つかびーの技術日記

(情報)工学修士, 元SIer SE, 現Web系 SEの技術blogです。Scala, Java, JS, TS, Python, Ruby, AWS, GCPあたりが好きです。

CODE COMPLETE(上巻)を読んだ感想と抜粋

   

最近は以下の技術書を読んでいました。あまり読書時間を確保しなかったので、読み終わるまでに2ヶ月以上かかりました。500ページ以上ありますし、結構考える部分が多いので時間がかかりましたが、読んでよかったです。

[tmkm-amazon]489100455X[/tmkm-amazon]

感想

非常によく考えられて書かれている印象です。参考文献、引用の数が非常に多いです。そのため、よくある「著者の持論を展開するだけで、納得はするけど根拠に欠ける」という状況が少ないです。確かな情報のもとに話が展開されています。

引用元論文だけでなく、推奨する図書についても書いていますので、ソフトウェア開発ちゃんと学びたいけど、どの本を読めばいいのか分からない、という人にも向いていると思います。各章で紹介されているので自分の気になった章の本を読めばいいと思います。Effective C++やデザインパターンなど、ソフトウェア業界で良書と呼ばれている物が多数紹介されています。個人的には大学3年くらいのときにまずこの本を読んでおきたかったです。

冒頭の著名人のCODE COMPLETEに対する賛辞も特徴の一つです。GoFで有名なRalph Johnson, リファクタリングで有名なMartin Fowlerなどもこの本を褒めています。

肝心の本の中身はというと、書名にCODEとありますが、要求定義からコーディングまで幅広く扱っています。テストについての話は少ないです。上流工程では何を考えれば良いかから、良いクラス、ルーチン、変数をどうやって書くかまで非常に広いです。具体的にどういう点が良かったかは以下に書いて行きます。

良かった点抜粋

ソフトウェアに紛れ込んだ欠陥を修正するのは早ければ早いほど良いです。例えば要求段階で紛れ込んだ欠陥は要求を練ってるうちに修正した方が良い、ということです。誰もリリース後に欠陥を直すのが良いとは思わないはずです。理由はコストがかかるからです。この本は複数の論文による成果をまとめて、このコストの数値を表形式で提示しています。例えば要求段階で紛れ込んだ欠陥はアーキテクチャ段階では3倍、システムテスト段階では10倍かかると言っています。

情報隠ぺいについての説明がよくされている点も良かったです。「書き手の便宜より読み手の便宜を優先する」というような話もあって、カプセル化、インタフェースをよく設計するなどオブジェクト指向の本質を述べている点が良かったです。

人の頭では7プラスマイナス2程度の継承構造しか理解できないという話も勉強になりました。自分はあるクラスがあったとしたら5継承も一度に頭で整理できない気がします。それほど深い継承構造を1から作ったことがありませんが、既存のクラスを新たに継承するシーンは多いので、そのときは十分注意したいです。

ルーチンのサイズについては興味深い話が載っていました。各研究成果をまとめていました。研究Aではルーチンのサイズがエラーと反比例する(コード1行あたりのエラーの数は減っていく)ことが判明した。研究Bでは、小さなルーチンは大きなルーチンより1行あたりのエラー率が23%高いが、修正コストは2.4倍少ない。とか。

ルーチンの引数はだいたい7個に制限すること、とも言っています。これは割とよく聞く話ですが、7の理由は心理学の調査による結論なんだとか。7つ以上の情報のかたまりを一度に覚えていられないそうです。

ループ変数にも正しく名前を付けよう、という話は初めは懐疑的でしたが、本を読み終えた今では同意しています。当初は「ループ変数は一目で誰もがそれと分かるi, j, jを使ったほうが良いんじゃないかな」と思っていましたが、確かにループが長くなったり、ループがネストしているとi, j, kが何を表すのか分からなくなって困るシーンがありました。これからは短いループ(せいぜい10行程度)ではi, j, kでもいいが、その他の場合はループ変数も正しく命名しようと思いました。

変数への値の割り当てが早いほど(つまりi = 10;というような記述)、複雑さが下がり、柔軟性が下がる。割り当てが遅いほど(例えばi = getHogeValue();というような記述)、複雑さが上がり、柔軟性が上がる、という話も納得できて面白かったです。前に経験したあるプロジェクトでは何でもかんでも値をDBへ入れたがったり、やたらと柔軟性を謳う設計者のせいで複雑さがとんでもなく高いソフトウェアが出来上がっていました。保守フェーズまで含めて総合的に見るともしかして良いのかもしれませんが、柔軟性があってもそもそも複雑で理解できなければ保守は無理ですよね・・・。

他にもifをネストしないで、ガード句(ルーチン冒頭のifによるチェック)を使いましょうだとか、仮引数型や戻り値型はbooleanがふさわしいと思ってもEnumを検討しよう(true=success, false=errorだとすると、後でwarningを追加する時に表現できない)だとか、ためになる話が満載でした。

CODE COMPLETEおすすめです。この調子で下巻も読んでみようと思います。

 -