(編注：2020/08/18、いただいたフィードバックをもとに記事を修正いたしました。) これはある仕事熱心な若手開発者のほぼ実話です。2004年の後半、この若手開発者は小さな会社で働き始めました。条件は全て彼の望みどおりでした。給料はいいし、扱うのは彼の得意とするプログラミング言語、アプローチの複雑性、モデリングのアーキテキチャでした。 彼にとって今回の会社が初めての職場ではありませんでした。しかし、ここでの最初のプロジェクトは結果的に 問題だらけ に終わりました。当時、この若手開発者は、機能は絶対に変わらないものだと思っていました。しかし、それは間違いでした。機能が変更されるたびに完全なリファクタリングを行わなければなりませんし、バグを引き起こして膨大な時間を無駄にしてしまいます。彼は、テストを書くといった実直な方法も試してみましたが、書いたテストはメンテナンスが必要な上、書くのに時間

コードを日本語訳したような設計書。CREATE TABLE 文を表形式に変換した定義書。これらは「Excel 方眼紙」と呼ばれる日本の SE 業界を象徴する伝統的な手法で記述されており、ロクにメンテナンスされることなく引き継がれ、保守担当者を困惑させる。 今回はこうした設計書がなぜ存在し、どうしたらこんな醜いものをなくせるか、考えたい。 対象とするのは、ブラウザからアクセスできる、Web アプリケーションとして動作する社内のアレコレを管理するようなシステムを作る場合。組み込み系などは経験ないので、ソフトウェア開発における話、それもインターネットに繋がっていない環境で仕事をさせられているような時代遅れの SIer に限定させていただきたい。 漠然と思った順に書き殴っていくので、乱文です。 自分の基本主張 コードファースト。ソフトウェアは実際に動いているコードが主たる成果物であり納品物。設計書

※2011.3.30追記 11個目の判断項目を追加しました。 また、「昔はね...」の補足説明を各項目に追加しました。 レガシープログラマ = モダンな言語のおいしい機能をうまく使いこなせていないプログラマ おいらは時々社内システムのコードレビューなんかをやっているのですが、「なんかちょっと前時代的だな〜」とか「ちょっと修正したらC言語でもコンパイルできそうだな〜」って思うことがよくあります。 おいらがレビューする言語は主にC#です。C#やJavaのような比較的モダンな言語のおいしい機能をうまく使いこなせていないプログラマを、ここでは「レガシープログラマ」と呼ぶことにします*1。 そこで、おいらがこれまでに見てきたコードの中から「これはレガシープログラマっぽい」と思った典型的な症例を10個11個挙げてみます。 レガシープログラマの判断項目 使われるローカル変数をすべてメソッドの最初に宣言す

「ソースコードを綺麗に書く」というのは、プログラマーであれば誰しもが心掛けたいと思っている極めて重要な事柄です。そもそも「綺麗なコードってなんぞ？」という感じですが、いくつかあると思います。 改行位置/空行の数/インデントなどに一貫性があり整っていて、パッと見が綺麗 「こんな難しいことがこんなに簡単に書けるなんて！」というエレガントさ 理解しやすい etc... ひとつ目は美的感覚の問題なので、基本的には人それぞれということで今回は言及しないことにします。チーム開発の場合はソースコード整形ツールで一定のクオリティを維持するのがお手軽ですね。ふたつ目もさておき、今回は「理解しやすさ」について考えてみようと思います。主にプログラミングの勉強を始めた人向け。 ※ 画像を借りているだけで、この本のオススメをする記事ではありません！ 1. そのコードを誰が読むのかを考える 「理解しやすいコード」は「

はじめに プログラミング技術の歴史は、ありとあらゆる歴史がそうであるように、いろんな「史観」で眺めることができます。ならば、プログラミング技術の歴史を、「エラーハンドリングとの戦い」という視点から見ることもできるのではないでしょうか。本日は、エラーハンドリングとの戦いの歴史を俯瞰することで、エラーハンドリングの勘所について考えていこうと思います。 なお、このエントリはNDSという勉強会の第41回で発表した内容と同一です。 Cの時代 Cの時代のエラーハンドリングでは、関数の返り値と、グローバル変数errnoを見ることで処理が成功したか失敗したかを見るのが一般的でした。 例として、文字列をlongに変換するstrtol関数をmanで引いてみましょう。すると、だいたい以下のようなことが書かれています。 変換に失敗すると、0を返す 変換に失敗した場合、グローバルな変数であるerrnoに以下の定数を

小野　今回、「美しいコード」をテーマに考えていこうということで、まず僕が興味を持ったきっかけについて話します。僕はこれまでパッケージをベンチャーでやってきた中で、プログラマーというのは美しいコードを目指すのが当たり前だとずっと思って生きてきました。ところが、4年前にセゾン情報と業務提携をして、そこでSIの実際の現場みたいなものに触れた時に、「美しいコードが当たり前」という考え方とは大きく異なる価値観で、いろんなことが動いている生態系を目の当たりにして。コードがあまり重視されてないというか、作業的に見られていることにショックを受けたわけです。これまで芸術性を極めて、大切にするべきもの、崇高なるソースコードへの探求の道みたいに思っていたものが、なんか雑作業扱いになってる？！みたいなところがあって、ものすごく傷ついたんですよね。自分が大事にしていたものが、この世界では価値を持たないと。 その後、

2019年にクレディセゾンに入社して、3年の月日が経った。 これまで基本的にシステムに関するすべてを外部に委託してきたこの事業会社で、ゼロから内製チームを組成し、70名規模に拡大し（※1）、データ駆動経営の推進チームも組成した。また、日本の大手金融会社として初めてSlackを全社導入するなどデジタル人材の採用・育成による内製開発を武器に、デジタルの力を事業会社のど真ん中にインストールしていくことはそれなりにできてきたかな、と感じている。 そして1年前に大きな転機があり、CTOに加えてCIOの仕事もすることになった。長きに亘りプログラミングを自分の仕事の核としてやってきた私にとって、当初はCIOの仕事は違和感もあり慣れないことばかりだったが、1年間を経て課題がクリアに見えてきて、今後何をすれば良いかが分かってきた。（※2） だから2022年は、CIOとして一気に会社を良くしていきたい。 続き

Changelog を英語で書く際に参考になるようなテンプレートをまとめてみました．git や svn のコミットログにも使えます． このエントリは今後も逐次更新を続けます（最終更新2018/11/01） リリースノートの英文についてはRelease note のための英文テンプレート集 - pyopyopyo - Linuxとかプログラミングの覚え書き -に分離しました git等のcommit メッセージにも使えます 以下，例文． バグ修正した場合 修正した場合　→　fix を使うのが定番です Fixed a performance regression. （パフォーマンスが低下するバグを修正しました） Fix possible memory leak Fixed an issue where some devices would display the wrong image. (いく

クラス名編をつくりました あるメソッドを定義しようとするとき、そのメソッドを使う人達が名前からどんなことをするか理解できるようにするには、メソッドの内容に応じて適切な情報量の命名が求められます。 この記事では、メソッド名に用いることでどのような情報が提供できるかを見ていきたいと思います。 真偽値を返すメソッド 場所 単語 意味 例

UKTKKNSHINF こういう名前の変数が出てくるのだが、意味わかる？ 答え：受付禁止情報 今読んでいるPL/SQLコードは本当にひどい出来なのだが、その中でもネーミングが群を抜いてひどすぎてむしろ笑えてくるので、ここでさらしてみたい。 先ほどの例でわかると思うが、悪しきネーミング習慣である子音母音抜きの嵐である。変数名だろうが関数名だろうがこのルールで命名されているので、暗号文を読んでいるような気分になる。 他には、例えばこんなのがある。 SKSI 作成 HNKN 変換 KKT 確定 CHKN 中間 DTM Datetime DTA Data こうして見ると、ktkrやwktkとなんら違いがない。 "作成"のような、比較的簡単に対応する英単語が見つかるものまで日本語子音母音抜きで書くという徹底ぶり。でも"情報"はINFだったりする統一感のなさ。そしてこれらが単独ならまだしも、複合して出

最近、会社でソースのコメントがらみで苦労して、ふと思った。 適切なコメントの書き方についての実践的な入門資料はないものか？ 『CODE COMPLETE 第2版 下 完全なプログラミングを目指して』の第33章や『Code Craft ~エクセレントなコードを書くための実践的技法~』の第5章では良いコメントについて結構なページ数を割いて詳しく論じているし、そこまで詳細でなくてよいのなら『プログラミング作法』の第1章で良いコメントの書き方の基本方針的なものが提示されている。参考になりそうな本はあるのだ。 ただ、ネット上でそれなりにまとまった資料となると、探し方が悪かったからかうまい具合に見つからなかった。本だと買って読んでくれる人が中々いないので*1、ネットで読めるものが欲しいのだ。 そこで、車輪の再発明であることを承知の上で、試しに自分で書いてみた。 対象読者は……そこまで考えていなかった。

コメントは基礎的で一般的なものでありながら、「どのようなことをコメントに残すか」は経験のあるプログラマにとっても難しいもの。 この記事では、アンチパターンコメントを見ながら、どのようなコメントを残すべきかについて説明します。 by 馬場美由紀 （CodeIQ中の人） コードは機械のために、コメントは人間のために? プログラミング言語を学ぶとき、コメントは最初に習う項目のひとつです。そして、プログラムであればコメントを含んでいることが普通です。ある研究によれば、ソースコードの平均19%がコメントだそうです。 コードを書くとき、私たちは機械とコミュニケーションを取ることを意識しています。機械はコードを認識してコンパイルしたり実行してくれます。解釈できなければ教えてくれます。プログラマは、コンパイラのためにデータ型を明示するコードを書いたりもします。 一方、コメントは人間とコミュニケーションする

ICT支援員の「めがねさん」が、先生をはじめとする登場人物との会話を通じてビスケットの魅力をお伝えする「めがねさんのビスケット活用術」をオープンしました。

Haxe 4 is here! Haxe is an open source high-level strictly-typed programming language with a fast optimizing cross-compiler. Download 4.3.4 Released: 2024-03-04 Haxe can build cross-platform applications targeting JavaScript, C++, C#, Java, JVM, Python, Lua, PHP, Flash, and allows access to each platform's native capabilities. Haxe has its own VMs (HashLink and NekoVM) but can also run in interpre

マネージャのあなたが、プログラマが作ったソフトウェアの「意図しない動き」を目撃したとします。このとき、その現象を指して軽々しく「バグ」という言葉を使ったりしていないでしょうか。 いいですか、それはバグではありません。 なぜなら、その現象がバグかどうかは、この時点ではまだ分からないからです。 たとえ、あなたにとっては「バグ」という言葉の範疇であったとしても、結果的に報告書に「バグ」と記載することになるのだとしても、決してプログラマの前で軽々しく「バグ」といってはいけません。 プログラマは「バグ」という言葉に、とかく敏感です。 いきなり、 「バグが出たので直していただけますでしょうか」 などと言おうものなら、顔を真っ赤にして憤慨します。 それもそのはず、調べる前から「バグ＝おまえが悪いから早く直せ」と言われているのに等しいのですから。 ひょっとすると、それはオペレーションのミスかもしれませんし

http://www.zusaar.com/event/438105 アプリケーションを作る英語 の著者の西野さんを交えて、クラス名とかメソッド名とか変数名とか命名で困っている課題を1つ以上持ち寄りみんなで一緒に検討する勉強会をしました。 「アプリケーションを作る英語」 電子書籍 http://tatsu-zine.com/books/english4app 紙 http://www.amazon.co.jp/gp/product/4844332848/ はじめに：西野さんからちょっとお話 The Art of Readable Code から第2章と第3章 第2章：名前に情報を詰め込むようにする どういう情報をつめこむか。 明確な言葉を選ぶ get は不明確らしい getPage(url) -> FetchPage(url) や DownloadPage(url) 特色のある（color

目指すは世界市場! 英語版アプリ開発のために、UIやメッセージでよく使われる英単語や構文パターン、さらに英語ライティングの基本やメッセージの書き方、I18N/L10Nの基本から翻訳業者への依頼まで、幅広く紹介。 サポートサイト著者によるサポートページが公開されています。 翻訳者 西野竜太郎 Webサイト 内容紹介最近スマートフォン用やWeb 用のマーケットが登場したことで、アプリケーションを海外に展開しやすくなりました。パソコンに加えてスマートフォンやタブレットといった新しい機器や、有線および無線の高速ネットワークが世界的に普及しつつあることを考えると、アプリケーションに対する需要は今後さらに拡大するものと思われます。海外は日本の開発者にとって魅力のある市場です。しかし海外展開には外国語での開発が必要となります。特に英語は世界共通語と位置付けられている面があるため、まず対応を考えるべき言語