焦点を当てた書籍です。面白く読めると思います。上巻の感想は次のブログ記事を参照してください。変数名がどうだの文の構造がどうだのといった初心者向けの話題が多かった上巻と違い、コラボレーティブコンストラクションやプロジェクト管理、工数見積もりといったコーディングよりも上位の層の話題が多く、いろいろと面白かったです。上巻の内容は読むほどじゃないなー、と感じている人でも下巻は面白く読めるかもしれません。いうぐらいの人にちょうどいい内容だと思います。広範な内容に触れている書籍で、書かれている内容は良いことだらけなので、広く浅く学ぶために読む本として適しているでしょう。単体テストや統合テストによる欠陥検出よりも、公式のコードレビューや大規模なベータテストによる欠陥検出の方が検出率が大きい。ほとんどの研究では、欠陥検出のコストについても、テストよりもコードレビューの方が小さいという結果。コードリーディングではインターフェイスの欠陥が多く発見され、機能テストでは制御の欠陥が多く発見された。複数の方法を組み合わせると効果的。品質を改善すると開発コストが低くなる。デバッグとそれに伴う修正に多くの時間がかかっている。品質を改善し、デバッグなどにかける時間を削減することで開発コストを小さくする。コンストラクション時の品質保証も大事だし、コンストラクションの前段階での品質保証も大事。適切にリソースを配分する。実際のところ糞みたいな欠陥の調査に結構な時間が割かれるので、リリース前にちゃんとしたいし、して欲しい。コラボレーティブコンストラクションペアプログラミングやコードレビューなど、複数人での共同作業について。本書では、次のようなコラボレーティブコンストラクションが紹介されている。人のプログラマがペアを組んで作業する。コード品質の向上や、コーディング時間の短縮、若手の教育に効果的といった利点がある。コーディング規約で議論する、とかしていると無駄だし、初心者同士が組んでも効果は薄いなど、気を付けるべきことはいろいろある。準備ののち、会議室に集まって仕様やコードのレビューを行う。(進行役)、レビュア、仕様やコードの作成者、記録係、が必要。準備として、予めレビュアが仕様やコードについて読んで欠陥を洗い出しておく。その後、会議室に集まり、設計をわかりやすく説明させたり、コードの流れを追ったりして、その中で欠陥を報告していく。記録係は報告された欠陥を記録する。欠陥についての議論は、それが欠陥であるという認識に達した時点で終了すること。組織的にインスペクションを行い、インスペクションごとの記録を次に活かすことでより改善されていく。人以上で集まって設計やコードについて話し合う、というぐらいのざっくりした定義。参加者全員が予め設計やコードを読んでおく。参加者が集まり、作成者が進行役になって欠陥を検出していく。基本的には公式なインスペクションの方が費用対効果が高い。ソースコードを読み、欠陥を探す。いった品質面について意見を述べる。人以上のレビュアが、コードを読んで問題点を探す。その後、作成者を進行役として会議をする。インスペクションやウォークスルーと違い、コードを読むことに時間をかける。利点などを書くと次のような感じ。コラボレーティブ開発プラクティスは、テストよりも効果的に欠陥検出する傾向。検出しやすい欠陥の種類はテストによるものとは異なるので、テストと組み合わせる必要がある。ペアプログラミングは一般にインスペクションと同程度のコストで同程度の品質のコードを生み出す。公式なインスペクションは、コード以外にも、要求、設計、テストケースなどの作業に利用可能。ウォークスルーとコードリーディングは公式なインスペクションの代替。時間を柔軟に使いやすい。今はチームで簡易的なコードリーディングをやってるのだけど、やっぱりそれだけだと品質を十分に保証できないし、チームメンバーの教育効果という観点でも微妙なんだよなー。簡易的にするなら仕様のウォークスルーとコードリーディング、って感じが良さそうかなぁと今のところは思ったりしてる。ここら辺は個人的にはそんなに学ぶことはなかった。品質改善のプロセスにおいてテストは重要ではあるけれども、上にも書いたようにインスペクションとかコードレビューとかも重要だよね、とか。欠陥修正は場当たり的に行うのではなく本質的な変更をせよ、とか。欠陥が多いクラスはそもそも設計が悪い可能性があるので、設計から見直して一から書きなおすということも検討せよとか。よってもパフォーマンスは違うということを意識せよ、とか。確かにプログラミングの勉強を始めたころはこんな感じだったなー、と懐かしい感じ。理由で場当たり的な修正をしてしまうってことはあると思うので、場当たり的な変更をするならするで後から適切に修正するための時間を確保するとか、そういう感じのことをせねばなー、と思ったり。作業について記述されている。小規模なプロジェクトと比べると大規模なプロジェクトでは生産性が低くなるし行あたりの欠陥の数が多くなる、とか、参加するソフトウェアエンジニアが多くなるのでコミュニケーションのサポートが必要になる、などの話が書かれている。コンストラクションの管理ソフトウェア開発の管理のうち、特にコンストラクションに関連する部分について述べられている。コーディングの標準を設定することについてや、プロジェクトの構成管理、コンストラクションスケジュールの見積もり方法についてなど。工数の見積もりはソフトウェア開発における難題の一つであって、プロジェクトの開始時点での見積もりでは実際の工数と数倍程度の開きがある見積もりをしてしまうこともよくある。複数の方法で見積もりをして結果を比較することでより正確な見積もりを出すとか、定期的に見積もりをし直すことで当初の見積もりの誤りを修正していく、ということが書かれていた。ソフトウェアエンジニアが自分の担当箇所の工数を見積もる際の難しさもさることながら、プロジェクト全体の工数見積もりはより一層難しいよなぁと最近思ってる。まあそこら辺はコミュニケーションの問題なのだけれど。言われるまでもないことだけど、プログラマの能力には個人差があって、コーディングやデバッグにかかる時間、それからソフトウェアの品質や実行速度に大きな差が付きうるとか、作業環境と生産性の間に強い因果関係がある、という話が書かれている。良い環境で仕事したい。つのシステムにまとめる作業について。プロジェクトが小さければコンストラクションの最後に統合しても良いが、大きなプロジェクトであればインクリメンタルに統合していく方が効果的。それから、毎日ビルドしてスモークテストすることで、品質低下のリスクを減らしたり、欠陥を発見した場合にいつ混入したのか調査しやすくできる。いうことが書かれていた。ソフトウェア開発に便利なツールがいろいろあるから使いましょう、という話。部では、コーディングスタイルについてや、プログラマとしての心構え、といったことが書かれている。読み物として結構面白かった。読もうと思ったのは、この章に書かれているコメントについて読みたかったから。一年ぐらい前にコメント付けについて考えていたので、本書に書かれている内容が気になっていた。ひだまりソケットは壊れないで、読んでみてどうだったかというと、本書に書かれていたコメント付けについての思想は基本的に私が上の記事に書いた思想と同じだった。適切なコメント付けってそんな感じだよなー、という感想。コードの行うことを別の言葉で置き換えたもの。複雑なコードの説明など。