組込み徒然草

超短期の案件の「事後」作成の検査仕様書・成績書対応が完了しました。

結果としては更にバグを発見できたので、やった意味は充分にありました。 メモリ破壊などの致命的なバグも含まれていたので、ろくに検査もせずに納品してしまうと後悔するところでした。

結果的には予定見積もり工数を超えることになりました。 発注側も受注側の私も見積りが甘かったということです。 やっぱり、どんなにコード量が少なくても検査はしないと駄目ですね。 プログラミング量だけで双方とも見積るべきではありません。

例えば1日でコーディングしてほぼ想定どおりの動作をしていたものを細かにデバッグのために16進ダンプなどを行って確認するとコーディングの数倍の手間がかかります。

今回の案件では扱うデータが膨大だったために処理はそんなに多くないのですが、繰り返し処理でのいくつかのチェックうポイントを確認する必要があったので、後からやるのはいやになるほど面倒でした。

でも、一通り動作を確認できたので、自信を持って納品できます。

一般手法かどうかはわかりませんが、一人や少人数で開発を行う場合は「ひとり時間差レビュー」という方法をよく使います。 つまり、設計やコーディングなどを一度完了させた後に忘れるか忘れないか位の時間を置いて、再度見直すのです。

コーディング中の自分にとっては正解で意味のあった処理が時間を置いて見直すと「なんだこれ」とか「なにやってんの？」と思うようなことをやっている場合があります。

検査仕様書を書くのも同様で、コーディングとは離れた視点で項目を洗い出すので、仕様を整理して書くという行為そのものにレビューの効果があったりします。