日々の破片

_ XPとの出会い

そりゃ助田さんだ。その意味ではRubyとの出会いがきっかけではあるのだが、助田さんがRubyUnitを題材とした本を書かれていて、それに乗る形になったのがXPとの出会いだったのだ。

Rubyを256倍使うための本 極道編(助田 雅紀)

もっとも、極道編はXPの本というよりはテストファースト（という手法。この時点ではまだTDDとは言わなかった）の本なのだが、なぜか帯にはしっかり

RubyUnitでeXtrem Programmingを極めろ

なんて書いてあって、確か助田さんはそれはちょっと違うんだけど（ネゴシエーション）まあいいかあというような感じで、日本で最初に出版されたXPの本となったのであった。

で、さらにいろいろ考えて見ると、石井さんの功績も非常に大きいのだと思う。というか、どうテストファーストを実践するかのノウハウという点に関して石井さんのコンテンツはとても価値があると僕には思える。以前、Java Worldの巻末特集に石井さんが書かれたJUnitの活用方法についての記事があったが、これも非常に良かった。

やっぱり、実際に使っている人間の言葉は重いよな。

で、自分のことに戻ると邪道編が2000年の7月に終息したから、したがってXPを知ったのは1999年ということになる。

Rubyを256倍使うための本 邪道編(arton)

（まあ、ここでの話題とは一見関係ないが、一応、貼っといてみる。WMIを使うとことかは今頃になって有効に読めるかも。ただしRuby側がちと古いけど）

で、ここから回想に入るのだ。

1994年がWindows95だとすると、Win32cを実装したNTはNT3.51で、ここからSTAという方法でCOMのマルチスレッドでの利用が可能となったわけだから（＝まともに使える−−わけないんだが−−インフラとして）、大体そのあたりから、僕はCOMを使った開発を開始した勘定になる。

でインターフェイスドリブンなオブジェクト指向の日々に入っていって、だんだんわかってきたことがさすがに1999年には溜まっていた。

それはたとえば、API（インターフェイスでも利用プログラム界面でもいいんだけど）重要とか、動的なロード重要とか、そういったこと。今じゃ常識の感もある実装継承は難しいとか、再利用性は神話ですな、とか。そんな中の1つに、もう設計についての文書は不要だな、という実感もある。早い話、APIだけ決めれば後は放っといてくれ、というか、ソース読めというか、そんなところだ。――これはミドルウェアだからAPIなわけで、もっと上層なら要件定義ということになるのだと思うのだが。

理由はたくさんあるが、Windowsの比較的新しめのインフラ使うから、毎日がバッドノウハウの探索と発見の連続で、プログラム作る前にどう作るかなんて決定できねーよ、というのもあるし、幸か不幸かCOMはインターフェイス継承しかないから内部構造は実装側で工夫の余地があるわけで（このあたりでストラテジとかフライウェイトとかメメントとかの再発見をしたりするんだが、それでもシングルトンとかファクトリメソッドパターンとかは自分で発見しなくてもどこからか仕入れて使ってた。とは言えGOF本買ったのは第2版-1999-からだからその時点ではGOFを読んだのではなくおそらくMSDNのアーティクルから仕入れたんだとは思う）で、ご多分に漏れず外側のインターフェイスで合わせとけばいいわけで内側ではリファクタリングかけたり……だがここにはテスティングフレームワークが無かったのであった。しかし、それはこの時点ではまだ問題を発生「させて」はいても、気付いてないんだからまだ問題ではない……というわけで、APIの文書作るから後は放っておいてくれ、でなきゃやってられないよということになるのであった。

だってさ、MSDN見てこのAPI群使うぞと決めて実装すると、実はタイミング依存のNT3.51のバグを突付いて、結局全然違うAPI群を使うように大改造（だから、TDDというような発想がないから一応動くようにしてからテストするんだって）でも、インターフェイスは同じだからOKね、とかが山のように出てきたら馬鹿馬鹿しくて設計書とか書けないよね。だから完成してから書く？ と言ってる間にまたWindowsのバグを突付いたから（ただし実は4:6くらいでこっちのバグ――大抵はAPIの使い方の間違い――のほうが多かったり）修正ですか、そうですかな状態なわけだから、書かないで済ませられるのはなんとなくそういったことだ。とは言え、実際に書かないわけにはいかない（文書の提出義務とかあるわけだし）ので最初にインターフェイスと機能の上っ面だけを書いて、データフローとかつけといて（ミドルウェアではこれは結構重要だったり）、あとは何も無し、インターフェイスの内側は実装時に決定という書式で押し通すことにした。それが設計書かといわれると機能設計書＋インターフェイス仕様書ではあっても、実装については何も書かれていないわけでちょっと怪しい。要求定義メイルストロームを見ると、要求定義書群−機能要求＋機能定義を書いてるだけじゃんということであるな。

で？ そう、この状態にテストファーストとペアプログラミング、コード共有を追加するとほぼXPなのだ。ミドルウェアを利用するアプリケーションプログラマーとは否応なくオンサイト顧客、計画ゲーム、生々しいメタファ（じゃなくてずばりそのものだけど）、絶えざる修正（継続的インテグレーション−−バグ修正だけじゃなくて、今度はこれしたいあれしたいという要望は出てくるわけで。で、ふんふんと聞きながらAPI仕様としてまとめてそれはその場で文書化−−たまに手戻りするがパラメータの追加とか−−大した問題ではない）、設計の改善（何しろ、頻繁に修正が入るわけだから、これやっとかないと死んでしまう）、シンプルデザイン（いきなり大きく出るとWindowsのバグを突付いたときに即死だ）、小さなリリース（アプリケーションプログラマーが待ってるのだ）……

で、とりあえあず、今は立ち位置を変えたが（コードの共同所有ってのは職人技が必要な領域だと難しい（気難しい？）ってのはあるよな）、これに無事、コード共同所有とテストファーストを付け加えることができたと思いきや、ミドルウェアだけじゃなくなったもんで、設計書のいんちきがばれていろいろあったりしながら、もうすぐ今年も終わりですな、と。

で、なんでこんなことを書いているのかというと、設計書書かないしねに疑問を感じたからだ。

おまいさん、プログラムを開発したこと無いね？ なんてことがないのは他の文書を読めば明らかだ。でもここで書かれている設計書というのが実装寄りの、つまり、僕が書いていられるかといって棄てたやつのことを指してるってのは誤読じゃなさそうだ。本当は、XPを見た時に僕の反応と全然違うから（でも、他の文書を見るとむしろものがわかってそうな人だし）どこから温度差が生まれるのかを考察するつもりだったのだが、いろいろ書いているうちに別のことになってしまったのであった。

でも、標準APIがあり、デザインパターンがあり、外部とのインターフェイスが決定されていれば、なぜ設計が必要なのだ？

というか、UMLスケッチってのは場合によってはするかも知れないけど。というかしてるが。でもそれはソースになった時点で廃棄だ。どうせその後変わるんだから。このあたりについては別の形で文書化したから、そっちをどうぞ。

後から読む人間に対してはクラス名にXxxxStrategyとかXxxxFactoryとかXxxxxSingleton（とはしないな。見りゃわかるからか）、XxxxStateとか付いてりゃわかるだろうし、わからんやつには触らせたくないな。でも、DecoratorとつけるかProxyとつけるかDelegatorとつけるかは未だに定説がなく、面倒なんでSAXからいただいたFilterで統一することにしたり。というようなのはコーディング標準だ。

まとめると、というか、とりとめなく書いているから最初の予定と全然違うことを書いているけどいいや。何しろ今日はシメトリクな1221な日だ。

遥か昔、半年くらいCOBOLでプログラム書いたときを思い出す。標準ライブラリが無い。だからビジネスロジックの実装とユーティリティが混在したようなプログラムになる。だから、設計は必要だったように思う。なきゃどこから手を付ければ良いかわからなかったかも。ここではシステムは安定しているがインフラが不足しているため、プログラムの実装に設計が必要だったのだと思う。それにね、COBOLのビジネスロジックって読めないんだ。グローバルな世界だったから。77COBOLだったかな？ ちょっと忘れたが。っていうか、COBOLで思い出したが、ある程度の規模のプログラムでフラグ変数すらグローバルだったりすると、設計って必要だ。あれは読めない、確かに。その後はアセンブラだから裸の世界なわけでいろんなものを再発明しながら作るから設計書が必要だった。どんなに小さくてもデータベースマネージャを作ると成ったらそりゃ設計書は必要だ。ソフトウェアライフサイクルも10年以上を見るわけだし。

90年代中半以降は、違う。インフラがあるし、多層化のパターンも（黎明期ではあるがなんとなく）決まっているし、ユーティリティの外出しは明確になっているから、ビジネスロジック（データソースだったり、サービスだったりしても、そのドメイン−−出たー−−なんだからビジネスロジックで良い）に機能を入れればよい。かつ、どのインフラを採用するかはギャンブルだから事前に固く設計してもしょうがない。したがってプログラムの実装について事前に設計することは意味を持たない。メンテナンスの時？ 多分、その時はWindowsのバージョンが違うからやっぱり意味ないんじゃないか？ つまるところソフトウェアライフサイクルも比較的短いってのもある。

00年代。インフラがあり、多層化のパターンも決まっているし、GOFは常識となった。という状況の上で、チーム開発ってのをやることにした。アーキテクチャモデルは文書化した。これは必要だが、実装を縛るものではないし、縛らないように緩める場所は緩めてあるわけだし。インターフェイスはユーティリティとかストラテジのインターフェイスそのものなんかについてはJavadoc化している。で、やっぱり設計書はいらんな。でも書きたきゃ書けば良い程度の緩いルールとしては残しておく。でもビジネスルールの規定をどう文書化するかを怠ったのは反省点かも。

もちろん、1つのファクターとして、年月の推移でこっちの意思決定権がでかくなったから−これやれへいへいから、おら知らねを通して、おまいらこれでやりますがどうですかに変わったってのは一見ありそうだ。でも、多分、それは違うな。あと、今じゃ見ただけでモデル化できるってのはあるかも知れないが、それも重要ではなさそうだ。なぜなら、文書なしでもソース見てばしばし修正してコミットしてるわけだし、現実に。やはりインフラの差だろうと思う。インフラと言えばケントベックにしろマーティンファウラーにしろ出発点がSmalltalkerだってのは関係あるかも知れない。COBOLerからは出てきそうにもないのは言語が利用できるインフラの差ってのは大きそうだ。つまりアジャイル＝富豪的ということでどうですか？ 少なくても内部的にはインフラとしての知識が必要な気はするな。知恵も含むかも。それはハッカースタイルかな？ いや普通のプログラマの勘さえあればすぐに順応できる範囲だろう。あとIDEで補うこともできるし。

でもまあ振り返って考えてみれば、その時代その時代にそれなりのインフラがあるところで仕事してるわけだから、結構、恵まれてるのかもとか。でも来年のことはわからない。ああ恐ろしや恐ろしや。

なんか、妙に個人的なことを書いてるからバカが往くにしてしまうかも。