コードのレビューを上手にするには？

まず、コードレビュープロセスを固く信じており、常に誰かにコードをレビューしてもらいたいと思っています。私の質問は、他の誰かのためにコードレビューを実行する上で、どうすればより良い仕事をすることができるのかということに本当に集中していますか？

コードレビューを実行するには、既存のコードの仕組みとローカル標準の知識が必要であり、どちらも非常によくわかっていると感じています。それでも、私は他の人のために十分なコードレビューを決してしないように感じています。また、特定の人は他の人よりも優れたジョブレビューコードを実行しているようだということを知っているので、優れたコードレビュアーである人のために、あなたはどのようなテクニックを使用していますか？

より良いコードレビューを行う方法はありません。あなたができることだけが、学習と経験によってそれを改善し続けます。

通常私が従うこと

- Use variables judiciously
- Keep things in scope loose boundaries will generate more errors
- Orient your language of coding in domain specific terms, they make more sense
- Keep loops to minimum 2 for each method if needed
- use ternary operators
- Arrange methods alphabetically
- Keep errors at handling ease
- write less but efficient code

たくさん追加できると思います。

他の人があなたにとって良いレビュアーになる理由を自問してください。

また、コードの説明に従ってください。

• わからないことはやめて、コメントが必要だと書いてください
• コーディング標準（スペース、ブラケット、camelCase..etc）に準拠しているかどうかを識別します
• すべての機能が含まれていることを確認します
• 論理の簡単なテストを行って、境界条件などに合格するかどうかを確認します。

私はただ目指しています

• 提案された変更が必要な理由の説明。修正だけでなく理由を確実に把握する
• コードのフォーマットに同意する-全員のコードが同じ/馴染みがあるように
• 維持したいコード特性のリストを共有します。誰もが一度すべての間違いをする必要がないように、ウィキにそれを置きます。頻繁に更新してください。

それとは別に、「何を探すべきかを知る」ということは、経験、練習、そして読み上げによってもたらされます。

私の経験では、最良の方法はホールチームにコードレビューを行わせることです。各プロジェクトでコミットメーリングリストを使用し、バージョン管理システムへのすべてのコード変更を追跡できます。開発者のほとんどは、コードの変更に関心があるため、プロジェクト固有のメーリングリストに登録しています。

誰かが新しいソースコードで悪い方法に気づいたとき、彼はコミッターが訓練生であればコミッターにもっと良い方法を説明するか、より経験豊富なコミッターであればそれについて議論を始めます。

もちろん、この方法は、特にチームメンバーの誰もが各コードの変更を追う余裕がないストレスの多い時期に、すべての新しいコードがレビューされることを保証しません。また、すべての開発者が責任を持ってすべての開発者が自分の仕事を成功させることを保証するわけではありません。これだけでは、レビューされることを保証できません。しかし、少なくとも私たちのチームには、常に技術的な品質を担当する技術マネージャーがいます。

コードレビューが次のスコアに適合する場合、私はコードレビューの真のファンです。

• すべての開発者は、自分の意見に対するすべてのコードと議論をレビューする可能性があります
• 誰も他のコードを悪用する権利はありません
• 悪いコードは議論を活性化するだけでなく、良いコードも有効にします
• 議論はすべての関係者の幸福で終わります
• レビューはほぼリアルタイムで、少なくとも機能が完了する前に行われます

私が学んだことは、あなたがコードの各行をレビューし、コードのフォーマットやコード効率の点でコード品質のようなものを管理する必要があると思う人なら、マシンができることをするので、あなた自身は非常に非効率的であるということです君は。目標は、各コードコントリビューションのビルドとコード品質を制御する継続的統合システムを使用することです。このシステムがレポートを生成し、それらを寄稿者に送信する場合、すべてが完璧です。

制御する必要があるためにコードを確認する必要がある場合、またはプログラマーの品質をランク付けする必要がある場合、私の提案は意味をなさないことを認めなければなりません。この場合、ソースコードを1行ずつ確認することもありません。次のようなことを確認します。

• セキュリティ関連の問題はありますか
• 使用されるAPI
• コードは指定されたアーキテクチャを適用しましたか
• 彼は有用なテストを書きましたか（ただし、暗黙的に指示された場合のみ、私は学ぶ必要がありました）
• ドキュメンテーション
• ビルドプロセス
• ...その他

あなたが経験豊富な開発者であれば、ループのようなものを見つけて、パフォーマンスを向上させることができます。もちろん、他の人にそのような知識を説明することは有用ですが、これはレビューセッションの一部ではありません。重大なパフォーマンスの問題がある場合、彼（または彼女）がリストタイプの効率の低いバリアントを使用したためではありません。

最初の質問は、なぜ一部の人々が他の人々よりも良いレビューをするように見えるのかということだったので、実際のレビューが始まる前にこれらの人々はおそらくプレビューをすることを答えます。

[H]他の人のためにコードレビューを実行するのにもっと良い仕事をすることができますか？

多くの質問をする

コードレビューを実行するには、既存のコードがどのように機能するかについての知識が必要であることを知っています...

実際、いいえ、良いレビュアーになるために事前にコードを知る必要はありません。

数年前、私の雇用主はすべてのコードチェックインをレビュー担当者にサインオフするよう要求し始めました。私は主にCでGUIの仕事をしていましたが、私にとって最高のレビュアーの1人は相棒のビルでした。彼はCに習熟していましたが、GUIの仕事はあまりしたことがなかったので、レビューに入ると、私のコードがどのように機能するかわかりませんでした。

しかし、彼はそれについて多くの質問をし、私のコードが何をし、なぜ私の側で多くの思考を刺激したかを理解できるように説明する必要がありました。それは私がエッジケースで多くの奇妙な小さなバグを見つけ、私がとったかもしれない他のアプローチを検討することにつながりました。また、その時点で22年間Cを書いていて、かなり上手だと思っていましたが、すぐにコードの品質が向上しました。

私はそこで働いていませんが、チェックイン前に差分を確認し、「これに関してビルはどんな質問をしますか？」と自問します。そして、かなり頻繁に、結果として何かを変えることになります。