正式なコードレビューを実施する際に役立つ考え方

当社のチームは最近、各チェックインに対してコードレビューの実施を開始しました。

チームのリーダーとして、私はあまりにも多くの提案を提供し、開発者をいらいらさせ、チームの出力を減らし、コードを手放すというバランスを見つけようとしています。

有用なアプローチを示唆する、よく知られた情報源からの証拠、研究、またはガイダンスはありますか？

包括的な目標に留意してください：最終的には、動作するソフトウェアのみが重要です

ピアレビューとチェックインコードレビューには、品質を改善するという目標があります。しかし、やる気のある開発者ほど品質に劣るものはありません。チームリーダーとしての役割は、コードを自分で書いたものとして承認することではなく、チームワークを促進し、全体的な結果を保証することです。

レビューの明確な範囲を設定します

覚えておいてください：それはあなたのコードではなく、チームのコードです。そのため、間違った結果につながる可能性のあることに注意してください。

• 動作しないことが確実でない限り、開発者が要件を満たすために選択した方法に挑戦しないでください（ただし、テストに既に失敗しているはずですよね？）

• 問題の場所を示す指標がない限り、パフォーマンスの低下に挑戦しないでください。早すぎる最適化はすべての悪の根源です;-)

• 挑戦すべき設計またはソフトウェアの構造を見つけたら、それが前もって捕らえられなかった理由を自問してください！すでに書かれたコードは書き直すのに費用がかかります。これが発生した場合は、少なくともコードと同じくらい、ソフトウェア開発とチームワークのプラクティスを確認してください。

• 確立されたコーディング標準への準拠に対処する。レビュー担当者とレビュー担当者の両方について議論するのは、最も面倒なトピックです。全員があなたのチームで大文字のクラス名を使用することに同意し、ある人がクラスを持たない場合、それは好みの問題ですか？または、チームワークの有効性とリスクですか？

ところで、コーディング標準について議論する価値がないと感じた場合は、コーディング標準を標準から削除し、時間とエネルギーを無駄にしないでください。

リーダーシップの開発：レビューの人間的側面

チームリーダーとして、品質管理の形式を超えて、自分自身とチームを開発する機会をここで見つけることができます。

• 真のやり取りがあれば、コードレビューは誰にとってもずっと快適です。開発者にスキルを示す機会も与えます（そして、はい、おそらく何か新しいことを学ぶことができます）。
• 設計の選択、または既存の標準に対する批判に耳を傾けます。人々はそれについて話すことができるという理由だけで、そのような欲求不満にうまく対処できることがあります。
• ジュニアを指導する：遠慮なくアドバイスをしたり、次のイテレーションのためにオリエンテーションをリファクタリングしたりしてください。高齢者にはこれをしないでください。別の世界では、それぞれの役割が入れ替わっている可能性があります。

他の慣行を活用する

コードレビューで回避できることがいくつかあります。

• ビルドチェーンで静的コードアナライザーを使用すると、ピアレビューのずっと前に、一般的なバグや移植性のない構造の検出を自動化できます。一部のツールは、コーディング標準の一部をチェックすることさえできます。
• コードレイアウトに関する標準がある場合は、プリコミットプリティプリントまたは同様のフォーマッターを使用して、必要に応じてコードを自動的にフォーマットします。議論することなく、ソフトウェアがあなたのためにできることに時間を費やさないでください:-)
• 最後に、品質はレビューだけでなくテストによっても保証されます。TDDをまだ使用していない場合は、コードレビューとは別に考えてください。

開発者として、マインドセットは常にオープンで懐疑的なものでなければなりません。

開発者が私たちを驚かせるのはいつかわからないからです。また、ソフトウェアエンジニアにはソリューションを実装する正しい方法が1つもないことを忘れがちなので、自分のアイデアに懐疑的です。私たちのソリューションの背後にある理論的根拠は、私たちにとって意味があり、他の人にとっては意味がありません。コードの匂いの背後には素晴らしいアイデアがあります。たぶん、開発者はそれを適切に表現する方法を見つけられなかったのでしょう。

私たち（人間）はコミュニケーションがひどいため、誤った仮定をしないでください。レビューしているコードについてコード所有者に喜んで尋ねてください。彼/彼女が会社の標準の下でアイデアをコーディングすることに失敗した場合、主任開発者も彼/彼女を案内してくれます。

ここで主観的なアプローチ。客観的なアプローチであるIMOは、この質問で非常によく説明されています。

上記のリンクに加えて、達成すべき一連の目標（保守性、読みやすさ、移植性、高い凝集性、疎結合など）は必ずしも10の戒めではありません。あなた（チーム）は、これらの目標を、品質と生産性のバランスが仕事を快適にし、「開発者にとって居住可能」にするポイントに適応できる必要があります。

これらの目的に応じて品質の進捗を測定するための静的コード分析ツールの使用をお勧めします。SonarQubeなどのツールは、優先度に応じてカスタマイズできる品質ゲートと品質プロファイルを提供します。また、問題追跡ツールも提供します。開発者は、コードのにおい、バグ、疑わしい慣行などに関連する問題をターゲットにすることができます。

これらの種類のツールは良い出発点になる可能性がありますが、私が言ったように自分自身を懐疑的にしてください。Sonarのいくつかのルールはあなたにとって意味がないと思うかもしれませんので、それらを無視したり、品質プロファイルから削除したりしてください。

化粧品の変更のために開発者のコ​​ードを調整することは、開発者の意欲をかき立てますが、絶対的な状況では実行する必要があります。リードは、有用なコードレビューを提供することと、マイナーな欠点を手放すことを学ぶこととのバランスを見つけなければなりません。 https://blog.smartbear.com/sqc/for-the-new-team-lead-the-first-six-things-you-should-know/

留意すべき点：

1. それはテクノロジーと同じくらい心理学に関するものなので、ここには黄金律はありません。
2. 人々についてのことは、知識だけでなく、文化や階層の位置に関することでもあります。
3. これが「ロング」ゲーム（安定した確立された会社）である場合、人々が互いに信頼するよく統合されたチームは通常、レビュー中のコードよりも高い価値を持ちます。絶対に続行する必要がないものを強制するために使用しないでください。悪魔は詳細に...
4. これが「ショート」ゲーム（サイドプロジェクト、R＆D、グループ内の多くのフリーランサー）である場合、CRのコストは、それらを行うことから始まる冒険をしばしば克服します。そして態度は「ただそれを鍋にする」べきです

重要なことは2つだけです。

1. すべての要件に対する自動テストはありますか？
2. 彼らはすべて合格しますか？

他のすべては表面的なものであり、ゲートとして強制されるのではなく、ビールについて議論されるべきです。

このビューに従うと、フォーカスの狭い領域に制限されます。

要件は良好ですか？理想的には、タスクを開始する前に知っておく必要があります。つまり、パフォーマンス、セキュリティなどはすべてそこにあるべきです

テストは良いテストですか？失敗したエッジケースは、要件を十分にテストしているかなどです。最終的には、既存の要件をテストするが、失敗するテストを作成できますか。