国民宿舎はらぺこ 大浴場

• キミのコードが汚い理由 (@IT)

賛否両論出ているようですが。。。おいらとしては概ね賛同。

コードを綺麗に書くことによって得られる最大の利点は、メンテナンス性にあります。可読性の低いコードは、修正や拡張が困難になる。ソフトウェア資産は蓄積されてゆくものだから、メンテナンス性の低いコードが量産されれば、それをメンテナンスし続ける企業にとっては不良債権にもなりかねないわけです。

実際それが原因で一方的に契約を切られた挙句、1年間近く無償の瑕疵保証対応に駆り出され続けた某社の人たちを現場で見てきたわけですが。。。

で、話を記事のほうに移すわけですが、冒頭のサンプルプログラムに対する批判が多いっすね (^_^; 。客観性を排除してこのサンプルに限って議論するなら、リスト 2 が優れているのは、二人のプレイヤーの対称性、可換性を、うまく表現している点にあると思う。「一般化できる問題は、できる限り一般化する」というのはプログラミングにおける基本中の基本。プレイヤー 1 よりプレイヤー 2 の方が勝っている場合と、逆の場合とで、別個にコードの記述が存在するようでは、後の仕様変更で、片方のケースしか仕様変更が適用されなかったというミスに繋がりかねない。これを「メンテナンス性の欠如」と言わずして、なんと言おうか。

但し、リスト 1 の方が、リスト 2 よりも可読性は高そうだ。恐らく、このサンプルがいまいち納得されにくくなっている一番の要因は、この点にあるんじゃないかと思う。リスト 2 に対しては、適切なコメント付けが必要になるんではないかと思う。逆にいえば、適切なコメントが追加されるのであれば、リスト 2 がリスト 1 より劣っていると言える理由は、他にはなくなるんじゃないかと思う。インデントに関する好みとか、細かい部分での意見の分裂はあるかもしれないけど。

汚いコードができる理由については、最初、3 つの項目を見たときには、「なんか微妙に体育会系っぽい意見だなぁ」とか思ってしまったわけですが、読み進んでいくうちに概ね納得しました。まぁ、プログラミングって、キータイプが速けりゃ仕事も早く片付くってもんでもないし、一般化・抽象化できる要素を洗い出す作業に時間をかけるより、コピペしちゃったほうが早い、ってのも確かなんだよね。ブラッシュアップ工数を見積もりに計上したいってのが、多くの開発者にとっての本音でもあり。。。

学習については、、、おいらの体験談を明かすならば、大学ではもっぱら C と BASIC とアセンブリ言語ぐらいしか講義としては扱われなかったってこともあって、当時 C++ や Java で取り入れられ始めていた「例外」って概念を知らなかった。入社一年目の仕事で、とある C++ で書かれたプログラムのメモリエラー検出を、new 演算子が返すポインタの NULL チェックでやるのをやめて、bad_alloc 例外を検出する方法で書き直そう、という話があって、そのときおいらが担当していたモジュール (NG 喰らった前任者が残していった、それこそ不良債権ｗ) でも対応作業を行ったわけですが、なんだか 2000 行近くある関数内の至るところに new が散りばめられていて (^_^; 、まぁ、関数内全部 try で括っちゃえばよかったんですが、それをやらずに散りばめられた new ごとに対応する try ～ catch を書いて、なんてことをやっていたら、後のコードレビューで流石に顰蹙買ってしまいまして、なんてことをやらかしたこともあったもんで、、、ただ体験的に綺麗なコードを書くことを心がけることの重要性を知らしめるのも重要っちゃ重要なのですが、やっぱりプログラミングスタイルを決定付ける様々な概念に対して、知識を深めることもまた、同時に同じくらい重要なんだろうなぁという気はするのでありまする。

熱意ってのは、よーするに優先度の問題ってことかな。大切なことだとは分かっていても、どうしても軽視してしまいがち、ってのはあるかもしれないね。だからこそ、それを適切に評価する機会を設けるってのは、大切なことだと思う。コードレビュー、ちゃんとやってますか?