Yellow between Red and Green

id:yuki_neko_nyan さんや id:moro さんが言う「仮実装に対するマーカーが欲しい」というのは実際の開発に置ける利便性という意味では分からないではないんだけど、捉え方は私の考えとは違う。

つまり、こういうことだ。

「仮実装は仮ではありません」

仕様は、少なくとも機能要件を満たすための要素に関しては自動実行可能な形式で書かれているべきだと思っている。だから、t-wadaさん曰く、「redフェーズは仕様の定義段階」なんでしょう。

仮実装でGreenになっているというこという状況は、その仕様を満たす極めてシンプルな実装ができたということ。定数を返しつづけるようなメソッドを書いてGreenになってしまうなら、そのモジュールは今はそういう仕様である筈だ。 だから、そこで言うべきは「仮実装に対するマーカーが欲しい」ではなくて「仕様の定義の不足に対するマーカーが欲しい」だと思う。

些細な言葉の問題ではあるけれども、それこそTDDに対するBDDのように、言葉の違いは大切だ。仮実装を「仕様は不足しているかもしれないが、その仕様に対する適切な実装ではある」と捉えるから次の三角測量に続くんではないのか? 仮実装・三角測量が複雑な問題を噛み砕く手段となるのは、仕様に対する最小の実装を重ねながら段階的に要件を満たす仕様に至ることができるからではないのか。

使い捨てコードや理論レベルの試行錯誤の場合はともかく、メンテナンスしていくコードの場合は私はこう言っている。「仕様は実行可能に書け。たとえそれじゃ売り物にならなかろうとも、Greenならばそれが仕様です」

Microsoftみたいだけど、でもMicrosoftのあの有名なセリフも、私はちょっとしたエピソードを聞いてイメージが変わった。つまり、Windows OSにおける仕様とは、QA担当が書いたバグ票が再現しなくなり、設計担当が書いた動作定義に反する動作をしないということである、と。それ以外の実装の詳細の全ては実装担当者に任されている、と。で、Joelが言うには、それをクリアしている限りは部屋にテディベアを積み上げようとゲームしていようと自由だけれども、ビルドの時間になって仕様が満たされていなかったらビルド担当者が怒鳴りこんでくることになるらしい。

ということは、やはりWindowsの変な動作はMicrosoftの内部定義においては仕様が不足していたのであってバグではないということになる。だって、またその現象を起こさないように定める仕様がなかったんだもの。だからってそれを社外に向けたドキュメントに書くかどうかは別として。

担当が事細かに分かれているMicrosoftのやりかたは確かにアジャイルじゃないかもしれないが、仕様に関するこの考え方は良いものじゃないだろうか。だから、私は思うのだ。必要なのは、仕様の不足を忘れないでおく仕組みである。仮実装は現状の仕様を満たすもっともシンプルな〈従って潜在的なバグも少ない〉実装なのだから、それは理想的な実装であって問題視するようなものではない。