Chat (Lingr.com)
Informaiton
Daily
Column
- MySQL日本語の旅(5/1)
- アクセス向上秘伝(5/9)
- 一風変ったHaskellλ門(6/13)
- SICP Answer Book (5/31) 問題3.26追加
Zope Solution
Extra
アーカイブ
OSS案内所
Site Info
関連リンク
「XPマンセーッ!」
毎度、XPオタクのますくです。
机の上に散らばるテスト仕様書...
一度閉じたら、次に開かれることがほとんどない設計書入りキングファイル...
非常に論理的で説得力のあるプレゼンテーション...
これらの共通点は1つ。
どれだけしっかり作っても、ドキュメントは動作しない。
最近では、MDA(モデル駆動アーキテクチャ)のように、実行直前まで持っていけるドキュメントの類も出てきたが、そういった仕掛けがない限り、ドキュメントは動作しない。
どんなにすごいプレゼンテーションも設計書も、コードがなければITシステムとしては動かない。
だから、実際に動くコードにしっかり時間を使うことが、理にかなっているはず。
しかし現実は、動かないドキュメントを要求し、動かないドキュメントを一生懸命作る。
その結果、コードやテストに割く時間は限りなく削られる。
おまけにテストが手作業だと、コードやテスト仕様書に修正があったり、コードに障害が発生すれば、最初からやり直し...
これでは、幾ら時間があっても、足りる訳がない。
とてもじゃないが、品質の高いITシステムは作れない。
では、どうやってこれらの障害をXPは克服するか?
ようするに、ドキュメントのような動かないモノは必要最小限そろえるようにして、テストのような動くコードで表現できるものはできるだけコード化しておくこと。
たったこれだけで、品質は驚くほど向上し、障害や手戻りが発生しても、最小限のコストで処理することができる。
最初は、慣れないことに戸惑いながら、よちよち歩きをしなければならないが、そこで支払った分は幾らでも回収できる。
非常に割のいい投資だ。
では、これを行うタイミングはいつか?
できるだけ最初の段階がいい。
勝負毎は、たいていスタートダッシュで決まる。
とはいえ、途中から気付いても遅くはない。
気付いたときが、ダッシュする最適なタイミングだ。
There is no comment.