成果物なんて役に立たない「けど」

 思うところがありましたので、トラックバック。あまりまとまっておりませんが失礼します。
 http://d.hatena.ne.jp/methane/20060709/1152464497

 キャッシュを知らないプログラマがDMA転送を利用するプログラムを書いたら、「ごく希にデータが化ける」ソフトができあがることがあり、その頻度が少なければシステムテストを通って出荷されてしまう可能性だってある。

 思わずちゃんとflushしようぜ! とか思ってしまうワケなのですが、CPU転送とDMA転送の兼ね合いなどはあまり理解されていない事が多いですね。
 かといってAPIやらメモリモデルやら、ハードウェア特性やら、そんなものを一から全員に教育して身につけさせるようなフェイズは無いわけで何とかしなければなりません。
 一々みんながメモリのアドレッシングやVRAM領域のサイズや特性、特殊なデバイス周りの仕様を覚えてくれることなんてありませんもの。

 ハードの仕様書を読むなんてフェーズはない。

 無いのは同感ですが、実際組み込み系であればこれを行う必要は絶対にあり、そのアウトプットはそれらハードウェアの特性を「理解していない人間には」ひた隠しにする「環境(ラッパー)構築」になると考えています。
 ここで行われることは、ハードにおいて出来ること出来ない事を選り分け、要件を満たすにはどの機能を用いたらよいか精査することで、個々のプログラマがその担当部において、何を理解し何を理解しておかなくても良いかを取捨選択すべきフェーズだと思います。

 僕もハードの仕様書と向き合う事は幾度かしましたが、すべてのプログラマにドキュメントを渡して読ませても理解度に差があるので、読んで理解するのは主要な人物だけでかまわないと考えています。あとは担当部だけ判っていれば何とかなるものです。

 ハード上理解できなければ勝手に触るな、というルールにしておきこちらで考える最低限の効率を発揮するようにラップして使わせる、実装の前にそのためのフェイズは必須だと考えています。
 こうしていく中で、「個々が完全に理解していないので」最高の効率も出ませんし極限までの高い品質に持って行く事もできませんが、少なくとも「担当部だけは理解している」ので工数を減らす事にはなると考えられます。

 そして、設計フェイズは自分は「現状の設計を知識として共有し理解するフェイズ」と考えています。結果としてソースコードだけが設計の成果物として出力されていくだけだと理解度が一辺倒にはならないので「足並みを揃え知識共有する為に必須なフェイズ」なのではないかなと考えている訳です。

 結局、ソフトウェア開発において信じられる成果物は動いてテストされたプログラムだけなのだ。

 言わんとしている事は納得しますし、重要な事実でもあると思うのですが、実際のソースコードの意図、理屈を「理解する為の力」は個々によって様々ですので、何らかのソースコード以外の信じられる「成果物」を構築しなければならない、と考えています。

 それって、何だろ、というと、何でしょ、ってなるんですけれども。
 自分がやったのは、「とりあえずこれだけ見れば判るよ図」「触っちゃいけないのはこことことだよ図」「気にしてはいけない領域図」な感じですね。