ここでは、チームのコード修正を、すべての参加者に新しい体験を提供できる、より楽しいアクティビティにする方法についての私の研究について説明します。 完全に地理的に分散したチームがあり、すべての通信はインターネットを介して、多くの場合非同期で実行されます。 Trelloを使用して製品の機能を説明し、コードを1つずつ作成し、プルリクエストをGitHubに送信し、GitHubに組み込まれたレビュー機能も使用します。 これは、オフィスでコードを直接見たり、ビデオチャットで見たりすることとは異なります。



真剣に考えないと、コードの非同期および書面による修正がチームに災害を引き起こし、相互作用と協力が悪化する可能性があります。 しかし、すべての参加者がすべてをうまくやろうとすると、このアプローチは非常に効果的に機能します。

コードレビューとは何ですか？

レビューを行う方法とレビューしない方法について話し始める前に、会社が誰にそれを必要としているかを考え、これに従って要件を作成することが役立ちます。 また、レビューは、コード構造のバグや問題の単なる検索ではないことを忘れないでください。



チームのコードと士気の品質を改善するためにレビューが必要です。



互いのコードの分析は、通常の営業日の開発者間の相互作用の主な方法の1つです。 すべての参加者が彼を待って積極的に参加できるように、これはインスピレーションを与えるプロセスであるべきです。



リビジョンの助けを借りて解決できる主なタスクは次のとおりです。

• 内部チームカルチャーを作成します。 レビューは、チームカルチャーに関係する主要なプロセスの1つです。 また、参加者がレビューに参加するのが不快な場合、 わかりやすいチーム文化はありません 。 改訂により、前向きな雰囲気、寛容性、親しみやすさが生まれます。
• 同僚とより頻繁に話す能力を通じて、 仕事上の関係を改善します。
• 他の人のコードに関する肯定的なレビューの助けを借りて緊張を和らげます。
• トレーニング。 レビューアは、他の人のコードから自分自身のために、レビューから著者のために新しいことを学ぶことができます。
• 自分の責任範囲の境界を超えて、すべてのチームメンバーがコードのさまざまな部分を分析できるようにし、コードベース全体に精通します。
• メンタリングと教育。 レビューは、経験豊富な参加者がメンターになり、他の人を訓練する機会です。 ただし、時間が経過してコードが記述されているため、レビューは必ずしも学習するのに最適な時間ではないことに注意してください。 開発者は、コード生成前とコード生成中の両方で、技術プロジェクトに協力する必要があります。
• コード品質。 そして最後に、品質（バグ、メンテナンスの容易さ、ドキュメント、組織、アーキテクチャ、製品の使いやすさなど）。

レビュー時に行うこと

おそらく、この部分はあなたにとってかなりネガティブに思えるかもしれませんが、その後、素晴らしい部分が追加されます！



コードレビューを失敗させるには、さまざまな方法があります。 過激で怒りのある予測不可能なコメントは、チームの仕事の喜びを奪い、監査を感情的に困難な義務に変える可能性があります。

レビューで避けるべきことを理解すると、チームの仕事の貴重な部分が残酷で不快な罰と区別されます。 エリック・ディートリッヒ、「コードをレビューするときに避けるべきこと」

正式なコメントや最小限のコメントでレビューを行わないでください。

（別名、同僚があなたについてどれほどひどく考えているかを知る）



これに何も追加せずにエラーを指摘するだけでよいわけではありません。



開発者はコードに多くの時間を費やし、それを誇りに思っています。レビューは自分の仕事を実証するチャンスです。 そして、正式なミニマリストのアプローチで、あなたが期待できるのは、「Looks good、Smergeil」のスタイルのコメントだけです。 このようなレビューは、「 彼らがあなたのことをどれほどひどく考えているかを調べる 」というタイトルに値します 。



不明瞭で思慮のないコミュニケーションは、長期的な不快な結果につながる可能性があります。 チームの文化が悪化し、生産性が低下します。 同時に、開発者はしばしば「 このむち打ちは彼らの精神をノックアウトするように特別に設計されているようだ 」といったレビューを受け取り、改訂自体は「 人々が標的を撃つ精神的な競争に変わります...そして目標はコードを書いた開発者です」

「エンコーダではなくコードを批判する」だけで十分だとは思わないでください

これは最も一般的なヒントの1つです。エンコーダではなくコードを批判します。 それは良いことです（コードではなく同僚を批判すると、問題が発生します）。 しかし、これでは十分ではありません。 コードを書くことは、開発者が心を込めて創造するプロセスです。 そして、誰かのコードを残酷で愚かに批判するなら、その人自身を批判します。 批判できるようにする必要があります。 コードを改善する方法を分析し、提案するためのより積極的な方法を見つけてください。

音を見る

個人的にならないでください。 「なぜあなたはそれをしたのですか？」のようなフレーズは、攻撃として知覚されます。 悪い選択肢：「この関数を書いた方法は読みにくく、コメントを追加しにくい」（個人的な扱いは、人が何か間違ったことをしたことを意味する）。 より良い発言：「コードにコメントを追加する必要があると思わないか、これにより関数が読みやすくなりますか？」（より正確に聞こえ、コードの改善に集中できるようになります）。



要求の厳しい表現や反抗的な表現をしないでください。 「あなたは間違っています」という意味のフレーズは避けてください。 自分が間違っているとか、何か悪いことをしたとか、不快だとか言ってはいけません。 そのような場合、人々は防衛に取り組み、仕事や勉強を長期間、創造的にやめることができます。 次のようなフレーズは避けてください：

• 「それは機能しません。」
• 「絶対に間違っています。」
• 「なぜあなただ​​けではないのですか...」

誇張しないでください。 根拠のない、または誇張されているという批判に腹を立てたくありませんか？ 「常に」、「決して」、「際限なく」、「何も」と言わないでください 。



in辱はありません。 「ばか」や「ばか」のような悪態をつくことは避けてください 。 このような単語には一定の意味があり、コードの作者の気分を改善することはありません。



せっかちなまたは受動的に攻撃的なターンを使用しないでください。 常に抑制され、友好的であり、苛立ちを示す不愉快なフレーズを避け、人々が悪いことをしていると感じさせる：

• 「もう一度繰り返します。ここでは必要です...」
• 「私が言ったように...」

火に油を加えないでください。 人が誰かから批判を受けるのは不愉快かもしれませんが、その下で同じテーマについて「+1」や道徳を唱えることもあります。 さらに、多数の批判は単純に混乱させる可能性があります。

未承諾のアドバイザーにならないでください

自分自身を抑制し、あなたがしたいコードに変更を加えることを提案しないでください。 すべてを書き直さなければならないほどの変更を提案することで、コードの作者の士気をくじくことができます。 そのため、最も重要で最良のもののみを選択してください。



レビューのタスクの1つは、コード構造内のバグと問題を見つけて修正することです。 そして、作者にあなたがする方法でコードを書くことを強制しないでください。 ソフトウェアでは、開発者の好みに応じてさまざまな問題をさまざまに解決できることを忘れないでください。それぞれのアプローチには長所と短所があります。 別の改訂版を提案する予定がある場合は、自問してください。これは単なる私の意見ですか。 著者が他の方法を選択し、その選択を正当化する場合、彼をサポートする方が良いでしょう。 著者の決定権を尊重します。

誰かがあなたとは異なる方法でコードを書いたとしても、これはコードが間違って書かれているという意味ではありません。 主なものは、高品質で保守が容易なコードです。 彼がこれらの基準とチームで受け入れられたルールを満たしていれば、これで十分です。 ロバート・ゴッド、痛みのない効果的なレビュー

自分が書いたコードだけを他人に書かせることは決してできません。試してはいけません（これがあなたにとってとても重要な場合は、自分でコードを書く方が良いです）。 エリック・ディートリッヒ、「コードをレビューするときに避けるべきこと」

驚きのルールを破らないでください

予期しないことを避けてください 。 プルリクエストとコード標準についてチーム用に文書化された共通の合意を作成し、レビュー中にあなたの意見ではなく、それに依存します。

あなたの声を聞くためだけに話さないでください

レビューを書く前に、達成したいことを考えてください。 あなたのコメントはすべて必要ですか？ 単にあなたの視点を表現するのではなく、建設的に助けようとしていることを忘れないでください。 レビューを投稿する前に、コメントを読み直して自問してください。それらはすべて本当に有用で重要ですか？ 不要なものを削除します。 コードを表示した後、事後にメモを分析する方が良いでしょう。 コードを処理しながら、好きなだけコメントを書いてから、冷静にレビューして、残す内容を決定します。

あなたのポイントを強調するためだけにコメントを残すことは、常に有用（または合理的）ではありません。 人との長期にわたる良好な関係を維持するために、自分自身に対する意見を保持した方が良い場合があります。 キャサリン・ダニエルズ、「フィードバックのやり取り方法」

各レビュー中に問題を見つける必要はありません。

コードが良好で、変更せずにコードベースに流し込めば、すべて問題ありません。

レビュー時に行うこと

レビューを改善できます。 どのくらい正確に？ 以下に、インターネットで収集された提案をお読みください。

良いコードを賞賛する

欠陥を指摘して提案を行う前に、時間をかけてコードの長所を賞賛してください。

人間の性質は、失敗だけでなく、成功についても知る必要があるようなものです。 開発は、人々が自分の魂を入れる創造的なプロセスであり、多くの場合、彼らの心に多くを取ります。 したがって、彼らにとって賞賛はさらに重要です。 ロバート・ゴッド、痛みのない効果的なレビュー

チームメンバーに、レビューを純粋な批判としてではなく、快適で便利な体験として認識してもらいたい。 正のフィードバックは緊張を軽減し、批判に対する人々の反応を改善します。



甘いコメントや偽りに見えないように、前向きなコメントを書くことが重要です。 ピルを甘くしようとしているだけの印象を受けないようにしてください。



疑わしい賛辞を避ける。 「良い仕事ですが...」などのフレーズ（以降、提案する変更のリストと呼びます）はシミュレートされたように見えます。



賞賛をもっと正直にする方法は？

• コードと他の側面のほとんどの優れた部分を評価し、それらを気に入った理由を説明してください。
• 他の人のコードを詳しく調べるときは、コメントに「独り言」を残してください 。 「ええ、私はこれがそうだということに気付きました...まあ、ここに接続してそれを素晴らしいと呼びます...そしてこの部分はそれら2つに依存しています、素晴らしいです。」 コードを理解する別のプログラマーの思考の流れは、ジョブ検証の別の形式です。 また、理解できないコードに遭遇した場合は、説明を求めることができます。

まず、良い点

気分をすぐに設定します。まず、気に入ったものについて話します 。 これは、GitHubコードレビューの新しい機能のおかげで簡単に行うことができ、コメントを作成する前に複数行のコメントを作成し、（保存するときに投稿するのではなく）一括で公開し、短いレビュー（レビューの最初に表示）を作成します：

避けられない告発を避ける

聞いて、話さないで。 発言するよりも質問する方が良いです。

文は告発です。 「ここで基準を順守しなかった」というフレーズは、意図的であろうとなかろうと、告発です。 「このアプローチをここで使用した理由は何ですか？」 ロバート・ゴッド「痛みのない効果的なレビュー」

質問をすると、全体的な雰囲気が改善され、対話やトレーニングへの招待によりレビューの認識が変わり、コードの作成者が理由を説明したり、より良い解決策を探したりします。



理想的には、正しい質問に答えて、著者自身がバグを見つけたり、コードを改善することを提案したりします。

間違いである可能性のあるポイントが表示された場合、それらが間違っていることをすぐに人々に伝えるべきではありません。 通常、「このメソッドにゼロを渡すとどうなりますか？」と尋ねるだけで十分です。そして、本人はおそらく「疑問がありました。修正します」と言うでしょう。 彼が自分で問題を解決し、コードの改善を提案できるようにすることは、欠陥を修正するための指示を与えるよりもはるかに優れています。 エリック・ディートリッヒ、「実行にコードレビューを使用」

悪い：

• 「ここの基準に従わなかった」
• 「A-間違っている、Bを使用する」
• 紛らわしいコード
• 「これらの変数を初期化しませんでした」

良い：

• 「なぜこのようなソリューションをここで選んだのですか？」
• 「なぜBの代わりにAを使用したのですか？」
• 「この部分は私には理解できない。 説明できますか？」
• 「これらの変数が初期化されている場所が見つかりません」

告発的な「理由」を避けてください。 アサーションのように、 なぜ質問も非難に聞こえるかもしれないので、それらがなければ良いでしょう。



悪い：

• 「なぜここで標準に従わなかったのですか？」
• 「なぜあなただ​​けではないのですか...」

良い：

• 「どのような理由で、ここで基準から離れることに決めましたか？」
• 「...のときに何をフォローしましたか？」

もっと控えめに

質問ではなく、質問してください。 どの変更が必要かを著者に伝えるのではなく、コードについて質問するか、提案をして著者にこれについてどう思うかを尋ねます。 したがって、ボールをフィールドの彼の側に渡し、彼の自由意志に敬意を表して、著者に彼の決定を説明するか、あなたの提案がコードに役立つかどうかを話す機会を与えます。

「この変数のユーザー名に名前を付けましょう。そうでなければ明確ではないから」という質問の形で文を言い換えることをお勧めします。 現在の名前は、someotherfile.jsの別のコンテキストでも使用されているため、あまり明確に見えません。 ダニエル・バダー、「コードレビューで関係悪化を避ける7つの方法」

何かを提供するときは、この変更がコードを改善できる理由を必ず説明してください。



個人的な例を使用してください。 コードの作者に、彼がそのような間違いを犯しただけではないことを示してください。 これは、批判を和らげる素晴らしい方法です。「自分でやるのは難しいことでした...」、「同じことをしました。」



すべての質問に答える必要はありません。 コードの作成者が質問ごとに回答する必要があることをすぐに受け入れます 。 だからあなたはあなたの考えにあなたのレビューで質問をすることができます。 コードベースにコードを注入するためにそれらに答える必要はありませんが、一方で、彼らは開発者の思考を促し、長期的には彼の仕事の品質を向上させます。

驚きのルールを破らないでください

チェックリストを使用します。

確かに、チームの各メンバーは何度も何度も同じ間違いを犯します。 そして最も難しいのは、いくつかの要素の欠落を検出することです。 そのため、チェックリストは、最も一般的な間違いを回避し、紛失の可能性を減らすための最も簡単な方法です。 SmartBear、「ベストコードレビューテクニック」

もちろん、チェックリストはすべての可能なケースをカバーすることはできません。 ただし、適切なリストには、プルリクエストがコードベースとマージするために満たす必要があるすべての要件を含めるだけで十分です。 これは、エンコーダーとレビュアーの両方に役立つツールです。 チェックリストは、コードの改善、一貫性の向上、および規則と標準の違反を回避するのに役立ちます。 新規参加者が最初のプルリクエストを送信して最初の改訂を行う前に、コード要件に注意することは非常に便利です。



開始できるチェックリストの例：

• ブランチには、論理的に独立した1つの操作が含まれている必要があり、それに関連する変更はありません。
• 質の高いコミットメッセージが必要です。 < commit->
  
  
  
  参照してください。
• ブランチには、すべての新規または変更されたコードの新規または変更されたテストを含める必要があります。 すべてのテストはブランチで実行する必要があります。 < >
  
  
  
  参照してください。
• ブランチには、すべての新規または更新されたコードの新規または更新されたドキュメントが含まれている必要があります。 < >
  
  
  
  参照してください。
• ブランチはマスターブランチに関連し、競合することなくマージする必要があるため、プルリクエストにリベースします。
• すべての新しいコードは、Python、JavaScript、HTML、CSSの各スタイルについて承認されているアーキテクチャ要件とガイドラインを満たしている必要があります。 < >
  
  
  
  参照してください。
• 新しいコードにデータベーススキーマへの変更が含まれている場合は、データベースの移行を含める必要があります。 < >
  
  
  
  参照してください。
• コードにプラグイン、APIクライアント、またはテーマとの後方互換性に違反する変更が含まれている場合、これらの変更はどの程度必要ですか？ そのような変更の影響は、互換性を妨げるのに十分な大きさですか？ 後方互換性の免責事項は変更リストに含まれていますか？
• 新しいコードは依存関係を追加しますか（たとえば、インポートされた新しいサードパーティモジュール）？ その場合、新しい依存関係が評価されましたか？正しい手順に従って追加されましたか？ < >
  
  
  
  参照してください。
• テストデータコードはテストされていますか？ < >
  
  
  
  参照してください。
• ユーザーインターフェイスが変更された場合、さまざまなサイズの画面でさまざまなブラウザーでテストを実施しましたか？ < >
  
  
  
  参照してください。
• ユーザーインターフェイスが変更された場合、ユーザー補助の要件を満たしていますか？ < >
  
  
  
  参照してください。
• ユーザーに表示される新しい文字列変数が表示された場合、それらは国際化されていましたか？ < >
  
  
  
  参照してください。

包括的に文書化されたプログラミング標準を使用します。



プログラミング標準は、 開発者間の一般的な合意です。 高品質で保守が容易なコードを作成するためのすべてのユーザー向けの一連のバインディング推奨事項。 基準はレビューの基礎です 。なぜなら、レビュー中に基準に準拠しているかどうかコードをチェックするからです。 標準の一部ではないコードに要件を提示する代わりに、推奨事項のリストに含めるよう要求します。



チーム全体がアクセスできる標準の参照プロジェクトがないと、開発者は次のレビューで問題がどこで見つかるかさえ理解できないかもしれません。 そして、これは彼らの仕事に効率を追加しません。



標準は包括的でなければなりません。 PEP 8コードのフォーマットスタイルに依存できますが、これはレビュー中に使用するための完全な標準ではありません。

必要なものを分析し、残りはツールの面倒を見る

レビュー中、コードの書式設定に問題はほとんどありません 。 改訂は生産的な思考と議論の外観を誘発するはずであり、スタイルと書式設定に時間を費やすことは役に立ちません。 そのような場合は、リンターや自動フォーマットツールなどのツールを使用します。

おわりに

この記事では、コードレビュー中に肯定的な結論を出し、提案を成功させる方法を正しく批判する方法について説明します。 キーポイントを強調したこのガイドの簡潔なバージョンを作成し、各チームメンバーに配布することをお勧めします。 誰もがそれを解析して変更を提案できるように、指示を共通のリポジトリに入れてください。そうすれば、チーム全体が議論に関与します。



また、コードの作成方法について検討することをお勧めします。作成したコードはレビューに入ります。 おそらく、コードをレビューする前に 、エンコーダとレビュアーに技術設計を同様に理解してもらいたいでしょう。 特定の機能のコードを作成する人とレビューする人を事前に決定し、最終バージョンを確認する前に、これら2人がコード構造とその中間オプションについて話し合うように協力することを推奨します。 質の高いアーキテクチャが必要です（2つのヘッドが優れています）が、分析中に不必要な議論を回避する必要もあります（両方の開発者が完全に異なるソリューションを提供する場合（一方は完成したコードを完全に書き換える必要があります））。



レビューの前に著者とレビューアの間に強力な協力関係が確立されている場合、レビュー中に、ほとんどの場合、わずかな小さな問題のみが発生します。