コードレビューの歴史
コードレビューの歴史に関して良い記事があったのでメモ。
【元ネタ】
コードレビューいろいろ - steps to phantasien
コードレビューは非同期ペアプログラミングとも言える。
二人の目を必ず通すことで、ソースの品質をチェックする。
ソースインスペクションを真面目にやるGoogle、MS: プログラマの思索
コードレビューはペアプログラミングの代替手段: プログラマの思索
コードレビューでよくあるのは、ウォークスルー。
コードレビューされる人が司会者となり、別のレビューアにコードレビューしてもらう。
ウォークスルーは、司会者によほどの力量がない限り、あまりうまくいかない。
一人の人の役割が大きすぎるからだ。
「Code Complete第2版―完全なプログラミングを目指して」のような本では、インスペクションが推奨されている。
インスペクションは、モデレータ、書記など役割分担がはっきりしており、事前準備の計画、議事録、レビュー後のチェックなどのプロセスが定義されている。
厳格なだけに実施するための準備が多いし、インスペクションの経験者がいなければうまく回らないだろう。
CMMやTSP、清水吉雄さんが提唱されているXDDPでよく使われていると思う。
コードレビューをサポートするツールは、Googleが自社開発のために作ったMondrianが一番有名だろう。
そこから各種のオープンソースツールが生まれた。
多分、ReviewBoardが一番有名だろう。
今なら、Gitと一体化したGerritが有名かもしれない。
コードレビューで多いスタイルは、コミット前のレビュー。
ReviewBoardではプレコミットレビューの機能が既にあり、充実している。
ReviewBoardでプレコミットレビュー: プログラマの思索
コミット後レビューで多いのは、Diffメール。
SVNにコミットしたら、その差分をメーリングリストに流す。
Diffメールを使うプロジェクトは今でも多いだろうし、Diffメールからコードレビューに発展する時も多いだろう。
コードレビューいろいろ - steps to phantasienの記事で面白かったのは、Bugzillaに既にパッチの差分ファイルを添付することでコードレビューする機能がプラグインとして提供されていたこと。
BugzillaのプラグインSplinterを使うと、差分表示してくれるらしい。
Splinter ? patch review for Bugzilla ≪ fishsoup
また、Bugzillaにはパッチのレビューのステータスを管理する機能もあるとのこと。
この機能があるだけでも、全く違ってくるだろう。
(引用開始)
Bugzilla は Mozilla によって開発され, WebKit でも使われている. Bugzilla にはファイルを添付できる以上の大仰なレビュー支援機能はない. そのパッチがレビュー要求であること, パッチのレビューが受理されたことを, フラグとして管理できるだけ. でもフラグをはじめとするメタ情報を検索でフィルタできるから, メールよりはレビューの進捗を把握しやすい.
(引用終了)
RedmineやTracなら、パッチの添付ファイルは差分表示してくれるし、コードレビューそのものをチケット化することで、一つの作業とみなせる。
ツール自身もどんどん進化している。
だが、コードレビュー専用のツールの方が使いやすい場面も多いかもしれない。
| 固定リンク
「プログラミング」カテゴリの記事
- テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA(2021.04.10)
- Ruby技術者認定試験の感想(2020.05.08)
- 前処理大全の良いところ~SQLとRとPythonで対比できる(2019.07.10)
- WinSCPでトンネリングする方法のリンク(2018.09.09)
- 仕様書にもExcel脱却が求められている(2017.12.23)
「Redmine」カテゴリの記事
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
- Redmine 4.1.2がリリースされた(2021.03.21)
- 信頼度成長曲線の落とし穴(2021.02.12)
- キャズム理論をプロセス導入の問題解決に使うアイデア(2021.01.25)
- 変更管理プロセスが弱いとトラブルが多い(2021.01.04)
「ソフトウェア工学」カテゴリの記事
- テスト駆動開発が抱える問題は可読性と保守性のトレードオフ #dxd2021 #streamA(2021.04.10)
- プロジェクト管理手法はプロジェクト型開発からプロダクト型開発へ変えるべきだ(2021.04.01)
- ソフトウェア開発は打ち合わせ駆動開発だ(2021.03.30)
- ソフトウェア開発のチームは人数が増えるとプロジェクトは失敗する経験則がある(2021.03.30)
- ITの技術や知識はツールの習得と表裏一体である(2021.03.26)
コメント