開発者としてコードレビューの準備ができていますか？

ここでいくつかのアイデアを探しています。

私は「コードレビューはどのように実行し、コードレビューを実行する必要がありますか」という記事を読みました。これは非常に有益でしたが、以下の質問をさらに明確にする必要があります。

私の質問は、

1. ターゲットの開発者として、コードをレビューする前に、開発者が組み込むことができるいくつかのベストプラクティスを提案できますか。

   • 現在、私は以下の方法を練習しています

     • 論理フローのPPT
     • 詳細なコメント。

問題：上記のプラクティスを実装しましたが、レビューには役立ちません。私が直面した問題は、特定のロジックが参照されると、実装とフローを探し続け、プロセスに時間がかかりすぎて、人々の神経質になってしまうことです。

多くの開発者も私が経験していることを経験していると思います。

OPの詳細に基づくと、質問は「Xを見つけたり、Yを説明したりするときに、迅速に応答できるように、自分のコードをどのようにして習得すればよいか」のようです。

私が考えることができるいくつかの提案：

• コーディングするときは、時間をかけて自分のコードを学び、理解する必要があります。これは、TLがそれほど多くの言葉であなたに伝えようとしていることかもしれません。現在のプロジェクトのTLである私は、過去11か月間に多くのコードレビューを行っており、一部の開発者が独自のコードベースまたは他の場所（googleなど）、それをコピーして貼り付けます。個人的には、コードが単純な単体テストに合格しても実際に何が行われているのか理解していないため、私はそれに耐えられません。発生する可能性がある境界ケースまたは予期される障害状態。

• 前のステートメントの結果として、コピー/貼り付けする必要がある場合は、以前に記述した、理解しているコードのみをコピー/貼り付けしてください。他の人のアイデアを「借りる」ことは確かに問題ありませんが、その場合は、コードを1行ずつ書き直してください。コードを書いているときに、コードの内容をよりよく理解できるからです。外部APIを使用している場合、そのAPIを使用する例がある場合でも、とにかく数分かけて参照を見つけ、そのAPIがどのように機能するかを学習してください。それが以前に機能した場合、それはあなたの状況でも機能すると想定するだけではありません。

• 読んで、DRY原理を愛することを学んでください。多くの場合、コピー/貼り付けしたくなるものは、共通の場所（個別の関数、個別のクラス、個別のライブラリ...）に配置できます。

• SOLIDの原則を読み、愛することを学びます。その間、mouvicielによってすでに言及されているKISSを確認してください。これらの原則はすべて、非常に簡潔でクリーンなモジュール式コードを生成することを目的としています。それらの中に大きなクラスと大きな関数がある場合、明らかに物事を見つけるのがはるかに難しくなり、それに加えてコードが何をするのかを説明しようとします。一方、SRPをフォローする（または少なくともフォローしようとする）場合、各クラス/関数が1つのことだけを担当するようにすると、コードは小さくなり、非常に読みやすくなります。

• Clean Codeのコピーを入手します。とても良い本です。自明で、読みやすく、維持し、拡張しやすいコードを書くことについて話します。読みやすいコードを書く練習をしている場合は、コードレビューで独自のコードを読み取ることに問題はありません。そしてこれは面白い部分です、私は人々に彼ら自身のコードを読むか、単に変数が何を表しているかを私に言うように頼みました、そして彼らはたった一週間前にそのコード（真新しいクラス、レガシーではない）を書いたにもかかわらず答えられませんでした。良い命名は長い道のりです。

• 単純化とリファクタリングを行った後でも、あまり明らかではないある種のアルゴリズムを実行する必要がある関数がまだある場合は、時間をかけてその関数にコメントブロックを記述し、アルゴリズムを説明します。2か月後にその機能を変更する必要がある場合に役立つだけでなく、コードレビューで待ち伏せされた場合は、書き込んだ内容を簡単に読み戻すことができます。

• 上記のすべての項目を実行しても、問題が発生しますか？あなたはチームに新しく、多くのレガシーコードで作業するように依頼されましたか？その場合は、TLがA $$であり、会議の前に、関係者全員の時間を無駄にしないように頼むことで、積極的に取り組むことができます。新しい人がチームに参加するとき、TLは新しいプラットフォーム、新製品、新しい人、新しい環境での作業が新しい人からの多くの集中を取り、その人は最初にいくつかの詳細を見落とすため、十分な忍耐が必要です。設計どおりに機能し、TLはそれを受け入れる必要があります。

• 上記のすべての項目が終わった後でも、恐ろしいコードレビューがあるとまだ感じています。TLに相談してください。コードレビューミーティングの性質上、実際にはTLが完全に満足しているのに、人々が気分が悪くなることがあります。コードレビューを行うときの目標は、何を変更する必要があるかを強調し、変更を理解して先に進むことです。多くの場合、私は礼儀正しくする時間がないので、一部の人々は防御的になり、私のコメントのすべてに答えようとします。これらの状況では、コードレビューの会議のグラインドが停止するので、中断して先に進む傾向があります。一般的には、ミーティングの後に、彼らがプロセスを理解していることと、それが個人的なものではないことを確認するために、新しい人たちと話します。少数のコードレビューの後、人々は一般的にはるかに快適になります。

実践はさまざまですが、私の経験では：

• コードに特別なことをしないでください。コードがレビューされることを知ったとき、コードを少し精巧にすることは自然であり、スペルミスなどの明らかなものを修正しても害はありません。ただし、レビューが予定されているからといって、詳細なコメントを多数追加したり、コードを変更したりしないでください。

• コードは準備され、レビューのかなり前にレビューアに配布されます。これは通常、中立的な第三者、おそらくコードレビューファシリテーターによって行われます。印刷する場合、コードは行が頻繁に折り返されないように十分小さく、誰でも簡単に読み取れるように大きくする必要があります。それが必要な場合は、横長の形式で印刷します。

• コードは、印刷するか、行番号とともに表示する必要があります。番号は、あるファイルから次のファイルへと続くことが望ましい。「foo.cの238行目」よりも「3502行目」を参照する方がはるかに簡単であり、数字を使用すると、誰もがそれらの行を見つける時間を無駄にすることなく特定の行について話すことができます。

• 確かにファシリテーターがいるはずです。彼または彼女の仕事は、レビューがマニューシャで行き詰まらないようにし、個人的または熱くなるのを防ぎ、レビューの長さを厳密に制限することです。

• 著者として、レビュー会議の前に自分でコードをレビューする必要があります。これが他人のコードである場合に提案する変更を書き留めます。これは、数日では見られなかったかもしれないコードの記憶を揺さぶります。また、自分のコードを批判的な目で見て練習するのにも役立ちます。レビュー担当者と作成者の両方としていくつかのレビューを終えると、自分のノートがグループの他のノートとより密接に一致することがわかります。

• レビュー中にメモを取る準備をしてください。これはあなたの主な関心事ではありません-コードの説明とフィードバックの聞き取りに集中できるように、他の誰かがグループが同意するアクションアイテムを記録する必要があります。ただし、アクションアイテムではない貴重なフィードバックが得られる場合があります。そのようなことは、発生したらすぐに修正する必要があります。

• それは個人的なものではないことを忘れないでください。レビュー中に防御的な感覚（および行動）を回避することは困難です。コードが誤解されていると思われる場合は、コードを説明してもかまいませんが、何よりもまず耳を傾けることを試みます。

他の答えに追加するもう1つのこと：正式なコードレビュー担当者を容易にするために、非公式のコードレビューを大量に実施してください！例えば：

「ボブさん、foo（）関数の実装方法を教えてもらえますか？」「スティーブさん、このクラス図を見て、あなたの考えを教えてください。」「カレンさん、この問題の解決を手伝ってくれませんか。良い解決策はあると思いますが、私はあなたの助けを借りることができます...」

これを定期的な習慣にします。設計プロセスの早い段階で同僚を巻き込むと、次のようになります。

• 関係を築く
• 問題に対する新しい洞察を得る
• 目の前の問題/解決策を説明する能力を向上させる
• 正式なコードレビューで時間を節約