紫だちたる雲の細くたなびきたる blog

春はあけぼの(をかし)

オフショア開発

今回のプロジェクトが火を噴いた原因の一つに中国に発注した部分の品質が最悪だった事が挙げられる。というより品質以前の問題。仕様がちゃんと伝わってないのだ。新しい部品を使わないと規約違反だよって情報すら伝わってないのだ。これは完全に我々のチームの管理責任。メールや電話だけではダメなんだと思う。誰か中国に常駐して毎日チェックを入れる必要があった。

あと、オフショアからは離れるがソースレビューよりテストケースのレビューの方がずっと大事である。しかしこれが皆無だった。ソースの可読性も大切だがそれはプログラムが動いてからの話。テストを通らないプログラムなんてレビューするだけ無駄である。仕様を満たしてないテストなんてテストするだけ無駄である。テストがちゃんと仕様を網羅したものになっているかが一番重要なのである。
必ずこの日までにあげろなんてやり方で作られたソフトウェアの品質なんて必要最低限の共通部品だけで後はプログラマの裁量で余裕を持って作られたソフトウェアに遥かに及ばないの火を見るよりあきらかだ。だってテストの消化が主目的だから修正後の再帰テスト(修正によって既存のプログラムに異常がないかどうか全てのテストを再実行する事)なんてほとんど無理なんだから。
僕はJUnitを用いてテストを自動化する手法を無理矢理にでも取り入れたかった(一部取り入れた)けど、共通部品が環境依存の部分を持っていたので、せっかくEJBビジネスロジックの部品化をしたのにJUnitを活用できなかった。でも2ヵ月くらい前の日記に書いたやり方で無理矢理テストの自動化をした部分の品質は相当高いと自負している。仕様変更による修正と画面JSP(テストを自動化できない部分)以外ではバグは出ていない。データ不良による障害は上がってきたけど。