オルタナティブ・ブログ > 森崎修司の「どうやってはかるの?」 >

計測できそうでできない多くのこと。エンピリカル(実証的)アプローチで。

Cisco Systemsのコードレビュー

»

通信事業者むけのハイエンド通信機器で大きなシェアを持つシスコ。高信頼、高性能のソフトウェアをどのように作っているのだろうか。"Code Review at Cisco Systems"というタイトルで、ソフトウェア開発(コードレビュー)の文書がPDFとして公開(smartbear社のWeb)されている。(smartbear社はコードレビュー支援ツールをはじめ開発環境ツールのベンダだ)

文書では2006/5から10ヶ月にわたって収集された指摘密度やレビュー速度を統計的に調べた結果が掲載されている。対象は2500回のレビューで総コード行数は320万行だそうだ。このうちの一部を抜き取って分析しているものもある。

本題のシスコでのレビューだが、以下のような手順になっているらしい。本ブログの過去のエントリでも紹介したGoogleのコードレビューとかなり近い。GoogleではMondrianだったが、シスコではCode Collaboratorというコードレビュー支援ツールを使っているそうだ。

  • プログラマは自身のソースコードを構成管理システムにチェックインする前に、他の誰か(レビューア)にコードレビューして、OKをもらわなければならない。
  • コードレビューしてもらう際には、プログラマが1人以上のレビューアを招待する。レビュー全体では、50%くらいがレビューア1名で実施される。残りは2名以上。
  • レビューで指摘された欠陥が修正されるまで、レビューアはレビューを続ける。修正したことがレビューアによって承認されるまではソースコードはチェックインされない。レビューアが複数人いるときは全員の承認が必要。
  • 上述のワークフローがツールによって支援される。
  • レビュー終了までに要した工数や対象ソースコードの行数等のメトリクスがツールから得られる。

形態は、オープンソースで実施されているコードレビューに近いといえるだろう。

文書の多くの部分は、メトリクスの分析について書いてあり、ここもおもしろい。また別の機会に紹介したいと思う。


今回紹介したコードレビューにも関連するが、今週もThinkITで、レビューに関する記事が続々と登場しているので今週分の一部を紹介する。

  • 技法の分類とテンプレート(基礎編)(月曜日)
    なぜ、リーディング技法が必要かという話、チェックリストとアドホックの指摘
    テンプレートがある。(奈良先端科学技術大学院大学 森崎が執筆)
  • レビューの質をモデル化する!(火曜日)
    レビュー改善のための現状把握と改善方針をシステマチックに進めるための具体例。計測でやってはいけないことが書いてある。(デンソークリエイト 竹下氏が執筆)
  • 定量データに基づくインスペクション(水曜日)
    対象ドキュメントから計測できる値を使って、兆候をつかむ、インスペクションするべき部分を絞り込む。(日本IBM 細川氏が執筆)
Comment(0)