バグが入らないように設計する方法
- 第4、5、6章で議論した概念的な整合性（conceptual integrity）のためのアーキテクチャの努力を行い、仕様や定義を出来る限り明確にし、書き手によって暗黙の前提が違っていたというような事態を避けること。
- コーディングのずっと前に、テストチームに仕様を渡し、不足やあやふやな点がないか綿密に調べてもらうこと。
- トップダウンで設計すること。つまり、全体の構成から小さな部分に向かって、いくつかのステップに分けて設計を行うこと。各ステップでは、出来る限り高レベルの表記を用い、現ステップでは不要な詳細は隠すこと。このトップダウンの過程の中で、他から独立して詳細が設計できるモジュールを見いだしていくこと。
- 詳細の設計で困難な問題が見つかった場合など、必要な場合はステップをさかのぼってやり直すこと。
テストとデバッグ
- コンピュータを動かしてデバッグ作業をする前に、どのようにデバッグするかの計画を立てるべきだ。デバッグ作業の後には、ログの保存や分かったことを記録するなどの後始末を行うべきだ。
- システムテストには、デバッグ済みの、つまり、バグを見つけて修正した後のコンポーネントを用いること。バグが残っているコンポーネントを組み合わせてテストするのは著しく効率が悪い。
- テスト期間中もソースコードなどのバージョンをきちんと管理すること。こうすることで、変更を全て記録し、応急的な修正と正式な修正の区別が付くようにすること。
- システムテストでは、コンポーネントを1つずつ足していくこと。つまり、全てがダミーのものである状態から始めて、1つずつ本物のコンポーネントに交換していくこと。追加の際は、追加コンポーネントのテストだけでなく、実施済みのテストも再度行うこと。つまり、追加の際は回帰テストも行うこと。
- 既にシステムテストへ追加済みのコンポーネントを更新する場合も、1つずつ交換して回帰テストを行えば良い。
- それぞれのコンポーネントの開発チームがテストベッドとして共通に使うバージョンは、頻繁に変更しない方が良い。このバージョンは、統合テストが終わっているものの中で最新のものが基本となるが、バージョンとバージョンの間を広く空けて、その間にまとまった量の改良や修正が入るようにするべきだ。このテストベッドの変更は少なからず作業を遅らせるので、効率的に開発できる安定した期間を増やすためには、間隔を広く取る必要がある。例えば、応急的な修正は定期的なタイミングを待って共通テストベッドバージョンに取り込むことにして、このときまでにはテストと文書を伴った正式な修正にしておくというやり方がある。
第13章に関する注記
- （設計・テスト・デバッグの良い手法が載っているとして、第13章では参考文献が複数挙げられている。）
- （第13章の「Structured programming」の節に書かれている主張は、多くのプログラミング言語に取り込まれ、一般化したと思われるので省略する。）
- （第13章の「Component Debugging」の項では、デバッグ手法の歴史的変遷が述べられており、これまでに登場したsupervisory programなどの名称が具体的に何を指すのか、また、本書の文章が書かれた当時の技術的前提がどのようなものであるかなどを理解するのに役立つ。）
- （第13章の「Build plenty of scaffolding」の節では、テストやデバッグのための足場（scaffolding）の具体例が書かれている。）
他の章はこちらから：
「人月の神話」の要点
人月の神話の要点・ポイントをまとめています。原著に基づき、人月の神話の要点・ポイントを主に箇条書き形式でご紹介しています。
picolab.dev
2022.04.18
