CODE COMPLETE メモ2

第5章 コンストラクションにおける設計

5.1.2 設計はルーズなプロセスである、たとえきちんとした結果を生むとしても

完成したソフトウェア設計は理路整然とした明確なものであるべきだが、設計を作り上げるプロセスは、最終的な結果の生前さとは程遠い。設計がルーズなのは、しょっちゅう手順を間違っては袋小路に入り込んでしまうからである

5.1.3 設計は妥協と優先順位の産物である / 5.1.4 設計には制限がつきものである

設計の目的っは可能性を生み出すことであると同時に、可能性を制限することでもある

これは確かにと思った。たとえばデータクラスを設計する際、可変にするかどうかを考えることが少なくない。不変にすればインスタンス作成後は変更される心配がなくコードも簡潔で済む。一方UIに近かったり通信に関係するオブジェクトはイベントを受けて修正を重ねたりするケースがあるので、単純にプロパティを可変とするのか、固定値のセットで完結するのであればenumで表すのかといった可変にもさまざまな制約を課して考慮すべき点を排除することが多々ある。

5.1.5 設計は非決定論的である

同じプログラムを3人の開発者に設計させると、それぞれ完璧に条件を満たしたまったく異なる3種類の設計が手元に戻ってくるだろう。

最近は杓子定規になんでも流行りのスタイルやOSSに寄せればOKとか、クリなんちゃらを使っておけばよいといった思考停止が横行している気がする。

5.2.1 ソフトウェアの鉄則：複雑さへの対応 / 複雑さに対処することの重要性

ソフトウェアプロジェクトの失敗の原因に対する調査報告で、失敗の主な要因として技術的な理由が挙げられることはめったにない。もっと多いのは、要求に不備があること、計画に不備があること、あるいはプロジェクトマネージメントが不十分であることだ。 ...
複雑さへの対処は、ソフトウェア開発における技術面での最も重要なテーマである。

いかに平易なプログラムを組むか、は本当に重要だと思う。難しいことをやるんだから難しいではなくたとえば低レベルの処理は中レベル高レベルと分けることで、とても分かりやすくなる。iOSのオーディオAPIはよくできているので実際参考になった。

5.2.2 設計に望ましい特性

最小限の複雑さ / 保守性 / 疎結合 / 拡張性 / 再利用性 / 移植性 / 階層化 / 標準化手法

日ごろから心がけていること。

* 高いfan-in ... そのクラスを使用するクラスがたくさんあること
* 低いfan-out ... 1つのクラスが使用するほかのクラスが少ないこと...高いfan-outは使用するクラスが多く、複雑になりすぎる可能性がある
* 無駄のなさ ... 余分なコードはレビュー、テスト、検討、互換性維持が大変

5.3.5 秘密の隠蔽

* 良いクラスインターフェイスは氷山の一角のようなもので、クラスのほとんどの部分を公開しない
* 複雑さを隠ぺいして、特に必要なければ考えずに済むようにする
* 変更の源を隠ぺいして、変更が発生したときに、その影響を１カ所に留める

この辺は例も含め非常に濃く書かれているのでピンと来ていない方はぜひとも読むべき。公開されているインターフェイスは少ないけれども、きちんとやりたいことができるクラスは読みやすいし使いやすい。

5.3.9 その他のヒューリスティクス

* 失敗の回避...土木工学の教授Henry Petroskiは、橋の設計の失敗の歴史を記録した～という興味深い本を執筆している。壮大な橋の失敗の多くは、過去の成功にこだわるあまり、失敗する可能性があるケースを十分に考慮しなかったことが原因であるという。そして、タコマ海峡橋のような失敗は、成功した設計の特徴をそっくりまねるだけでなく、どうすれば橋が崩壊するのかを慎重に検討していれば防げたという結論を下している。この数年間に有名なシステムのセキュリティ上の欠陥が話題になっていることを考えると、設計の過失に対するPetroskiの見解をソフトウェアにも適用する方法を考えるべきという意見に反論するのは難しい。

丸ごとうつしてしまったが、、なるほどと思ったので。

5.4.7 設計作業の文章化

* 設計書をコードに直接挿入する (javadocなど)
* 設計に関する議論や決定事項をWikiに記録する
* 電子メールで議事録を送る
* デジカメを使用する
* 設計をフリップチャートに記録する
* CRCカードを使用する
* UML図を適度に詳しく作成する

10年前の手法が今の技術を使って有効なのは興味深い。個人的に設計は一人で行うので資料はdoc系かwikiにまとめることしかしないが、ホワイトボードの図を写真に記録したりUML図を作るケースは時々見るので下巻にある複数人での設計作業もチェックして実践したい。