SSブログ

ソフトウェア開発組織が持つべきカルチャー 008 [ソフトウェア開発組織が持つべきカルチャー]

コードをレビューする

最近では、コードをレビューすることの重要性は多くの書籍で述べられています。しかし、組織によっては「レビューを行った」という事実が重要視されて、「質の高いレビューが行われた」ということにほとんど関心が払われていない場合があります。そうなると、実際にシステム全体を結合テストすると、非常に初歩的なコーディングミスで障害が発生することになります。

1999年の頃だったと思いますが、2週間以上調査された不具合の報告会に出た時に原因が「変数の初期化忘れ」というものでした。それで再発防止策として何があるのかと聞かれて、コードをレビューすれば良いのではと回答したら、「じゃ、ガイドを書け」と上司から指示されて、「Code Review Guide」を書きました。

当然、ガイドを書いただけではレビューは定着しませんので、ガイドの教育を多くのエンジニアに行い、実際のレビューを私自身が行いました。当時、C++言語での組込開発が始まることもあって「C++ Coding Standard」を書いて、さらに「Memory Management Library for C++」「Thread Library for C++」と関連するライブラリの設計も行いました。そのようなガイドやライブラリを実際に使用する開発チームに対しては、2000年の後半から2002年初め頃まで、ほぼ専任のレビューアとして現場でレビューを行っていました。多い時には、週に4日ぐらい一日中レビューということありました。

今日では、フォーマルなレビューからペア・プログラミングを通してのレビューなど様々なレビュー形式があると思います。しかし、重要なことは、コードの読みやすさ、エラー処理、防御的プログラミングなど様々な観点からコードがきちんと書かれているかをレビューすることです。

特に初心者のコードは徹底してレビューする必要があります。そうでなければ、先輩達が経験してきたであろう間違いをもう一度実体験することで、結果的にプロジェクトの開発期間を延ばしたり、デスマーチを引き起こしたりする場合があります。

たとえば、C言語でローカル変数のアドレスを関数から返したり、他のスレッドやタスクに渡した場合にはどのような挙動になるのかは不定です。それが原因で発生する障害の調査には時間がかかったり、仮に障害が修正されても、QA部門によりバグ管理されて、そのためのバグDBの更新、ソフトウェアの再リリース、QAでの再確認という追加工数が発生して、結果としてプロジェクトの工数を増大させてしまいます。一方、開発内でのレビューでこの程度の初歩的な誤りは指摘して修正していれば、将来プロジェクト全体に余分な追加工数を発生させることを未然に防ぐことができる訳です。

ソフトウェアの品質を上げると同時にプロジェクト全体の工数を減らすには、きちんとしたレビューに工数をかける必要があります。しかし、現実は「品質の作り込みよりスケジュール優先」ということで途中の中間マイルストーンは守れても、結合テストに入ると多くのバグを出してプロジェクト全体のスケジュールを延ばしてしまうソフトウェア開発が多いのではないでしょうか。

ソフトウェア開発のスケジュールでは、いい加減な開発でも結合テストまではスケジュールが守れたという「奇跡」を恣意的に起こすことはできますが、品質の悪いソフトウェアでは結合テストの終わりのスケジュールを守るという奇跡を起こすことはできません。

※ Robert Martin著の『アジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技』の付録には「奇跡」の面白い話が掲載されています。

nice!(0)  コメント(0)  トラックバック(0) 

nice! 0

コメント 0

コメントを書く

お名前:[必須]
URL:
コメント:
画像認証:
下の画像に表示されている文字を入力してください。

Facebook コメント

トラックバック 0