達人プログラマーを読んで気づいたことなどメモ

達人プログラマーを読んで気づいたことや学んだことなどをメモしておきます。

割れ窓理論

割れ窓理論について、「1枚の割れた窓が長期間修理されずに放置されていると、ビルの住人に投げやりな感覚が植え付けられ、2枚目の窓が破られたりゴミが撒き散らされたりと建物に対する深刻な破壊が起こり始まる」と本書で説明していました。

これはネガティブな考えには伝染性があるからだとされており、明らかに問題があるにもかかわらずその状況を無視することで、破滅に向かっていきます。

割れた窓は、悪い設計や誤った意思決定、質の低いコードにも当てはまり、そのままにしておくことで深刻な問題を引き起こすことになります。

そのため割れた窓は発見と同時に修復する必要があります。もし正しく修復する時間がないのであれば、割りやすいところにその旨を明示するなど、何らかのアクションが必要です。

たしかに実体験として振り返ってみても、この割れ窓理論は開発においても当てはまると思います。

最初は頑張ってテストを書いていたのに、ある時にテストがやりにくいコードを実装してからテストをしなくなったことで、バグが頻発しプログラムの依存関係が煩雑化するなど、みるみるうちにシステムが破壊に向かったことがあります。

後でやればいいやはたいてい後からやらないため、いっときの楽しようという考えが後々の自分の首を絞めることが多々ありました。

どんなにしんどくても割れた窓を見つけたら見て見ぬふりをせずにその場でしっかりと対応することが大切だと改めて実感させられました。

DbC(Design by Contract)とは、ソフトウェアモジュールの権利と責務を文書化し、プログラムの正しさを保証するための簡潔かつパワフルな技法のことです。

ここでいうプログラムの正しさとは、要求された以上のことも、以下のことも行わないというものです。DbCを提唱したMeyerはDbCを実行する上で、以下の想定と確約を解説しました。

この機能を呼び出す前に必要な要求のことを指します。事前条件に違反している場合には、この機能を呼び出してはいけません。そして、適切なデータを引き渡すのは呼び出し側の責任になります。

この機能が終了した後にその機能を保証する内容のことです。事後条件があるということは、この機能が正常に終了することを意味しています。

クラスが呼び出し側に対して、常に真になることを保証する条件です。

ソフトウェア開発におけるコンポーネントベース開発によって、テストのしやすいコードを書くことができます。

初期の段階からソフトウェアの中にテスト機構を組み込んでおき、ソフトウェアを接続する前にテストができるようにしておくことが大切です。

先程のDbCにあった契約が遵守されていることを確認するテストを用意しなければなりません。

これはコードが契約に合致しているのか、そして契約の意味が我々の考えている通りのものなのかをいう2つの意味を含んでいます。

DbCは最近になるまで知らなかったが、TDDを実践していく中でDbCという手法を学びました。本書を通してDbCについて理解を深めるきっかけになりました。