« TestLinkを受入テストで運用する方法 | トップページ | メトリクスでソフトウェア品質を見える化する »

2009/12/13

コードレビューは緩いペアプログラミング

記事は古いけど、気付いたことをメモ。

【元ネタ】
【ITpro Challenge!】「高い生産性を実現する『ハッカーのソフトウエアエンジニアリング』とは」---Google 鵜飼文敏氏:ITpro

(前略)
 開発もなるべく小さな単位で行う。「設計しつつ実装,こまめにマイルストーンを設定する。小さい単位で動くものを作る。作る順序は後で使うものから。テストしやすさ,デバッグしやすさのために重要」(鵜飼氏)。
 既にあるコードを利用して,新たに作らないことも重要だ。「何を作らなくていいか,利用できるか,把握する。持ち駒が多ければ多いほどいい」(鵜飼氏)。
 Googleに入って感じたのはコードレビューの有用性だという。「コードレビューはとてもいい。ゆるいペアプログラミングのようなものでお互いのコードをチェックできる。ペアプログラミングは時間が拘束されるが,コードレビューならいつでもどこでもできる」(鵜飼氏)。
 デバッグの際はバグが存在する範囲を狭めて絞り込んでいく。あるいは狭めるようなテクニックをあらかじめ仕込んでおく。
(後略)

生産性:知識ゼロから学ぶ ソフトウェアテスト:So-netブログ

(前略)
個人的にはなるべく優秀な人を優遇したgoogleなりmicrosoft方式が気にっている。ソフトウェアプロセスも重要だと思うけど、優秀な人はCMMIがなんだかんだ言う前に日々現実的な作業改善をしている。
なんかペアプロよりこコードレビューのほうがいいというのも共感する。
(後略)

XPのプラクティスの一つであるペアプロは、二人の目による品質チェックと設計情報や技術ノウハウの共有という二つの利点がある。
実際の現場では、ペアプロを意識して実施されることはないが、本番リリース作業やDBメンテ作業など失敗が絶対に許されない状況では、自然にペア作業を行っている。
また、要件定義プロセスで複数人の設計者がペアで設計したり、初めてのアーキテクチャを使ってプログラミングする時は自然にペアプロしている。

しかし、ペアプロは同じ場所に二人同時に在席する制約があるため、疲れやすい。
コードレビューならば、非同期にペアプロできるのでいつでも可能だし、緩やか。

チケット駆動開発では、ワークフローを徹底すると、自然にペア作業になる。
例えば、バグ修正(PG)とバグ検証(テスター)、作業(PG)と承認(PL)、質問(開発者)と回答(設計者)、のように。

このプロセスをチケット駆動開発やコードレビューWebシステムで補完できないか?

|

« TestLinkを受入テストで運用する方法 | トップページ | メトリクスでソフトウェア品質を見える化する »

Agile」カテゴリの記事

チケット駆動開発」カテゴリの記事

コメント

コメントを書く



(ウェブ上には掲載しません)


コメントは記事投稿者が公開するまで表示されません。



トラックバック

この記事のトラックバックURL:
http://app.cocolog-nifty.com/t/trackback/49479/47014413

この記事へのトラックバック一覧です: コードレビューは緩いペアプログラミング:

« TestLinkを受入テストで運用する方法 | トップページ | メトリクスでソフトウェア品質を見える化する »