日々の破片

_ 小出しかつメモ（まとまってない）

で、この1年ほど、昼間は、ばかばかしいほどたくさんプログラムを書いている。思うところあって、仕様だけ設計なし（といっても、実際は仕様を切った、あるいは見た瞬間にほとんど設計は終わってしまうんだが−後述）ユニットテスト−リファクタリングをクソマジメにやると、どのくらい効果があるのか無いのか、比較的規模の大きいプロジェクトを専横できるのをいいことに実行したからだ。

このやりかたは、とんでもないや。すさまじく消耗する。とにかく、ほとんどずーっとプログラムを書き続けだ。たまに文書を書くとほっとするくらい。

大きなサイクルを半年として2度回して、小さなサイクルだと日に3回から、2ヶ月に1回までいろいろあり。いずれにしても、テスティングプログラムが必須だということは、よぉーく、わかった。無しではまったく無意味だ。って言うか、「必須」と最初に決めといて良かったよ。もちろん、CVS（じゃなくても良いが構成管理システム）も必須ですな。

確かに、60年間不変なシステムアーキテクチャでかつ30年間不変なソフトウェアであれば、設計書は必須だと思う。なぜならば、30年経過すれば、元のソースの記述言語を読解できるメンバが消えてしまっていたり、ソースファイルを紛失してしまうことだってありえるからだ。これは、2000年問題発生時のCOBOLプログラマ問題で、ある意味証明できているはずだ。2000年問題は、修正問題だったわけだが、別の切り口から考えても、メインフレーム（PL/IまたはCOBOLのソース）から、システムアーキテクチャは変えずに、オープン系（たとえばUnixでCとかJavaとか）へソフトウェアを移行するっていうような場合だって、当てはまる。移行が完了するまで、元のシステムを熟知したプログラマまで含めてビジネスユニットが保持しているってことは、あまり考えられない。すでに、代替わりしているわけだから、ソースが残っていても、糞の役にも立たない（というのは言い過ぎ）。

では何が役に立つかと言えば、仕様書だし、さらに細かなビジネスルールが満載されている（はず）の、設計書ということになる。

だから、そういうシステムが存在することろでは、フローチャートみたいな設計書（詳細仕様とか実装仕様とかと呼んでもいいんだけど）が必要になる。別の言い方をすれば、人間が読める形式のソース（メタプログラムまたはメタソース）が必要だということだ。

ところが、考え方を変えて、システムアーキテクチャは変えずに、ソフトウェアのライフサイクルを数年（せいぜい5〜8年）というスパンで更新することを前提とすれば、プログラムソースをそのまま設計書として利用できるはずだ。

このことは、(1)設計書あるいは実装仕様書といった文書の作成期間を0に抑制することによる開発サイクルの短縮　(2)可読性が高いソースの必要性の周知徹底 (3)パターン、イディオムの否応ない使用の強制（っていうか、このあたりがカタログ化されているから設計を新たにする必要はないと言っても良いのだが、それは個々のプログラムの構造とかに関してだけで、ビジネスルールについては別問題−こっちの解決手法はコミュニケーションということになる、というか、現時点では他の方法論はわからない） といった複合的な効果が期待できる。それを補強するためにCVSによるソースへの共通アクセスを可能とした上で、コミット時のユニットテストの強制（通らなければ、コミット禁止、インターフェイスを変更したりした場合、関連しそうなソースの修正の強制−というより許可。誰が修正しても文句言うな、ソースは全員のものだ−の徹底）といった手法を導入する必要が、逆に出てくる。

XPのプラクティスというものも、きれい事を抜けば、ようするに、そういうことだ。もちろん、細かな設計書がないんだから、作成するシステムの5W1Hをメンバーによーく伝えることは必須どころの騒ぎじゃない。現実世界じゃ山のように出てくる個々のプログラムの例外的な状況に対して、どうすべきかの方針がそこで明確になるからだ。

でも、問題点はあるな。実感として8人規模までだ。それを越える場合には、メタソースを作成して放り投げてソースに翻案させていかなければ、多分、追いつかない。メタソースの記述とソースの記述、どっちが量的規模が少ないかだが、ユニットテストやリファクタリング（すべき余地）がそもそも含まれないメタソースのほうが、生産性は高いと考えるべきだろう。

後は、副官次第ってことだが、1)勝手に情報をどっからか入手する技術 2)どうでも良い部分を自分で抱え込まない手抜き精神 3)できれば1)と2)によって利用できるものを利用してしまう能力 4)一々お伺いを立てなくても与えた情報から自分ですべきことを判断できる決断力 ってとこだ。

これは副官だけじゃなくて、実際の作業者（と言っても人手が足りないから助っ人を除く全員なんだが）についても求められることで、たとえば、XMLで記述された設定ファイルを参照しながら適当な処理をする、パフォーマンスは重視されないかわりに、比較的変更が多いと予想されるプログラムを作れ、と言ったらいつの間にかRuby＋REXMLでスクリプト書いているような人間が居ると非常に助かる。ありがとう。

_ ユニットテスト

ユニットテストの良い点は、コンポーネントを利用するアプリケーションのテストプログラムが、コンポーネントにとっても最良のテストプログラムとなるという点で、ようするに、テストの機会が増えていく点にあるということもわかった。システム全部を通せば、静的な結合テストの相当範囲をカバーすることができるということだ。