読んだ: CODE COMPLETE 第 2 版 下 — 完全なプログラミングを目指して

『CODE COMPLETE 第 2 版 下』 を読み終えました。

CODE COMPLETE 第2版 下

上巻と同じく、ソフトウェア開発の中の、詳細設計やコーディングとデバッグ、単体テストなどの部分 (本書では 「コンストラクション」 と呼んでいる) に焦点を当てた書籍です。 コラボレーティブコンストラクションやプロジェクト管理といった話題もあるので、経験のあるプログラマでも上巻 (かなり初心者向け) よりは面白く読めると思います。 上巻の感想は次のブログ記事を参照してください。

• 読んだ: CODE COMPLETE 第 2 版 上 — 完全なプログラミングを目指して - ひだまりソケットは壊れない

全体的な感想

変数名がどうだの文の構造がどうだのといった初心者向けの話題が多かった上巻と違い、コラボレーティブコンストラクションやプロジェクト管理、工数見積もりといったコーディングよりも上位の層の話題が多く、いろいろと面白かったです。 上巻の内容は読むほどじゃないなー、と感じている人でも下巻は面白く読めるかもしれません。

下巻は 「一人でコードを書くことについては一人前だと思うけど、チームでの開発とかコンストラクション全体の管理といったところはまだこれからだなー」 というぐらいの人にちょうどいい内容だと思います。 広範な内容に触れている書籍で、書かれている内容は良いことだらけなので、広く浅く学ぶために読む本として適しているでしょう。

内容と細かな感想

第 5 部 コードの改良

第 20 章 ソフトウェアの品質

• 単体テストや統合テストによる欠陥検出よりも、公式のコードレビューや大規模なベータテストによる欠陥検出の方が検出率が大きい。
• ほとんどの研究では、欠陥検出のコストについても、テストよりもコードレビューの方が小さいという結果。
• コードリーディングではインターフェイスの欠陥が多く発見され、機能テストでは制御の欠陥が多く発見された。
  • → 複数の方法を組み合わせると効果的。
• ソフトウェア品質の原則: 品質を改善すると開発コストが低くなる。
  • デバッグとそれに伴う修正に多くの時間がかかっている。 品質を改善し、デバッグなどにかける時間を削減することで開発コストを小さくする。
• コンストラクション時の品質保証も大事だし、コンストラクションの前段階での品質保証も大事。 適切にリソースを配分する。

実際のところ糞みたいな欠陥の調査に結構な時間が割かれるので、リリース前にちゃんとしたいし、して欲しい。

第 21 章 コラボレーティブコンストラクション

ペアプログラミングやコードレビューなど、複数人での共同作業について。 本書では、次のようなコラボレーティブコンストラクションが紹介されている。

• ペアプログラミング: コーディング時に 2 人のプログラマがペアを組んで作業する。
  • コード品質の向上や、コーディング時間の短縮、若手の教育に効果的といった利点がある。
  • コーディング規約で議論する、とかしていると無駄だし、初心者同士が組んでも効果は薄いなど、気を付けるべきことはいろいろある。
• 公式なインスペクション: 準備ののち、会議室に集まって仕様やコードのレビューを行う。
  • 役割として、モデレータ (進行役)、レビュア、仕様やコードの作成者、記録係、が必要。
  • 準備として、予めレビュアが仕様やコードについて読んで欠陥を洗い出しておく。
  • その後、会議室に集まり、設計をわかりやすく説明させたり、コードの流れを追ったりして、その中で欠陥を報告していく。
  • 記録係は報告された欠陥を記録する。 欠陥についての議論は、それが欠陥であるという認識に達した時点で終了すること。
  • 組織的にインスペクションを行い、インスペクションごとの記録を次に活かすことでより改善されていく。
• ウォークスルー: 2 人以上で集まって設計やコードについて話し合う、というぐらいのざっくりした定義。
  • 参加者全員が予め設計やコードを読んでおく。
  • 参加者が集まり、作成者が進行役になって欠陥を検出していく。
  • 基本的には公式なインスペクションの方が費用対効果が高い。
• コードリーディング: ソースコードを読み、欠陥を探す。 また、設計やスタイル、可読性、保守性、効率といった品質面について意見を述べる。
  • 一般的に 2 人以上のレビュアが、コードを読んで問題点を探す。
  • その後、作成者を進行役として会議をする。
  • インスペクションやウォークスルーと違い、コードを読むことに時間をかける。

ざっくりと利点などを書くと次のような感じ。

• コラボレーティブ開発プラクティスは、テストよりも効果的に欠陥検出する傾向。
• 検出しやすい欠陥の種類はテストによるものとは異なるので、テストと組み合わせる必要がある。
• ペアプログラミングは一般にインスペクションと同程度のコストで同程度の品質のコードを生み出す。
• 公式なインスペクションは、コード以外にも、要求、設計、テストケースなどの作業に利用可能。
• ウォークスルーとコードリーディングは公式なインスペクションの代替。 時間を柔軟に使いやすい。

今はチームで簡易的なコードリーディングをやってるのだけど、やっぱりそれだけだと品質を十分に保証できないし、チームメンバーの教育効果という観点でも微妙なんだよなー。 簡易的にするなら仕様のウォークスルーとコードリーディング、って感じが良さそうかなぁと今のところは思ったりしてる。

22 章から 26 章

それぞれ 「デベロッパーテスト」、「デバッグ」、「リファクタリング」、「コードチューニング戦略」、「コードチューニングテクニック」 という章。 ここら辺は個人的にはそんなに学ぶことはなかった。

品質改善のプロセスにおいてテストは重要ではあるけれども、上にも書いたようにインスペクションとかコードレビューとかも重要だよね、とか。 デバッグは科学的に行おう (憶測で 「ここを変えたら良さそう」 と思ったところを変更して、実行してみて直ってるかどうか確かめる、みたいな試行錯誤はやめろ) とか、欠陥修正は場当たり的に行うのではなく本質的な変更をせよ、とか。 欠陥が多いクラスはそもそも設計が悪い可能性があるので、設計から見直して一から書きなおすということも検討せよとか。 パフォーマンスの改善をするなら測定は欠かせないし、環境 (コンパイラの違いとか) によってもパフォーマンスは違うということを意識せよ、とか。

確かにプログラミングの勉強を始めたころはこんな感じだったなー、と懐かしい感じ。 あと、意識してても 「時間がないから」 などの理由で場当たり的な修正をしてしまうってことはあると思うので、場当たり的な変更をするならするで後から適切に修正するための時間を確保するとか、そういう感じのことをせねばなー、と思ったり。

第 6 部 システムの考察

6 部は、プログラマがコードを書く、という部分ではなく、より上位 (コンストラクション全体の管理、というような) の作業について記述されている。

27 章 プログラムサイズが及ぼす影響

小規模なプロジェクトと比べると大規模なプロジェクトでは生産性が低くなるし行あたりの欠陥の数が多くなる、とか、参加するソフトウェアエンジニアが多くなるのでコミュニケーションのサポートが必要になる、などの話が書かれている。 ここら辺はソフトウェアエンジニアなら肌感覚でわかっていると思うけれど、実際の調査結果が提示されているので 「なるほどー」 という感じ。

28 章 コンストラクションの管理

ソフトウェア開発の管理のうち、特にコンストラクションに関連する部分について述べられている。 例えばコーディングの標準を設定することについてや、プロジェクトの構成管理、コンストラクションスケジュールの見積もり方法についてなど。

工数の見積もりはソフトウェア開発における難題の一つであって、プロジェクトの開始時点での見積もりでは実際の工数と数倍程度の開きがある見積もりをしてしまうこともよくある。 複数の方法で見積もりをして結果を比較することでより正確な見積もりを出すとか、定期的に見積もりをし直すことで当初の見積もりの誤りを修正していく、ということが書かれていた。

ソフトウェアエンジニアが自分の担当箇所の工数を見積もる際の難しさもさることながら、プロジェクト全体の工数見積もりはより一層難しいよなぁと最近思ってる。 プロジェクトのリーダーとエンジニアのやり取りの際に、意図している工数見積もりの見積もり対象が違っていたり (例えばサーバーサイドの実装の期間の見積もりをプロジェクトリーダーから依頼されて、エンジニア側は単純に設計とコーディングとテストの部分だけを見積もったけど、プロジェクトリーダーの意図としてはインフラの準備なども含めた工数を見積もって欲しかった) とか。 まあそこら辺はコミュニケーションの問題なのだけれど。

あとこの章で面白かったのが 「プログラマは人間である」 という節。 改めて言われるまでもないことだけど、プログラマの能力には個人差があって、コーディングやデバッグにかかる時間、それからソフトウェアの品質や実行速度に大きな差が付きうるとか、作業環境と生産性の間に強い因果関係がある、という話が書かれている。 良い環境で仕事したい。

29 章、30 章

29 章 「統合」 は、複数のソフトウェア部品を 1 つのシステムにまとめる作業について。 プロジェクトが小さければコンストラクションの最後に統合しても良いが、大きなプロジェクトであればインクリメンタルに統合していく方が効果的。 それから、毎日ビルドしてスモークテストすることで、品質低下のリスクを減らしたり、欠陥を発見した場合にいつ混入したのか調査しやすくできる。 ということが書かれていた。

30 章は 「プログラミングツール」 で、ソフトウェア開発に便利なツールがいろいろあるから使いましょう、という話。

第 7 部 ソフトウェア職人気質とは

7 部では、コーディングスタイルについてや、プログラマとしての心構え、といったことが書かれている。 読み物として結構面白かった。

32 章 読めばわかるコード

そもそも 『CODE COMPLETE』 を読もうと思ったのは、この章に書かれているコメントについて読みたかったから。 一年ぐらい前にコメント付けについて考えていたので、本書に書かれている内容が気になっていた。

• プログラムに対する適切なコメント付けについて考えてる - ひだまりソケットは壊れない

で、読んでみてどうだったかというと、本書に書かれていたコメント付けについての思想は基本的に私が上の記事に書いた思想と同じだった。 (と思ってる。) 適切なコメント付けってそんな感じだよなー、という感想。 本書では、コメントの種類を次の 6 つに分けていた。

• コードの繰り返し: コードの行うことを別の言葉で置き換えたもの。
• コードの説明: 複雑なコードの説明など。
• コードの目印: TODO コメントなど。
• コードの概要: コードの要約。
• コードの意図の説明
• コード自体では表せない情報: 著作権表示とか設計上の注意点とか関連する仕様への参照とか。

完成されたコードに含まれていて構わないのは最後の 3 つである、と本書では書かれていた。 コードの説明を書くぐらいならリファクタリングして説明を不要にすべきではあるけれど、(何らかの制約で) リファクタリングできない場合は説明をコメントで書いておくと良い、とも書かれていた。

35 章 さらに情報を得るには

さらに学ぶための書籍の情報がいろいろ書かれていた。 特に興味深かったのが、著者が所属する会社である Construx のソフトウェア開発者がプロとしての地位を獲得するために消費しなければならない読書計画が掲載されていたこと。 本書自体がちょっと古い書籍なので今だとまた違っているかもしれないが、参考にはなると思う。 *1 良さそうな本はそのうち読みたい。

ちなみに本書自体は 「初級」 レベルのところに入っているので、このエントリ内の 「感想」 にも書いたように、本書はソフトウェア開発を始めて日が浅い人が読むべき本だと思う。

次のものが 「初級」 レベルより上に進むために読まなければならない本。

メンタル・ブロックバスター―知覚、感情、文化、環境、知性、表現…、あなたの発想を邪魔する6つの壁

珠玉のプログラミング 本質を見抜いたアルゴリズムとデータ構造

ソフトウエア開発 55の真実と10のウソ

新訳 ソフトウェアプロジェクトサバイバルガイド

CODE COMPLETE 第2版 下

CODE COMPLETE 第2版 上

「実践」 レベルの地位を獲得するには次の書籍。

パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)

UML モデリングのエッセンス 第3版 (Object Oriented SELECTION)

ソフトウエア・クリエイティビティ

基本から学ぶソフトウェアテスト

実践UML 第3版 オブジェクト指向分析設計と反復型開発入門

ラピッドデベロップメント―効率的な開発を目指して (MicrosoftPRESS)

ソフトウェア要求

• Manager's Handbook Software Development (PDF)

「プロフェッショナル」 レベルについてはそれぞれの開発者に合わせて調整されるらしいが、下記のものは最低限必要っぽい。

Software Architecture in Practice (3rd Edition) (SEI Series in Software Engineering)

リファクタリング―プログラムの体質改善テクニック (Object Technology Series)

オブジェクト指向における再利用のためのデザインパターン

Principles Of Software Engineering Management

ライティングソリッドコード―バグのないプログラミングを目指して (マイクロソフトプレスシリーズ)

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)

オブジェクト指向入門 第2版 方法論・実践 (IT Architects’Archive CLASSIC MODER)

• SOFTWARE MEASUREMENT GUIDEBOOK (PDF)

*1:この下では、本書に書かれている版より新しいものが出ている場合はそれを掲載している。 また、日本語版がある場合は日本語版のみを掲載している。