割れた窓を放置したビルはすぐスラム化する。
これはどっかの国で行われた実験結果らしいです。
人間、綺麗なところを汚すことには抵抗がありますが、汚れている場所はとことん汚してしまうらしいです。
同じことがシステム開発にも言えると思います。
「ちょっと汚いけどまぁいいか。」
を繰り返しているうちに
「汚いけど、まぁいいか。」 => 「ぐちゃぐちゃだけど、まぁいいか。」
とどんどん汚し、最終的にすごく汚い(直交してない、高結合度、No DRY、コメントとソース乖離しまくり、メンテ不可能)システムが出来あがります。
じゃあ、どうしたら「割れた窓」を生み出さない開発ができるのか。
色々試した結果
- 辛いけどDRY順守
- テストコードを書く
がすごく効果あると思います。
- DRY
DRY順守すると必然的にプログラムをできる限り「短く」書くことが求められます。
つまりコード量が減ります。バグが減ります。修正も減ります。
「まぁ、同じような処理だけど、ちょっと違うからコピペ＆ちょろっと修正でいいか。」
を我慢して頭を使ってDRYです。結構、大変ですが・・・
- テストコード
テストコードを書くことで、直交しているプログラムになります。
なので、修正が入っても修正ポイント以外に影響はありません。
当然、使いづらいインタフェースを発見したら、すぐにリファクタリングします。
「っち。使いづらいIFだな。おい！これ作ったの誰よ？ん？俺か。。。」
自分が作ったプログラムの使いづらさに心が折れそうになりますが、こういうためのテストコードです。
リファクタリング時、ついついリファクタ以外のこと(機能追加とか)したくなりますが、痛い目を見るのでやめたほうがいいです。
- DRY
- テストコード
で１つ１つのプログラムの品質が格段にあがります。結果、システムの品質も上がります。
ただ、はじめはすごく時間がかかります。
ポイントはプログラムとテストコードを同時進行すること。
プログラム作りきってからテストコード書くと大変です。心が折れます。楽しくないです。
プログラムちょっと書いたらテストも更新。
慣れてしまえば、テンポよく開発ができると思います。
後、ビルド時に自動テスト。
手動で都度全ケーステストは無理なので、ビルドツールに任せるのが吉。
