Print Shortlink

内部レビューとバージョン管理

Subversion実践入門:達人プログラマに学ぶバージョン管理の続き。

どうも読んでいて引っかかったことが一点。バグ修正のタイミングについて。

以下、「1.1 バージョン管理の実際」より引用。

問題を絞り込むために、Fredはまずテストを書いた。

本番障害の調査手順だが、ここではまずテストコードを書いている。今までの自分の経験からすると、まずは本番の画面を叩いてログを見て…という流れになりそうだが、何よりも先にテストありきの前提で調査を行なっている。

…、コンパイルして、彼のテストで問題が発生しないことを確認した。そして、簡単な健全性テスト(sanity test)としてテストスイート全体を再実行してから、修正済みのコードを中央のバージョン管理システムにチェックインした。

やはり先に書いたテストコードありきという前提。ソースを修正してテストケースを書いて…という流れではない。どうもアジャイル開発を前提としている模様。

何が気になっているのかというと、どのタイミングで内部レビューを行うのかということ。内部レビューというと従来のウォーターフォールモデルの開発手法の基本であり、本書で書かれているアジャイル開発とは相反している。ただ、今でもウォーターフォールモデルの開発は多く、ここにバージョン管理を当てはめなければならない。どのタイミングで内部レビューを行うのか、それはチェックイン前なのか後なのか、単体テストの実施前なのか後なのか、そのあたりが読み取れなかった。というか書いてないけど。

全部のパターンを挙げて網羅的に考察したりはしないけど、単体テストも通っていないようなコードを内部レビューするという前提が誤っているような気がしないでもない。まともに動かないようなコードをチェックインするのもどうかと思うし、かと言ってチェックインせずにコードをレビューするのも何だし。でも単体テスト仕様書のレビューは当然必要。最適解は何だろう。

内部設計で内部仕様書と単体テスト仕様書を作ったら、以降は単体テスト完了まで担当者に丸投げして、ソースコードと単体テスト結果を同時にレビュー?ここまでの要員スキルを担当者全員に求めるのは難しいような…

This post was written by

くれす – who has written 67 posts on その他大勢チーム.

Web系の開発やっていた(過去形)けど、仕事がなくていつの間にかPMOになっていた。開発チームの進捗遅れや品質の悪さに対して上から目線でケチを付けたり、管理業務がボタンひとつで出来るように機械化したりするのが生き甲斐。定量的なことしか言わないので嫌われること請け合い。どうでもいいですが、男の子なのに腐です。えっ…なにそれこわい。こんなこわい男の子は食べてしまえ。二次元も三次元もおいしいです。

Send an Email

関連記事

  • 関連記事はありません。

Leave a Reply