CODE COMPLETE メモ1

はじめに

4年くらい前にCODE COMPLETEを上下巻購入して、当時チーム開発ではなく個人でアプリ案件を回すスタイルだったので技術面しかわからず読んでいなかったが、最近は大規模かつ柔軟性に富むチームワークが求められているため、今もう一度読み直して重要そうな部分を引用しつつ個人的な意見等も残しておきたい。

第1章 ソフトウェアコンストラクションへようこそ

* コンストラクションはソフトウェア開発の大部分を占める、一般にプロジェクト全体の30~80%
* 開発の中心的なアクティビティである
* コンストラクションに専念することで個々のプログラマの生産性は驚くべき程向上する
* ソースコードはソフトウェアを正確に書き表した唯一のドキュメントである

書籍では課題定義から始まり、保守までのウォータフォールの一連の流れを最初にソフトウェア開発の構成として挙げている。

コンストラクションのほとんどの部分はコーディングとデバッグだが、詳細設計、コンストラクション計画、単体テスト、統合、統合テストなどのアクティビティも含まれる

第2章 メタファー（喩え）の重要性

* よく理解できないものをよく理解できるものと照らし合わせた結果、何かが閃いて解明できなかったテーマへの理解が深まることはよくあること（モデリングという）
* ソフトウェアを構築する(build)というイメージはソフトウェアを書く・育てるというイメージよりも適切、構築から計画準備実行など様々なステージが連想できる
* 犬小屋のような単純な構造物を組み立てるケースではルーズなアプローチでうっかりミスしてもさほど問題にはならないが、家を建てるプロセスの場合はもっと複雑、どのような家を建てるか決める「要件定義」、建築士と話し合って全体的な設計を決める「アーキテクチャの（概略）設計」、用地の準備、基礎、柱や梁、壁、屋根、配管配線＝ソフトウェアコンストラクション、造園・内装業者＝最適化、プロセス全体を通じた検分＝レビューやインスペクション
* 複雑になればなるほど規模が大きくなればなるほど、作業結果が及ぼす影響も大きくなる、ソフトウェアの構築は資材費用はほとんどかかからないが、人件費は膨大

かなりの具体例を挙げて良いケース悪いケースが紹介されている。この本を読んでからかなのかは忘れたが、確かにソフトウェア開発は建築と近しいものがあると考えていた。

第3章 上流工程の必要性

準備不足の原因

* 一般的な原因は上流の作業を担当する開発者が与えられた仕事をこなすための専門知識を持っていないこと
* プロジェクトを計画する、説得力のある業務分析を行う、包括的で正確な要求を開発する、高品質なアーキテクチャを作成するというスキルは並大抵ではない
* ほとんどの開発者はこれらを実行する方法について訓練を受けていない
* 方法を知らないとしたら「上流の作業を増やす」というアドバイスは無意味、きちんと作業が行われないのであれば増やしたところで意味がない
* 上流のアクティビティの実践方法を知っていたとしても、一刻も早くコーディングに着手したいという衝動を抑えられず、準備をおろそかにするプログラマもいる
* コンストラクションの準備に時間をかけるプログラマを上司が快く思わないこと
* 根拠を示して必要性を訴える

第3章ではコンストラクション（計画を立てること）を疎かにしてはいけないことを論理的に、喩えで、データに基づいて訴えることを説明している。前章から反復型・逐次型のプロジェクトが唐突に出てきて説明がなかったのだがアジャイルとウォータフォールみたいのものなのか（図3-3に図示されており逐次型は明らかにウォータフォールで「逐次型以外」については要求からシステムテストまでがほぼ同時に進行）。いずれにせよ、あらかじめ準備しておくことでトータルコストが安くなることが数字で示されている。3.2.2で反復型か、逐次型かのポイントが示されているので、選択の判断材料になりそうだ。

3.3 課題定義

* コンストラクションを始める前に完了しなければならない最初の準備は、システムが解決するはずの課題を明記すること
* プロダクトビジョン、ビジョンステートメント、ミッションステートメント、プロダクト定義とも
* 課題定義はソリューションとして考えられるものに一切言及せずに、課題が何であるかを定義する
* 1~2ページに収まる単純な文章、ユーザーが専門家でないのならユーザー目線にすべきで専門用語を使うべきではない

課題定義＝プログラミングプロセスの土台。

3.4 要求

* 要求開発、要求分析、分析、要求定義、ソフトウェア要求、仕様、機能仕様、スペックとも呼ばれる
* システムの機能をプログラマではなくユーザー主導で決定するのに役立つ
* 要求が明記されていないとプログラマが要求を決めながらプログラミングする羽目になる
* 明確な要求は議論を減らす効果もある
* 修正コストは要件策定時に比べアーキテクチャ設計時で3倍、コーディング時で5~10倍、システムテスト時で10倍、リリース後は10~100倍
* 管理コストの低い小規模なプロジェクトではリリース後の修正は5~10倍程度

炎上はなくしたい。

3.4.2 要求は不変という神話

* 一般的なプロジェクトではコードが書かれる前に顧客が必要なものを正確に説明することはできない、これは顧客が下等生物だからではない
* 顧客もプロジェクトへ長く関わることで内容・ニーズをよく理解するようになる（これが要求を変化させる主な原因となる）
* 要求に断固として従うような計画は顧客の意見を正しく反映させない計画
* IBMなどの調査によると平均的なプロジェクトでは開発時に要求の約25%が変更されることが分かっている
* これは一般的なプロジェクトでの修正作業の75~85%を占める

3.4.3 コンストラクション時の要求変更への対処

* 要求の品質の評価
* 変更に伴うコストを全員に認識させる
* 変更管理手順を決める
* 変更に対応できる開発手法を使用する
* プロジェクトの中止
* プロジェクトの業務要求の視点を忘れない

見出しを抽出しただけになってしまったが、要求チェックリストが載っており要求の品質の評価が可能になっている。これにより要求精度を上げることができれば同様な要求の変更を今後避けることが可能になる。

3.5 アーキテクチャの準備

* アーキテクチャとはソフトウェアの上位レベルの設計
* プログラムの構成を定義する
* 主要なクラスを規定する
→クラスの階層、状態の遷移、オブジェクトの永続性（クラスがサブシステムとして構成される方法も説明する
→80:20の法則、振る舞いの80%を実現する20%のクラスが明記されていればよい
* データ設計
→使用するファイルやテーブル設計を説明できるものにする、データベースの大まかな構造と内容
* 業務ルールがあれば明記
→e.g.顧客情報が30秒以上古くなってはならない
* UIの設計
→要求の策定時に規定されることが多いがそうでなければアーキテクチャに明記すべき
→Webページのフォーマット、GUI、CLIといった主な要素
→アーキテクチャはモジュール化すべきで、例えば対話型インターフェースのクラスをCLIに差し替えることが容易になる
* リソースの管理
→DB接続、スレッド、ハンドルなど希少なリソースを管理するための計画について説明すべき
→メモリの制約を受けるアプリケーション分野ではメモリ管理はアーキテクチャに盛り込まなければならない重要な領域の一つである
→アーキテクチャは通常のケースと極端なケースでリソースがどのくらい消費されるか予測が必要
...

アーキテクチャは考慮すべき点がとても多い。

上流工程にかける時間

* 一般に順調に進むプロジェクトでは工数の10~20%、スケジュールの20~30%を要求・アーキテクチャ・事前の計画に充てる
* 詳細設計のための時間は含まない、詳細設計はコンストラクションの一部
* 要求が確定しないまま進んでいる大規模で公式なプロジェクトに従事している場合は要求アナリストと協力してコンストラクションの早い段階で発見された要求上の問題点を解決しなければならない
* 要求が確定しないまま進んでいる小規模で非公式なプロジェクトに従事している場合は、要求上の問題点を自分で解決する必要がある
* 要求が確定していない場合は、公式なプロジェクトでも非公式なプロジェクトでも要求の策定をプロジェクトの作業の一つとして扱う
* 要件が確定したら、プロジェクトの残りの時間を見積もる
* "家の建築工事を請け負った業者だとして、施主が「費用はどれくらいかかるか？」と聞かれたら「どのような家にしますか」と尋ねるだろう、施主が「それはわからないけれど、いくらぐらいかかりそうか」と答えたらあなたは「お邪魔しました」といって立ち去るだろう"
* 建物の場合何を建てたいかが決まらないうちに見積もることが理不尽なのは明らか

ソフトウェアだからつい簡単に無計画で完成られそうだが、実際は建築と同じくらいの念入りな準備が必要なことがいろんな観点で述べられており、次の5章では設計に関するトピックなのでぜひとも読みたい。

4章は10年前の言語の話題でありいまでも通ずるものはあるが、特にメモしておくべき項目がなかったのでスキップ。

つづく？