また、私は「ティムリッドの祝福」が何であるかを知っていました-すでにロシアのスタートアップで働いていた次の仕事の場所では、コードの品質はリポジトリの私のブランチを密かに訪問し、そこで正しいコミットを行いました。 時々、彼は私の行を削除せずにコメントし、「これを書いたのは二度としない」や「簡単にできる」などのメモを残して、会社の階層における自分の位置を明確に示し、さらに、家族のコンピューターでブラウザーの履歴を消去するのを忘れたティーンエイジャー。
HeadHunterで仕事を得たとき、それはすべて悪い夢のように終わりました。
「レビューコードがあります」とフロントエンドのグループリーダーがインタビューで私に語った。
-うわー、クール！ 私は、用語があなたに馴染みのないことを決して示すべきではないことを思い出して、答えました。
コードレビューは、タスクのリリース前に他の開発者が校正することにより、プロジェクトのコードの品質を維持できるようにするプラクティスです。 これは、コーディングを終えたすべてのプログラマーが同僚に次のように伝えることを意味します。「やあ、あれこれあれやった-見て、すべてがきちんと整っていることを確認してください。 同僚は彼のコードに目を向け、タイプミスに注意し、セマンティック、論理的および技術的な不正確さを指摘し、それらを修正することを提案し、より効果的なソリューションを提供します。 開発者はそれらに同意または反対し、妥協案を見つけ、責任者として任命された後、クリーンな（可能な限り）コードが実稼働環境に送信されます。
レビューは、ほとんど開発のような魅力的で複雑なプロセスです。 タスクの質（複雑さ、興味、ホリバーと相互トローリングの可能性、実際のコード）に応じて、2〜数十人の開発者が議論に参加でき、数分かかることがあります（「こんにちは、問題があります...」- 「レビュー済み」）最大数週間（「Re：Re：Re：Re：グローバルエリアビューの変数... [23:40]」）。
コードをレビューするには多くの方法があります。 議論中に直接調整が行われる場合、ペアプログラミングのオプションを好む人がいます。 これは、タスクが自明ではなく、詳細を議論する前に、何が起こっているかの本質を理解する必要がある場合に役立ちます。 しかし、通常は非同期で作業し、コメントでの議論をコードに導きながら他のことを行う方が便利です。 hh.ruフロントエンドベンダーの間では、2番目のオプションがはるかに人気があります。 まず、それは美しいからです。
第二に、あなたはいつでも他の開発者に頼って紛争を解決するために協力できるからです。
第三に、この方法で1石で2羽の鳥を殺すからです。コードをきれいに保ち、これらの行またはこれらの行が追加された理由を理解するのに役立つドキュメントを作成します。
著者を見つけます。
彼を理解してください。
レビューには間違いなく短所があります。 主なものは、開発時間の増加です。 プロトタイプまたはMVPで作業していて、「すばやく動作させる」必要がある場合、些細なことで欠陥を見つけたいという誘惑のあるレビューは、すべてを台無しにするだけです。 最も一般的であると同時に最も厄介なのは、セマンティックニッピッキングです。 最初に人間の血を味わった吸血鬼として、私は最初に出会った余分なギャップの後にすぐに味を覚えました。 1週間後、私はすでに1つのランダムな転送を見逃すことのない容赦ない文法国家でした-PEP 8だけで、1行あたり79文字しかありません。
もう1つの大きなマイナス点は主観性です。 アルゴリズム、モデル、テクノロジーはありますが、習慣、奇妙な点、シンプルな味があります。同僚は、あなたのアプローチが間違っていて、非効率的で、見苦しく、議論が行われないと考えるかもしれません。 ここで、意味論争の最後の言葉は著者にかかっているというルールは非常に役立ちます。
一般に、すべての副作用があるため、レビューは非常に便利なツールです。特に、長期的なコードベースと多数の開発スタッフを抱える大企業では便利です。
このプラクティスをプロジェクトに実装したい場合は、このための特別に考案されたツール（ StashやUpsourceなど ）に慣れることが良いスタートです-ホイールを再発明せず、最終的に「修正しました」アプローチに戻りません。 また、GitHubを使用している場合は、新しいブランチごとにプルリクエストを作成できます。タスクの簡単な説明は、「問題-理由-解決」という形式の簡単な説明または「ドキュメンタリーレイアウトについて話している）。 最初は、これをオプションとして実行し、標準のワークフローに含めることができます。タスクが存在する場合、それに対応するプルリクエストが必要です。
そして、チームに完璧主義者やスペースハンターが多すぎると、IDEのユーティリティとプラグインが助けになり、開発段階でフォーマットと構文を監視します。 開発に関するすべてのことのように、主なことは夢中にならず、オーバーエンジニアリングに移行しないことです-そして、もちろん、世界を少し良くする機会があります。
@dudeいいえ、「もう少し理想に近い」と書きましょう。
@vanowskiいいえ、それは残念です、彼らはそれを言いません。 単に-「より良い」すべて。
@dudeさて、引用符とダッシュ、e上のドットを修正してください-
（キャプション。）