読者です 読者をやめる 読者になる 読者になる

methaneのブログ

このブログに乗せているサンプルコードはすべてNYSLです。

成果物なんて役に立たない

組み込みでは、ソフトウェアの品質は、プログラマが制御対象についてどれほど理解しているかが大きく品質を左右する。*1
キャッシュを知らないプログラマがDMA転送を利用するプログラムを書いたら、「ごく希にデータが化ける」ソフトができあがることがあり、その頻度が少なければシステムテストを通って出荷されてしまう可能性だってある。
コレに対処するには、仕様書をじっくり読み、最低限「自分が何を知っていて何を知らないのか」を理解する必要がある。

でも、実際のソフトウェア開発で、ハードの仕様書を読むなんてフェーズはない。1週間かけて仕様書を読んだとして、「この1週間のアウトプットは?」とか管理者に言われても、アウトプットなんて何もない。インプットこそが成果だからだ。「判ったことをドキュメントにしろ」?はぁ?そんなに仕様書の劣化コピーが欲しいの?

ほかのフェーズでも同じ事が言える。設計フェーズでは、できた設計が重要で、それが頭の中にあるのか、裏紙にメモ書きされているのか、開くのに10秒かかるWordドキュメントになっているのかは大した違いではない。設計フェーズを「設計書を作るフェーズ」と定義すると、本質から大きく外れる。設計書のフォーマットを決めようモノなら、品質/工数のコストパフォーマンスは大幅に下がる。

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

*1:これは一般的にも当てはまる。Javaプログラマなら、APIJavaのメモリモデルやらの仕様を理解していなければ正しいプログラムは書けない