株式会社オズビジョンのユッコ (@terra_yucco) です。
[2019-06-01]
盛大に元記事とタイトルがひっくり返っていたことに気づきました。
こちらの記事の元は Why Review Code? です。
以前、SmartBear の Collaborator ツールの説明として書かれた Best Practices for Code Review を訳し、コードレビューのベストプラクティス として Qiita の記事をあげさせていただきました。
この記事は今でもちょくちょく読んでいただいているようで、皆様こういう分野に興味があるのだなあとありがたく思っております。
この記事は単体で会社のメンバからシェアされたのですが、その後見ていると Collaborator ツール説明の前提となっている 3 つの記事群の 1 つであることがわかりました。
そのため、残りの 2 つも翻訳をしていこうと思います。
Source Article
以下に記載の文章は、最後の Conclusion 部分を除き原文の内容をユッコの英語力の範囲で訳したものです。ただし以前の記事と同じく、正確に一言一句訳すわけではなく、かなりの意訳を挟んでいます。
また、貼り付けられている図表類は全て上記記事からお借りしています。
と思ったら、今回の記事の中にあった画像はリンク切れしていたので、別の記事から画像を持ってきています。そちらは画像に付記しました。
前書き
何かを書く人には、誤りを見つけてくれる編集者が必要。自分の作業成果物を適切に校正できないのは人間の性だから。ソフトウェア開発者にだって、組織の目的を達成するためには同じような助けが必要になる。
開発者が「コードのクオリティを向上させるにはコードレビューが一番だ！」と言っているのをよく聞く。
コードレビューのメリット
コードレビューの目的は本当に様々。
でも、ほぼ全部のコードレビューのゴールは共通していて、以下のようなことの実現にある。
- 欠陥がなく、ドキュメントが十分にあるソフトウェア
- 企業のコーディング標準に準拠したソフトウェア
- 開発者間での知の共有や教育
よくあるその他の目的としては、以下のような項目の担保もある。
- 保守性
- セキュリティ
- エンドユーザ向けドキュメントの一貫性
- コード内のコメントの適切さ
- 単体テストの完備
- スケーラビリティ
2018 State of Code Review report の中で 1,100 人の開発者に「コードレビューによる主なメリットは何？」と聞いた結果がこちら。
【訳注】この画像が元記事では Not Found になってしまっていました。
こちらは言及されている 2018 年ではなく、2017 年について書かれた The State of Code Review 2017 の該当しそうな画像を引用させていただきました。
リード文の中では「1,100 人の開発者に聞いた」とありますので、N が倍くらいになったグラフが貼られていたのだろうと推測できます。あくまで参考程度にとらえてください。
フルレポートはリンク先で読める。以前のレポートと比較すると、全体的にメリットがより認識されるようになってきている。
いくつかのチームでは、ピアレビューが新しいメンバーのオンボーディング及びトレーニングになっている。他のチームでも、ピアレビューはソフトウェア品質保証の大切なパートとなっている。
コードレビューの仕組み
コードレビューにはそのソースコードを書いていない開発者が 1 人以上参加し、対象のコードを検証して、良い点も悪い点もフィードバックする。
そのレビューアが該当のプロジェクトにまったく関係なければ理想的。なぜなら、そのプロジェクトに詳しくない人でも読みやすく保守しやすくなっているか？という観点で、最大限客観的にコードを読むことができるから。
よくあるケースでは、レビューアは標準化されたチェックリストを使う。チェックリストは、よくある誤りを見つけるためのガイドであり、そのコードが企業のコーディング標準に反していないか検証するためのものでもある。
コードレビューは開発の全ての場面で行われる。
※ただし、デモや実験などのため、さっさと作っては捨てるようなやり方をしている小さなプロジェクトを除く。
開発の最終フェーズで誰もが締め切りに直面しているようなときでも、コードレビューを行えば回帰バグを減らし、会社のコーディングルールを担保できる。
コードレビューのベストプラクティスを使えば、(コードレビューを行わなかった場合には) ローンチ直前の QA で見つかったであろう高コストの不具合を大幅に減らすことができる。
我々のコードレビューソフト (【訳注】SmartBear Collaborator) はコードレビューのプロセスのほぼ全てにおいて、所要時間を削減することができる。
コードレビューは、バグの発見と解消、全体的な理解の促進、設計上の問題の解消、そして他から学ぶための最も優れた方法である。
— Graydon Hoare (【訳注】Rust の開発者)
安上がりなバグ発見方法
バグの発見が早ければ、修正コストもより安く済むことはよく知られている。
QA フェーズで発見されたバグの修正には、開発中に発見されたバグ修正の 2 倍以上のコストがかかる。
明らかに間違った文章を書いても気づかないことがあるように、開発者もしばしば単純な不具合を作りこむ。ただしこれらは外部のレビューを受ければすぐに見つけることができる。
我々 (【訳注】SmartBear) はコードレビュー ROI 計算機を作り、バグ修正における時間とコストの削減がより明確にわかるようにした。
実際、NASA の研究で、1 時間にコードレビューで検出できる不具合件数は、テストで検出できるもののおよそ 2 倍であることがわかっている。
レビューアはよくある不具合、特に後からでは見つけにくいことで知られている不具合を探すだろう。例えば適切なスレッド同期、エラーの適切かつ完全な処理、参照カウンタやその他の潜在的なリソースのリーク、セキュリティの問題、単体テストが全てのパスをカバーしているか、エラーのケース、および閾値のケースなど。
IBM では 20,000 行のプログラムの検査を行い、大きな不具合をテストではなくコードレビューで検出したことにより、プログラマの労力の 85% 以上を節約できた。
— IEEE Trans. on Software Engineering, SE-12(7):744-751, July 1986.
保守性の確保
ソフトウェア開発の費用は初期開発にだけ発生するわけではない。将来、既存のコードを利用・修正した開発を行う際にも発生する。
ソフトウェアの保守が難しく高価なことはよく知られている。
これはある開発者がプロジェクトを離れ、新任者が着任したときに発生する。また、同じ開発者が 6 ヶ月前に自分が書いたコードを見直すときにも発生する。
一般に、保守性はコードの構造と適切なコメントによるものである。
プロジェクトに関わっていなかった人がコードの一部を読んで何をしているかを理解できればならない。そのコードを使うにあたっての制約や前提条件、およびその意図を汲み取れなければならない。(例えば、そのコードの作者は OS のバグ対応のため特殊なテクニックを使った、など)
ソフトウェア開発組織には、空白の使い方から関数の最大サイズまで規定したコーディングガイドラインがよくみられる。
レビューアはガイドラインに沿うことで、ガイドラインを理解していないことを気づかせたり、明らかに実装が必要なものを指摘することができる。
Shell Research はコードの検証に 1 時間投資することで、保守作業を平均 30 時間削減できた
— Software Practice and Experience, 22(2):173-182, Feb. 1992.
学習と共有
全てのプロジェクトには、明文化されていないルールや暗黙の了解があり、それらはプロジェクトに新しく入ってくる人全てが知るべきものである。
しかしそれらを全て書き留めたり、一気に伝えきることは不可能である。また、おそらく費用対効果もそこまで良くはない。
新規加入者はそれらの情報をプロジェクトに参加して数か月のうちには知らなければならない。通常、何かをやらかしたときに、経験のあるメンバーからアドバイスされて知ることになる。
コードレビューを促進するソフト
適切なツールを使わないと、コードレビューはとてもコストがかかる。専用のピアコードレビューツールは、ほぼすべての場面でコードレビューに要する時間を節約することができる。
レビューツールがあれば、チームでこんなことができるようになる。
- レビューの種別に応じたテンプレートやチェックリストの作成
- 参加者がやりやすいように、リモートでリアルタイムレビューを行える
- レビュープロセスや不具合のメトリクスを自動的に取得してくれる
【訳注】以降は Collaborator のデモ動画などなので、訳はここまで。
Conclusion
コードレビュー促進ツールの紹介記事なので「どんな場面でも、テストよりもレビューが有用だ！」というような論調が目立ち、途中で苦笑いしてしまいました。
訳者個人の意見としては、こと不具合検出においてはレビューが有効に働くケースもあれば、テストが有効に働くケースもあると思います。
例えば環境に依存するような不具合はレビューといった静的解析の場では見つけづらいものですが、該当の環境でテストさえ行えば低コストで一発で見つかったりすることもあります。
ただし他の側面、特に知の共有としてのコードレビューの効用は、(訳がうまくいった自信のない箇所はいくつもありますが) 納得させられるものばかりでした。
自社でもレガシーになりつつあるプロダクトの運営をしており、確かに暗黙知は増えてきていると感じているので、若手にこそ積極的にコードレビューをしてもらいたいと改めて感じたそんな記事でした。