<< 前 ホーム 次 >>

bakaid: 20080523

確かに『Code Complete 第2版』はいい本なんだろうけど、
網羅的すぎて、オレたちには合わない、古典的なやり方も
数多く紹介されている。

たとえば、p.118、『5.3.6 変更の可能性が高い領域の
特定』。こういうギャンブルは、オレたちはやらない。
可能性というからには、予想がハズれることがあるわけだ。
予想が当たれば万々歳だが、ハズれたらどうする?

どんなものでも、コードを書くにはコストがかかる。
予想がハズれたら、そのコストは回収できない。

p.91にタコマ海峡橋の話が紹介されている。それを
アナロジーとすれば、オーバー・エンジニアリングも
許されるということになってしまう。けれども、
オレたちはソフトウェアを作っているんだ。橋は一度
作ってしまえば、それが壊れない限り、作り直すことは
難しい。補強するという手段は残されてはいる。それでも、
ソフトウェアほどラディカルに作り変えることはできない
だろう。

オレたちはギャンブルはやらない。現状を良くするだけだ。
その良くするための指針が、繰り返しになるが:

* lots of little pieces
* once and only once
* low coupling, high cohesion
* rate of changes

ということになる。これらの指針は、可能性のためでは
なく、今現在のシステムを良くするためのものだ。

そしてなぜか、この指針を守ると変更に強くなる。
理由は単純で、この方針は結局モジュール化を促して
いるに外ならないからだ。

結局、『変更の可能性が高い領域の特定』なんかやる
必要はなく、この指針を守るだけでいいっていうことに
なる。それが基本や原則の持つ強みだ。

--

蛇足だけど、rate of changesは可能性じゃなく、現実の
話。実際に手が入ることの多いところは切り分けましょう
っていうこと。『なんとなくこのへんは変更されそうだ』
という曖昧な想像の話ではない。

本家Permlink

<< 前 ホーム 次 >>


Copyright © 1905 tko at jitu.org

バカが征く on Rails