達人プログラマー／四章 妄想の達人

達人プログラマーの四章に関するまとめ

• 契約による設計

クラス・メソッドに対して事前条件、事後条件、不変表明などをまとめる。
理想はiContractなどを仕様してプログラムで実際にチェックを行うこと。
それが不可能でもコメントとして記述しておくだけでも価値がある。

• 死んだプログラムは嘘をつかない

プログラムは実行が失敗した段階で処理が停止するようにすること。
トラッシュ（滅茶苦茶）よりクラッシュ（停止）させる。
もしエラーを放置すれば実際にエラーが発生した箇所とは別の箇所で
プログラムが停止するか最悪停止しないまま実行が継続されることとなり
解析が困難になる。

• 表明プログラミング

主にassertを利用。実行に影響をあたえるようなコードは記述せず
起こりえないことをチェックする。
assertなどはオーバーヘッドを考慮してリリース時にはオフにすることが多いが
よほどパフォーマンスに影響がない限りはオンにしておくことを推奨している。

• いつ例外を使用するか

例外は通常のロジックから取り除いても影響のない場所で予期せぬ自体を補足するために
利用すること。

• リソースのバランス

メモリ、ファイル、スレッドなどリソースは呼び元が責任を持って解放まで管理すること。
割り当て時は順序に注意する＝デッドロック対策。

■感想
契約による設計は考慮漏れを防ぐ良い手段だと思いました。
昨今の開発はスピードが早いため旧ウォーターフォール型開発のように
すべての仕様をがっちり決めて開発に着手するよりは概要を決め詳細は
都度確認しながら進めるような形式も多いと思います。

当然ビジネス要件にあわせて途中で方針変更もあるわけで、
アジャイルな開発を行いながら柔軟な対応が出来るようにしておくべきです。
そこで、コードと設計の乖離を起こさずに詳細要件を契約として
ソースコード中にコメントとして残すのは良い手法だなと思います。
もちろん業務要件以外でPrivateメソッドレベルの前提にチェックに関しても。

さらに一歩進んでiContractを利用すれば・・・。
自分のTODOリストにiContractの評価を追加。

---

達人プログラマー―システム開発の職人から名匠への道