ジュニアソフトウェアエンジニアとして、私はより良いコーダーになる方法を学ぶために受け取ったコードレビューコメントを常に熟読しました。 しかし、最初のコードレビューを試みるときが来たとき、私は自分の経験では反対側に立つ準備ができていなかったことに気付きました。
偽の症候群の深刻なケースを開発し、質問で下にスパイラルしました： このコード行にコメントする必要がありますか、それは価値がありませんか？ すべてのコメントをサポートする記事を見つける必要がありますか？ これを承認してサイトをクラッシュさせますか？ 彼らは私を嫌いますか？ さて、私は非常に迅速にらせんを認めます。 しかし、同僚と話をした後、私は心配しているのは私だけではないことを知っていました。
GitHubのエクスペリエンスエンジニアであるJessica Rudder氏は、ジュニアソフトウェアエンジニアは、「本を読む方法を知っているので、本を書く方法を知っているのは事実ではない」という仮定に基づいてコードレビューに投げ込まれる可能性があります。
コードのレビューには期待があり、そのプロセスは神経質になります。 そこで、他の7人のソフトウェアエンジニアにインタビューして、レビューの考え方を構築する方法に関するヒントを収集しました。
1.全体的な影響について考える
一般に、良好なプルリクエスト（PR）は、コードベースの限定された部分にのみ影響します。 ただし、スコープが制限されているために、より大きなコードベースのコンテキスト内でコードの変更について考えることを妨げるべきではありません。
The Museの元フルスタックエンジニアであり、現在フリーランスのソフトウェアエンジニアであるNigel Munozは、レビュー担当者に「この変更がどのように大きな画像と小さな画像に影響するか」について考えることを推奨します。繰り返される、非モジュール式、または最新の標準規約に準拠していない-コードベースのアーキテクチャへの変更を分析する。
ハドソンリバートレーディングのコア開発者であるサムドノーは、「コメントするには大きすぎたり小さすぎたりするものは何もないと考えています。 小さな改善の提案は、コードベースの複数の部分に大きな改善をもたらす可能性があります。」
GitHubでPRコメントを使用して、肯定的なフィードバックを提供したり、コードがフレームワークReactの標準規則と異なる可能性がある箇所を指摘したりできます。
たとえば、自分のコードレビューの1つで、Reactコンポーネントの特定のプロパティが混乱しているというコメントを受け取りました。これにより、コンポーネントの使用方法に関するより広範な疑問が生じました。 最終的に、元のコンポーネントからプロパティを削除し、個別のコンポーネントを作成して、それぞれの動作を明確にし、両方をより多くの場所で使用できるようにしました。
2.セキュリティを検討する
いくつかの変更がコードベース以外にも影響する可能性があることを忘れないでください。 ユーザーが「この機能を使用して誰かに嫌がらせをしたり、システムを悪用したりする可能性がある」かどうかを評価することをお勧めします。その他のセキュリティ脆弱性。
3.バグに焦点を当てる
あなたの仲間のコード貢献者は、たとえロボットのように見えても、人間であり、人間は機能を破壊したり忘れたりするかもしれません。 そのため、必ず「他のコードと同じ重要性でテストをレビューしてください」と、Teachers Pay Teachersの技術リーダーであるAbhishek Pillai氏はアドバイスします。 「彼らは新しいバグを防ぎ、将来これに取り組んでいる他の誰にもドキュメントの形として役立つでしょう。」
テストを読むと、新しい機能の機能を理解し、導入されるさまざまなケースを確認できます。テストを分析すると、欠落しているケースを指摘し、このPRに含まれていない機能を見つけることができます。 コード変更に含まれるテストがなく、関連性があると思われる場合は、レビュー内でテストを要求するのが適切です。
しかし、テストだけがすべてではありません。 「システムに過度の信頼を置かないでください」とDonowは警告します。 「テストを実行したからといって、バグがないわけではありません。」
「アプリをローカルで実行して機能的にテストし、機能することを確認することもできます。 うまくいかない場合、さらにレビューしても意味がありません」と8th Lightのソフトウェア開発者であるRyan Verner氏は述べています。 一部のレビュー担当者は、手作業によるテストがコードレビュープロセスの一部であるべきだとは考えていませんが、それは時間がかかることもありますが、Vernerは、レビューに時間をかける必要があるかどうかを判断するための迅速な方法であると考えていますバグバックログの成長。
4.チームプレーヤーになる
決まり文句は、コードのレビューに関して新しい意味を持ちます。 「全員のコードベースであるため、レビューに時間をかけてください」と、「集団所有権」を主張するVerner氏は言います。レビューアとして、あなたはバグのバックログが大きくなるのを防ぎ、チームの作業が減ります。
Pillaiはgifを使用して、チームメイトの承認済みですぐにマージできるPRを祝います。
同時に、The Museの技術主任であるCharles Luxtonは、チームの優先事項を理解し、覚えておくようレビュアーに奨励しています。 近づきつつある締め切りと意見の不一致により、将来的に改善が行われることを保証するバックログのTo Do項目を作成し、その間に問題のコードにコメントを付けることが、あなたが必要とするバンドエイドですチームを幸せに保ちます。
最後に、チームに参加したばかりで、最初の数週間以内にコードを読んでいた人にコードが意味があるかどうかを自問することは、コードを読みやすく理解しやすくするのに役立ちます。
5.学習と知識共有のプロセスを使用する
レビュープロセスは、コードベース、言語、フレームワーク、およびベストプラクティスに関するより多くの洞察を得る場所を関係者全員に提供します。
The Museの技術リーダーであるMatt Jefferyは、レビューアーに「アーキテクチャーの変更を理解するようアドバイスします。1つの方法は、コンテキストを与えるのに役立つのでファイル名を読むことです。たとえば、データアクセスレイヤーの変更を見ている場合ビジネスロジックやUIを扱っていないことがわかります。」
GitHubでPRコメントを使用して、ドキュメントを共有できます。
コードの変更から学ぶとき、知識を共有する機会もあります。 「あなたの意見を説明し、ドキュメントでそれをバックアップすることが最善です」とLuxton氏は言います。 裏付けとなる証拠と信頼できる記事に提供するリンクは、レビュアーとコードライターが最終決定を下す際にさまざまなアプローチを検討するのに役立つだけでなく、プログラミングの知識を強化します。
これらのヒントを念頭に置いて、確認は人材スキルを行使する時間であることも忘れないでください。 「人々に自分のアプローチについて考えた疑いの恩恵を与え、防御力を払拭しようとしている間にさまざまな可能性を指摘します」とラダーは言います。 「コメントを最後まで残し、最後にコメントを残します。素晴らしい点、改善できる点、マージする前に変更する必要がある点を示します。」
この種のアプローチにより、コードベースを技術的負債、セキュリティ上の脅威、バグから保護するだけでなく、チームを構築することもできます。
