正式なコードレビューを実施する際に役立つ考え方とは
私たちのチームは最近、各チェックインに対してコードレビューを実施し始めました。
チームリーダーとして、私は提案が多すぎること、開発者を困らせること、チームの出力を減らすこと、そして私が別様に書いたコードを手放すことの間のバランスを見つけようとしています。
有用なアプローチを示唆する、よく知られているソースからの証拠、研究、またはガイダンスはありますか？
包括的な目標に留意してください：結局のところ、有効なソフトウェアのみが重要です
ピアレビューとチェックインコードレビューは、 品質の向上 を目標としています。しかし、やる気のある開発者ほど品質に悪いことはありません。チームリーダーとしてのあなたの役割は、コードを自分で記述したものとして承認することではなく、チームワークを促進して全体的な結果を保証することです。
レビューの明確な範囲を設定します
覚えておいてください：それはあなたのコードではなく、チームのコードです。したがって、間違った結果につながる可能性があることに焦点を当てます。
動作しないことが確実でない限り、開発者が要件を満たすように選択した方法に異議を唱えないでください（ただし、テストに不合格だったはずですよね？）
問題がどこにあるかを示す指標がない限り、パフォーマンスの低下に挑戦しないでください。時期尚早の最適化はすべての悪の根源です;-)
挑戦すべき設計またはソフトウェア構造を見つけた場合は、なぜそれが事前に捕捉されなかったのかを自問してください！すでに書かれたコードは書き換えにコストがかかります。これが発生した場合は、ソフトウェアの開発とチームワークのプラクティスを、少なくともコードと同じくらい検討する必要があります。
確立されたコーディング標準への準拠に対処します。これは、レビュー担当者とレビュー対象者の両方が話し合う最も厄介なトピックです。全員があなたのチームで大文字のクラス名を使用することに同意し、1人の男がそれなしでクラスを持っている場合、それは好みの問題ですか？またはチームワークの有効性とリスクの？
ちなみに、コーディング標準を検討する価値がないと感じた場合は、標準から削除し、時間とエネルギーを浪費しないでください。
リーダーシップの育成：レビューの人間的な側面
チームリーダーとして、品質管理の形式を超えて、自分とチームを発展させる機会をここで見つけることができます。
- 真のやりとりがあれば、コードレビューは誰にとってもはるかに快適です。開発者に彼らのスキルを示す機会も与えてください（そしてはい、おそらく何か新しいことを学ぶことができます）。
- 設計の選択、または既存の規格に対する批判に耳を傾けます。時々人々はそれについて話すことができたからといって、そのような欲求不満にうまく対処することができます。
- 後輩を指導する：ためらわずにアドバイスをしたり、次の反復のためにオリエンテーションをリファクタリングしたりしてください。先輩にはこれを行わないでください。別の世界では、それぞれの役割が切り替わった可能性があります。
他のプラクティスを活用してください
コードレビューで回避できることがいくつかあります。
- ビルドチェーンで静的コードアナライザーを使用すると、ピアレビューのかなり前に 一般的なバグの発見 、または移植性のない構成を自動化できます。一部のツールは コーディング標準のいくつかを確認する さえできます。
- コードレイアウトに関する標準がある場合は、 pre-commit pretty-print または similar formatters を使用して、必要に応じてコードを自動的にフォーマットします。ソフトウェアがあなたのためにより良いことをするために議論することなく時間を費やすことは決してありません:-)
- 最後に、品質はレビューだけでなくテストによっても保証されます。 [〜＃〜] tdd [〜＃〜] をまだ使用していない場合は、コードレビューとは別に考えてみてください。
私たちの開発者として、考え方は常にオープンで懐疑的である必要があります。
オープン、開発者がいつ私たちを驚かせるかわからないため、そしてソフトウェアエンジニアリングではソリューションを実装するための単一の正しい方法がないことをしばしば忘れているため、私たち自身のアイデアに懐疑的です。私たちのソリューションの背後にある理論的根拠は、私たちにとっては意味をなし、他の人にとっては意味をなさないかもしれません。コードのにおいの背後には素晴らしいアイデアがあるかもしれません。多分、開発者はそれを適切に表現する方法を見つけませんでした。
私たち（人間）はコミュニケーションがひどいので、誤った仮定をしないでください。レビューしているコードについてコード所有者に喜んで尋ねてください。彼/彼女が会社の標準の下でアイデアをコーディングすることに失敗した場合、リード開発者も彼/彼女を案内することをいとわないので。
ここで主観的なアプローチ。客観的なアプローチであるIMOは非常によく説明されています この質問では 。
上記のリンクに加えて、達成すべき一連の目標（保守性、可読性、移植性、高い凝集性、疎結合など）は必ずしも10の戒律ではありません。あなた（チーム）は、これらの目標を、品質と生産性のバランスが仕事を快適で「開発者にとって住みやすい」ものにする点に適合させることができるはずです。
これらの目的に従って品質の進行状況を測定するための静的コード分析ツールの使用を提案します。 SonarQubeのようなツールは、優先事項に従ってカスタマイズできる品質ゲートと品質プロファイルを提供します。また、コードニオイ、バグ、疑わしい慣行などに関連する問題を開発者のターゲットにできる問題トラッカーを提供します。
これらの種類のツールは出発点としては良いかもしれませんが、先ほど述べたように、懐疑的になります。 Sonarでいくつかのルールがあなたにとって無意味であることがわかるかもしれないので、それらを無視するか、品質プロファイルから削除してください。
表面的な変更のために開発者のコードをいじると、開発者の意欲をそそりますが、絶対的な状況ではそれを行わなければなりません。リードは、有用なコードレビューを提供することと、マイナーな欠点を削除することを学ぶことのバランスを見つける必要があります。 https://blog.smartbear.com/sqc/for-the-new-team-lead-the-first-six-things-you-should-know/
覚えておくべきいくつかの事柄：
- それはテクノロジーだけでなく心理学についてでもあるので、ここに黄金律はありません。
- 人々については、知識だけでなく、文化や階層内の位置についてもです。
- これが「長い」ゲーム（安定した確立された会社）である場合、人々が互いに信頼し合うよく統合されたチームは、通常、レビュー中のコードよりも価値が高くなります。絶対に続行する必要のないものを強制するために使用しないでください。悪魔は細部に...
- これが「短い」ゲーム（サイドプロジェクト、R＆D、グループ内の多くのフリーランサー）である場合、CRのコストは、それらを行うことから来るアドベンチャーを克服することがよくあります。態度は「中華鍋にする」