10月4日(火)に行われた、達人プログラマー読書会@札幌に参加しました。
第4章〜23番まで。
実践的な話が増えてきて、自分でもできるけどやっていないことがたくさん。
この日は割と疲労困憊していて、話を思い出してブログに書くのが遅くなりました。。。
あなたは完璧なソフトウェアをつくることができない
キツキツの納期で、睡眠時間と一緒にいろいろな物を犠牲にしていたときだったので、ヒント30がとにかく身にしみました。（バグを出した直後だったのもあります）
「完璧なソフトウェアなんて存在しない」ことを甘えとするのではなく、だからこそ打てる手をきちんと打ちましょう（自分自身も含めて信頼しない）という話でした。
21. 契約による設計
契約的プログラミング（DBC）に全く触れたことがなかったので、この章の内容はつかみにくかったです。
現在自分がユニットテスト（TDD)で行っている物に近いのかなーと思いました。
「副作用を与えないプログラミング」「絶対的な要求は何か」なとパーツとして分解して考えた時に、違う形で（インターフェースのIN/OUTの型や方針を決定しておくことetc.）実現しているな、と感じた部分もありました。
22. 死んだプログラムは嘘をつかない
「トラッシュではなくクラッシュ」これには納得です。
付け焼き刃で延命させている中途半端なプログラムほど怖いものはありません。
早いうちにクラッシュさせて、原因の根っこの部分を解決することはとても重要。
いいやー、と後回しにしないよう、バグとは真摯に向き合っていきたいです。
23. 表明プログラミング
ここは、言語による違いがあるのかもしれないけれどJavaに慣れ親しんでいる自分にとってはすんなりと頭に入るところでした。
「こうであるべき」というのがある程度、型できっちり決められていたり、assertによりチェックをかけていたり。
127ページに書かれていた「ハイゼンバグ」は「ダメ！絶対！」
普段当たり前にやっていることから、忘れがちになっていることまで。
この本を読書会で読んで（そしてこのブログを書くために読み直して）、志高いプログラマになっていきたいです。
（読書会に参加して、最近ほんと、ダメコードを書いていたことを反省しました）