健全なコードレビューの考え方をチームにもたらす

公開: 2022-03-10

簡単な要約↬最後にコードレビューで共同作業を行ったときのことを思い出してください。あなたのチームはフィードバックの抵抗を克服し、時間の期待を管理しましたか？健全な考え方を育むことは、信頼を築き、同僚と知識を共有するための鍵です。

「コードレビュー」は、開発プロセスの中で、（開発者として）あなたと同僚が協力して、リリースされる前に最近のコード内のバグを探す瞬間です。そのような瞬間に、あなたはコード作成者またはレビューアの1人になることができます。

コードレビューを行うとき、何を探しているのかわからない場合があります。一方、コードレビューを送信するときは、何を待つべきかわからない場合があります。双方の間のこの共感の欠如と間違った期待は、不幸な状況を引き起こし、双方にとって不快な経験に終わるまでプロセスを急ぐ可能性があります。

この記事では、コードレビュー中に考え方を変えることでこの結果をどのように変えることができるかを共有します。

チームとして
著者として
レビューアとして

チームとして働く

コラボレーションの文化を育む

始める前に、コードをレビューする必要がある理由の価値を理解することが基本です。知識の共有とチームの結束はすべての人にとって有益ですが、考え方が不十分な場合、コードレビューは、不快な結果をもたらす膨大な時間の消費者になる可能性があります。

チームの態度と行動は、他の誰かの経験に関係なく、学習と共有という共通の目標を持って、判断力のないコラボレーションの価値を受け入れる必要があります。

ジャンプした後もっと！以下を読み続けてください↓

見積もりにコードレビューを含める

完全なコードレビューには時間がかかります。変更に1週間かかった場合でも、コードレビューに1日もかからないようにしてください。それはそのようには機能しません。コードレビューを急がせたり、ボトルネックと見なしたりしないでください。

コードレビューは、実際のコードを書くことと同じくらい重要です。チームとして、ワークフローにコードレビューを含めることを忘れないでください。また、コードレビューにかかる時間についての予想を設定して、全員が同期し、自分の作業に自信を持てるようにします。

ガイドラインと自動化で時間を節約

一貫した貢献を保証する効果的な方法は、プロジェクトにプルリクエストテンプレートを統合することです。これは、作成者が完全な説明を含む健全なPRを提出するのに役立ちます。 PRの説明では、変更の目的、その背後にある理由、およびそれを再現する方法を説明する必要があります。スクリーンショットと参照リンク（Gitの問題、デザインファイルなど）は、自明の提出の最後の仕上げです。

これらすべてを行うことで、レビューアが詳細を求める初期のコメントを防ぐことができます。コードレビューをあまり目立たないように見せるためのもう1つの方法は、レビュー担当者が関与する前に、リンターを使用してコードのフォーマットとコード品質の問題を見つけることです。レビュープロセス中に繰り返しコメントが表示される場合は、それを最小限に抑える方法を探してください（より良いガイドラインまたはコードの自動化を使用してください）。

学生にとどまる

誰でもコードレビューを行うことができ、年功序列に関係なく、誰もがコードレビューを受け取る必要があります。知識を学び、共有する機会として、フィードバックを感謝して受け取ります。 フィードバックは、防御的な反応ではなく、オープンな議論と見なしてください。ライアンホリデイが言うように：

「アマチュアは防御的です。専門家は、学ぶこと（そして時には現れることさえ）が楽しいと感じています。彼らは挑戦され、謙虚になるのが好きで、継続的で無限のプロセスとして教育に従事します。（...）」

—ライアン・ホリデイ、自我は敵です

あなたが学生でなくなるとすぐにあなたの知識は壊れやすくなるので、謙虚にとどまりなさい。

レビューアを選択するアート

私の意見では、レビュー担当者を選ぶことは、チームとして効果的で健全なコードレビューを行うための最も重要な決定の1つです。

同僚がコードレビューを送信していて、「全員」にタグを付けることにしたとします。これは、無意識のうちに、プロセスをスピードアップしたり、可能な限り最高のコードを提供したり、コードの変更について全員に知らせたい場合があるためです。各レビュー担当者は通知を受け取り、PRリンクを開くと、レビュー担当者としてタグ付けされた多くの人が表示されます。「他の誰かがやる」という考えが頭に浮かび、コードレビューを無視してリンクを閉じます。

まだ誰もレビューを開始していないので、同僚は各レビュー担当者にレビューを行うように通知します。つまり、レビュー担当者にプレッシャーをかけます。レビュー担当者がそれを開始すると、誰もが独自の意見を持っており、共通の合意に達するのは悪夢であるため、レビュープロセスは永遠にかかります。一方、コードをレビューしないことを決定した人は誰でも、すべてのレビューコメントを含む無数の電子メール通知でスパムされ、生産性にノイズが発生します。

これは、私が望んでいる以上に起こっていることです。レビュー担当者としてタグ付けされ、皮肉なことに、非生産的なコードレビューで終了する多数の人々を含むプルリクエスト。

レビューアを選択する際の一般的な効果的なフローがいくつかあります。考えられるフローは、コードに精通している2〜3人の同僚を選び、レビューアになるように依頼することです。 Gitlabチームによって説明されている別のアプローチは、少なくとも2人のレビューアがコードに同意するまで、作成者が1人のレビューアを選び、別のレビューアを選ぶという連鎖レビューフローを用意することです。選択するフローに関係なく、レビュー担当者が多すぎないようにしてください。同僚のコードの判断を信頼できることは、効果的で健全なコードレビューを実施するための鍵です。

共感する

改善するコードの断片を見つけることは、成功したコードレビューのほんの一部です。同様に重要なのは、同僚に共感を示すことによって、そのフィードバックを健全な方法で伝えることです。

コメントを書く前に、他の人の立場に立つことを忘れないでください。書くときに誤解されやすいので、送信する前に自分の言葉を確認してください。会話が醜くなり始めたとしても、それがあなたに影響を与えないようにしてください。常に敬意を払ってください。他の人と上手に話すことは決して悪い決断ではありません。

妥協する方法を知っている

ディスカッションがすぐに解決されない場合は、個人的な電話またはチャットに持ち込んでください。現在の変更要求を麻痺させる価値のある主題であるかどうか、または別の要求で対処できるかどうかを一緒に分析します。

柔軟性はあるが実用的であり、効率（提供）と有効性（品質）のバランスをとる方法を知っている。チームとして作られるのは妥協です。これらの瞬間に、私はコードレビューを最終的な解決策ではなく反復として考えるのが好きです。次のラウンドでは常に改善の余地があります。

対面コードレビュー

ペアプログラミングスタイルで著者とレビューアを一緒に集めることは非常に効果的です。個人的には、コードレビューに複雑な変更が含まれる場合や、大量の知識を共有する機会がある場合は、このアプローチを好みます。これはオフラインのコードレビューですが、特に会議後に変更を加える必要がある場合は、行われた議論についてオンラインコメントを残すことをお勧めします。これは、他のオンラインレビューアを最新の状態に保つのにも役立ちます。

コードレビューの結果から学ぶ

コードレビューに多くの変更が加えられた場合、時間がかかりすぎた場合、またはすでに多くの議論があった場合は、チームをまとめて原因と、そこから実行できるアクションを分析します。コードレビューが複雑な場合、将来のタスクをより小さなタスクに分割すると、各コードレビューが簡単になります。

経験のギャップが大きい場合、ペアプログラミングを採用することは、知識の共有だけでなく、オフラインのコラボレーションやコミュニケーションにも、信じられないほどの結果をもたらす戦略です。結果がどうであれ、常に明確な期待を持った健全でダイナミックなチームを目指してください。

著者として

著者としてコードレビューに取り組む際の主な懸念事項の1つは、コードを初めて読むときのレビュー担当者の驚きを最小限に抑えることです。これは、予測可能でスムーズなコードレビューへの最初のステップです。これがあなたがそれをする方法です。

早期のコミュニケーションを確立する

コーディングしすぎる前に、将来のレビュー担当者と話すことは決して悪い考えではありません。それが内部または外部の貢献であるときはいつでも、解決策を議論するために、開発の開始時に一緒に改良を行うか、ペアプログラミングを少し行うことができます。

最初のステップとして助けを求めることは何も悪いことではありません。実際、レビューの外で協力することは、初期のミスを防ぎ、最初の合意を保証するための最初の重要なステップです。同時に、レビュー担当者は、今後行われるコードレビューを認識します。

ガイドラインに従ってください

レビューのためにプルリクエストを送信するときは、説明を追加し、ガイドラインに従うことを忘れないでください。これにより、レビュー担当者は新しいコードのコンテキストを理解するために時間を費やす必要がなくなります。レビュー担当者がそれが何であるかをすでに知っている場合でも、この機会を利用して、ライティングとコミュニケーションのスキルを向上させることができます。

最初のレビュー担当者になる

独自のコードを別のコンテキストで表示すると、コードエディターで見逃してしまうものを見つけることができます。同僚に尋ねる前に、自分のコードのコードレビューを行ってください。レビューアの考え方を持ち、実際にコードのすべての行を調べます。

個人的には、自分のコードレビューに注釈を付けて、レビュー担当者をより適切にガイドするのが好きです。ここでの目標は、注意不足の可能性に関連するコメントを防ぎ、投稿ガイドラインに従っていることを確認することです。コードレビューを受け取りたいのと同じように提出することを目指します。

我慢して

コードレビューを送信した後、レビュー担当者に「見てください。数分しかかかりません」と言って、その親指を立てる絵文字を間接的に欲しがる新しいプライベートメッセージに飛び込まないでください。同僚に仕事を急がせようとするのは、健全な考え方ではありません。代わりに、同僚のワークフローを信頼してください。彼らはあなたが優れたコードレビューを提出することを信頼しています。その間、彼らが利用可能になったときに彼らがあなたに戻ってくるのを待ちます。レビュー担当者をボトルネックと見なさないでください。難しいことには時間がかかるので、辛抱強く待つことを忘れないでください。

リスナーになる

コードレビューが送信されると、コメントが表示され、質問が行われ、変更が提案されます。ここでの黄金律は、個人的な攻撃としてフィードバックを受け取らないことです。 どのコードも外部の視点から恩恵を受けることができることを忘れないでください。

レビューアを敵と見なさないでください。代わりに、この瞬間をとって自分のエゴを脇に置き、間違いを犯すことを受け入れ、同僚から学ぶことを受け入れてください。そうすれば、次回より良い仕事をすることができます。

レビューアとして

あなたの時間の前に計画する

レビュー担当者になるように求められた場合は、すぐに中断しないでください。それは私がいつも見ているよくある間違いです。コードを確認するには十分な注意が必要です。コードコンテキストを切り替えるたびに、フォーカスの再調整に時間を浪費するため、生産性が低下します。代わりに、コードレビューを行うために1日の時間枠を割り当てて事前に計画してください。

個人的には、朝または昼食後、他のタスクを選択する前に、まずコードレビューを行うことを好みます。オフにする前のコードコンテキストがなくても私の脳はまだ新鮮なので、それが私にとって最適な方法です。それに加えて、レビューが終わったら、自分のタスクに集中でき、作成者はフィードバックに基づいてコードを再評価できます。

協力的であること

プルリクエストが投稿ガイドラインに準拠していない場合は、特に新規参入者を支援してください。その瞬間を、著者が貢献を改善するように導く機会としてとらえてください。その間、著者がそもそもガイドラインに従わなかった理由を理解するようにしてください。 おそらく、以前は気づかなかった改善の余地があります。

ブランチをチェックして実行します

コードを確認している間、特にユーザーインターフェイスが関係している場合は、自分のコンピューターで実行するようにします。この習慣は、新しいコードをよりよく理解し、ブラウザでデフォルトのdiff-toolを使用した場合に見逃す可能性のあるものを見つけるのに役立ちます。これにより、レビュー範囲が変更されたコードに制限されます（コードエディタのように完全なコンテキストはありません）。。

仮定する前に尋ねる

何かがわからないときは、恐れずに言って質問してください。尋ねるときは、最初に周囲のコードを読み、仮定をしないようにしてください。

ほとんどの質問は、次の2つのタイプのカテゴリに当てはまります。

「方法」の質問
何かがどのように機能するのか、またはそれが何をするのかがわからない場合は、コードが十分に明確であるかどうかを作成者に確認してください。単純なコードを無知と間違えないでください。読みにくいコードと気づいていないコードには違いがあります。まだ深く知らなくても、新しい言語機能を学び、使用するためにオープンになってください。ただし、コードベースを単純化する場合にのみ使用してください。
「なぜ」の質問
「理由」がわからない場合は、特にエッジケースやバグ修正の場合は、コードにコメントを付けることを恐れないでください。コードの機能を説明する場合、コードは自明である必要があります。コメントは、特定のアプローチの背後にある理由を説明するための補足です。コンテキストを説明することは、保守性に関して非常に価値があり、役に立たないと思ったコードのブロックを誰かが削除するのを防ぐことができます。（個人的には、後で忘れても安全だと感じるまで、コードにコメントするのが好きです。）

建設的な批判

改善する必要があると思われるコードを見つけたら、プロジェクトに貢献するための作成者の努力を常に認識し、受容的で透明性のある方法で自分自身を表現することを忘れないでください。

オープンディスカッション。
フィードバックを「あなたがすべき…」や「あなたが忘れた…」などの命令や告発として形式化することは避けてください。フィードバックは、必須のリクエストではなく、オープンディスカッションとして表現してください。作者ではなく、コードにコメントすることを忘れないでください。コメントがコードに関するものでない場合は、コードレビューに含めるべきではありません。前に言ったように、協力してください。受動態を使用したり、複数形で話したり、質問や提案を表現したりすることは、作者への共感を強調するための良いアプローチです。

「ここからこのメソッドを抽出する…」ではなく、「このメソッドを抽出する必要があります…」または「このメソッドを抽出することについてどう思いますか…」を優先します。

明確にしてください。
フィードバックは、特に事実やガイドラインを共有するのではなく意見を表明する場合に、簡単に誤解される可能性があります。コメントですぐにそれをクリアすることを常に忘れないでください。

不明確：「このコードは…である必要があります。」

意見：「このコードは…である必要があると思います」

事実：「[ガイドライン]に従って、このコードは…である必要があります。」

理由を説明。
あなたにとって明らかなことは、他の人にとってはそうではないかもしれません。フィードバックの背後にある動機を説明しすぎることは決してないので、作成者は何かを変更する方法だけでなく、それから何が得られるかについても理解しています。

意見：「このコードは…である可能性があると思います」

説明：「このコードは、読みやすさを向上させ、単体テストを簡素化するため、（…）可能性があると思います。」

例を提供します。
作成者がよく知らないコード機能やパターンを共有する場合は、ガイダンスとして参照を使用して提案を補足してください。可能であれば、MDNドキュメントを超えて、現在のコードシナリオに適合したスニペットまたは実用的な例を共有してください。例を書くのが複雑すぎる場合は、協力して、直接またはビデオ通話で支援することを申し出てください。

「フィルターを使用すると[動機付け]に役立ちます」などと言うだけでなく、「この場合、[コードのスニペット]のようになります。 [Finder.jsの例]を確認できます。疑問がある場合は、Slackで気軽にpingしてください。」

合理的であること。
同じエラーが複数回発生する場合は、コメントを1つだけ残し、作成者が他の場所でもレビューすることを忘れないでください。冗長なコメントを追加すると、ノイズが発生するだけで、逆効果になる可能性があります。

焦点を合わせる

現在のコードに関係のないコード変更を提案することは避けてください。変更を提案する前に、その時点で厳密に必要かどうかを自問してください。このタイプのフィードバックは、リファクターで特に一般的です。これは、チームとして行う必要のある効率と有効性の間の多くのトレードオフの1つです。

リファクタリングに関しては、個人的には、小さいながらも効果的な改善を好む傾向があります。これらはレビューが簡単で、ブランチをターゲットブランチで更新するときにコードが競合する可能性が低くなります。

期待を設定する

コードレビューを半分完了したままにしておく場合は、作成者にそのことを知らせてください。そうすれば、時間の予想が制御されます。最後に、新しいコードに同意するかどうか、または後でもう一度レビューするかどうかも作成者に知らせてください。

コードレビューを承認する前に、将来そのコードに触れる可能性について安心できるかどうかを自問してください。はいの場合、それはコードレビューが成功したことを示しています。

コードレビューを拒否する方法を学ぶ

誰もそれを認めませんが、コードレビューを拒否しなければならない場合があります。コードレビューを受け入れることを決定したが、それを急いで行おうとすると、プロジェクトの品質とチームの考え方が損なわれます。

あなたが誰かの他のコードをレビューすることを受け入れるとき、その人はあなたの能力を信頼しています—それはコミットメントです。レビュー担当者になる時間がない場合は、同僚に「いいえ」と言ってください。私は本当にそれを意味します。決して行われないコードレビューを同僚に待たせないでください。 コミュニケーションを取り、期待を明確に保つことを忘れないでください。あなたのチームに正直になり、さらに良いことに、あなた自身に正直になりましょう。あなたの選択が何であれ、それを健康的に行い、そしてそれを正しく行いなさい。

結論

十分な時間と経験があれば、コードレビューを行うことで、技術的な知識以上のものを学ぶことができます。あなたは他の人からフィードバックを与えたり受けたりすることを学び、そしてそれにもっと考えを入れて決定を下すでしょう。

各コードレビューは、コミュニティとして、そして個人的に成長する機会です。コードレビューの外でも、あなたやあなたの同僚に自然に来る日まで、健全な考え方を育むことを忘れないでください。共有することが私たちをより良くするものだからです！

SmashingMagの詳細：

共同作業：設計者と開発者がより良いプロジェクトを作成するためにどのように通信できるか
設計者をコードレビュープロセスに参加させることによるコラボレーションの向上
Webデザイナーと開発者はどのポッドキャストを聞くべきですか？
完璧なWeb開発者の履歴書を作成する方法