<< 実践 ICONIXプロセス : コードを書く視点 | main | 実践 ICONIXプロセス : 警報が鳴っている >>

実践 ICONIXプロセス : レビューと修正がたいへん?

ICONIXプロセスのガイドブック「ユースケース駆動開発実践ガイド」を読むと、

・コード内に閉じたレビュー
・設計とコードの同期のレビュー
・ユースケースをコードで実現しているかのレビュー

を徹底的にやるように書いている。

時間がかかりそうで、実践的ではない?

私も最初はそう思いました。
実際にやってみると、やっぱり時間がかかり過ぎる。
指摘事項は多いし、問題点を見つけたらコード修正だけでなく、モデルの修正やプロセスの改善までやるのは、負担が大きくとちょっと現実的ではなかった。

でも、今は、状況は改善してきています。
改善のポイントは以下の3点でした。

コードを書く前の作業

ドメインモデル、ユースケースモデル、要求レビュー、ロバストネス分析、予備設計レビュー、アーキテクチャ、シーケンス図と詳細クラス図、詳細設計のレビュー。

これらの作業が雑だったり、手抜きだった結果が、結局コードレビューに集中した。

コードになると、いろいろ意見がでてくるが、上流のモデルの時点ではメンバー間でのレビューが少なく、またレビューの効果が少なかった。

上流の要件定義、分析、設計、そして各工程でのレビューについて、もう一度、本を読み直しながら、基本事項をひとつずつチェックしました。

最初の頃は、コード書きやコードレビュー段階で発見していた問題を、早い段階で発見・修正できることが増えました。結果としてコードレビューの時間がだいぶ減少しました。

技術知識と約束事の共有

アーキテクチャ(特に採用したフレームワーク)やコーディングスタイルについて、メンバー間で共有する知識や約束事が増えるにつれ、レビューの時間がだいぶ減りました。

コードレビューは、こういう技術知識や約束事に共有には、かなり効果的ですね。

XPのペアプログラミングの目的の一つもこういうことなんだと思う。

最初は、時間がかかって非効率に感じるけど、技術知識や約束事の共有には効果があるので、最初のうちはコードレビューにかなり時間を割くべきだと思います。

レビューのテクニック

いくつかレビューのテクニックがあって、それを徹底することで、レビュー時間の短縮と効率アップができました。
例えば、事前に必ず読んでおく、問題点の発見だけで修正の検討はしない、修正結果を確認するフォローアップミー手イングをやる、などですね。

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
 123456
78910111213
14151617181920
21222324252627
28293031   
<< May 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM