あなたがコードレビューの習慣を持っている場合、後は毎日、コードを書かれましたか？
無視バグの開発を見つけることを目指しているコードレビューコードレビューは、大幅にコードの品質を向上させるために、また、プロジェクトで開発者がより身近に役立つことができます。残念ながら、多くの業界の開発者は、定期的なコードレビューに慣れていません。だから、プログラマのために、それが必要な仕事であるかどうかを確認しますか？
作者| Gergely Orosz
翻訳|半月板、Zebian |火ミン
出品 | CSDN（ID：CSDNnews）
以下は翻訳です。
十年、私は、コードレビューとして働いていました。コードレビューの多くの利点：他の人の視点だけでなく、知識共有ツールと自動化の改善から、コードの変更をお読みください。あなたがコードレビューをお持ちでない場合は、その後、私は強く、この勧告（https://twitter.com/codinghorror）、あなたは2006年にジェフ・アトウッドのシェアに従うことをお勧めします。
コードレビュー、コードレビューと良識のためのベストプラクティスを共有するための多くの人々や組織。共有SmartBearチーム、エンジニアリングチームと導くPalantirエンジニアフィリップ・ハウアーは良い読み物です。良いコードレビューの私の個人的な見解は次のとおりです、そしてどのように良くやって。背景紙は、私は今、ユーバーを含める私の仕事の技術的な環境であり、MicrosoftのSkypeとスカイスキャナーの前に。
コードレビューによってカバーされるエリア
良いコードレビューアは、コード自体を変更することを見ていきます、と既存のコードのために、これらの変更かどうか。彼らは慎重にコードを変更するタイトルや説明、および「理由」を勉強します。彼らはまた、コード、テストカバレッジの正しさを確認する機能の変更やプログラミングのガイドラインとベストプラクティスに従ってくださいます。それと同時に、彼らはまた、例えば、コード、あいまいな名前を理解し、コード、コードテストされていないか、未処理のエッジケースをコメントアウトすることは困難であり、改善のための重要な領域を指摘します。最後に、彼らはまた、提出があまりにも多くのコードの変更が含まれている場合、単一の目的を残さなければならないコードを変更することが推奨されていることに注意して、コードの変更は、より焦点を絞ったターゲットのいくつかの部分に分解する。
より良いコードレビューアは、システム全体の観点から、コードの変更を見ていきますと、簡単にこれらの変更は維持するかどうかをチェックします。彼らは、コードの変更や原因システムの他の部分への影響のための必要性を求めることができます。彼らは、コードで導入された既存のソフトウェアアーキテクチャに抽象的で適応性を検討します。さらに、それらはまた、複雑なロジックは、テスト、反復、および他の可能な改善の構造を簡素化することができるかどうかなどのメンテナンスを、観察します。予備審査と包括的なレビュー：この記事（https://medium.com/@mrjoelkemp/giving-better-code-reviews-16109e0fdd36）でエンジニアジョエルケンプは、コードは2つのレベルに分かれて検討します。
トーンレビュー
トーンコードレビューが大幅にチーム内の士気に影響を与えることができます。過酷なコメントは、劣悪な労働条件につながる可能性があります。独善言語は、人々が白熱した議論を引き起こして、敵対的な気分にさせることがあります。同時に、専門的かつ積極的な気分は、より包括的な環境を開発することができます。これらの環境の人々は建設的なフィードバックを受け入れることができ、およびコードレビューは、健康的で活発な議論につながります。
良いコードレビュー担当者は、オープンエンドの質問をする、というよりも強いか独断文を発行します。彼らは、他のソリューションに代わるものを提供します。これらのレビューは、彼らがコンテンツの一部を見逃しているかもしれないと思うだろうので、彼らは最初の明確化を求めるのではなく、修正をお願いします。
人事思いやり、より良いコードレビュー。彼らは、人々は、コードがこれらの変化に対応するために多くの時間と労力を費やして書くことを知っています。コードレビューのスタッフではない良い宣伝。彼らは優れたソリューションと包括的なポジティブアクションの強い感謝となります。
変更要求を承認
オープンエンドの質問がある場合、良好なコードレビューアはコードの変更を承認しません。しかし、彼らは明らかに障害物や重要でないを起こさない質問やコメント表示され、通常、監査意見は、次のように呼ばれている「重要な。」彼らは非常に明確な変更のみの場合には変更を承認（例えば、「私の意見では非常に良い。」と記されました）。あなたがフォローアップする必要がある場合、彼らは間違いなく同じコードレビューツールを使用するか、または習慣を伝えるためにチームに従います。
更优秀的代码审查人员在面临需要回答某些问题或解决重要问题之前，也不会批准代码更改。这种审核在原则上是坚定的，但在实践上却是灵活的：有时，写代码的人会在后续代码变更中单独解决审核指摘的问题。有些更改比较紧急，所以审查人员会尽快地推动审查。
从代码审查到彼此交谈
良好的代码审查人员会尽可能地留下评论和问题。如果经过修改后仍然有残留问题，他们也会记录下来。如果来回的评论过多，那么审核人员会舍弃过于耗时的工具，而选择面对面交谈。
更优秀的代码审查人员在第一次审核完毕，但有很多评论和问题时，会主动联系写代码的人。他们知道与其在评论中来回反复，还不如面对面的交谈，因为这种方式可以节省大量的时间，还可以省却不少误解和麻烦。很多针对代码的评论表明，审查双方往往会存在一些误解。彼此的交谈更容易消除误解。
吹毛求疵
如前所述，良好的代码审查人员会清楚地表明哪些评论不重要，或有点挑剔。这方面的审查问题包括变量声明按字母顺序排列、测试结构遵循某个结构或括号位于同一行或下一行。
通常，良好的代码审查人员不会有太多的挑剔。鸡蛋里挑骨头会打击人的积极性，而且也会让大家丧失对重要问题的关注。
更优秀的代码审查人员明白太多的挑剔意味着缺乏工具或缺乏标准。经常遇到这些问题的审核人员会考虑在代码审查流程之外解决这个问题。例如，大多数常见的挑剔都可以通过自动linting来解决。如果无法通过工具解决，则应该由团队协商采用某些标准来解决，然后继续跟进这个问题，甚至可以自动化。
零基础如何开始学Python？14年开发经验大神分享
新加入代码审查的人
良好的代码审查人员会一视同仁，采用相同的质量标准和方法，无论他们的职位，级别以及加入公司的长短。根据上述内容，通常代码审查人员都会很和善，只在有必要的时候请求变更，并在收到许多意见时与他们进行交谈。
更优秀的代码审查人员更加注重给新加入的人留下一个好印象。审查人员明白新来的人可能不了解所有的编程指南，而且也可能不熟悉代码的某些部分。所以，他们会进一步努力解释替代方案，或建议他们阅读编程指南。他们还会使用非常积极的语气，鼓励写代码的人刚开始提交的代码变更。
跨办公室及跨时区审查
如果写代码的人和审查人员不在同一个地点时，代码审查会变得更困难。当审核人员位于不同的时区时，这种难度就会更高。多年来，我力争公平地审查所有代码，无论是美国、亚洲还是欧洲团队所提交的代码。
良好的代码审查人员会尽可能地考虑时区差异。审查人员都会努力在双方都办公的时间内审查代码。如果遇到很多评论的情况，则会选择直接聊天或进行视频通话。
更优秀的代码审查人员在反复遇到时区问题时，就会努力寻找代码审查框架之外的系统解决方案。假设某个欧洲的团队经常更改某项服务，而代码审查则由美国负责这项服务的人来进行。系统级的问题是，这些变化如此频繁发生的原因是什么？随着时间的推移，变化的频率相同还是下降了？假设代码变更是在正确的代码库中完成的，且频率没有下降，那么是否应该打破这种跨部门的依赖性？解决这些问题往往不简单，可能涉及重构，或者创建新的服务/接口，或改进工具。解除这种依赖关系会让两个团队都更加轻松，更有效地推动工作。
组织的支持
公司及其工程组织如何看待代码审查是影响代码审查的重要因素。如果组织认为代码审查无关紧要或微不足道，就不会在这方面投入太多。在这样的文化中，在某些情况下，开发人员将不得不放弃代码审查。倡导实施更好的代码审查的工程师可能会感到孤立，而且也无法获得获得上述支持，最终放弃。如果组织认为代码审查是工程中的关键部分，那么他们就会为工程师提供更好的工作环境。
拥有良好代码审查的组织会确保所有工程师都参与代码审查流程，包括那些单独在某个项目上工作的人员。他们鼓励提高质量标准。这些团队会积极地讨论从团队和组织层面开展代码审查。通常，这些公司都有工程师发起和编写的大型代码库的代码审查指南。这样的组织中，理解代码审查会占用工程师的很多时间。许多这样的公司在招聘开发人员时，也会将代码审查作为一项重要的工作能力，并希望高级工程师花费更多的时间来审查其他人的代码。
拥有更好的代码审查的组织会建立硬性规则：没有经过代码审查的代码不能投入到生产中，就像没有经过自动化测试的业务逻辑更改不能进入生产环境一样。这些组织明白，削减这样的成本根本不值得，相反他们拥有在紧急情况下，加快审查团队和组织代码审查的流程。这些组织会投资提高开发人员的工作效率，其中包括更有效的代码审查和工具改进。这些公司的高管通常都是软件工程师，你不需要说服他们有关代码审查和其他工程最佳实践的好处。相反，他们支持团队利用更好的工具，或更有效的代码审查流程。
当写代码的人感受到恶意的评论时，他们可以说出来并全力支持解决问题。高级工程师和管理人员认为不达标的代码评审与劣质的代码或不健全的功能同等严重。工程师和工程经理都感觉有责任改进代码审查的开展方式。
原文：https://blog.pragmaticengineer.com/good-code-reviews-better-code-reviews/
作者：Gergely Orosz，软件工程师，主要从事移动、Web和后台开发。
この記事CSDNの翻訳は、元のソースを明記してください。
CSDN 5Gサロンが来ます！
6月29日、魏清、マイクロソフト（中国）最高技術責任者、情報と北京郵電大学/日松林博士課程の家庭教師、シニアリサーチディレクターシャオジャン金山ユンAIoT課の通信工学、マルチメディア技術研究センター、エリクソン中国R＆Dの学校のディレクターマルチアンテナZhuhuaiソング、エリクソン中国R＆Dシステムエンジニア劉ヤンと他のトップ業界のリーダーのディレクターのシニア専門家は、上級技術専門家は、物事のインターネットで5G大きな可能性を議論するために一緒に来ます。
Fanger魏コードスキャン、すぐに生きる約束をします！
感熱紙 を推奨
☞ 書き込みコードが厳密ではないですが、私はプログラマであることを値しありませんか？
☞ 北京郵電大学、あなたは秒4G / 5G差を知っていると博士ワンワードテキスト通信！
☞ プログラマはどのようにオフの単一のですか？|プログラマーの何かを言うために
☞ 5Gの時代には、Microsoftはチェスのステップを行ってきました！
☞ LinkedInの最新レポート：需要の急成長を遂げている分野を投稿するブロック鎖、チェーン最高のを阻止するために、これらの地域の人々の願い......
☞ バートローリング？NLPのタスクのために何XLnetの「火のリスト」を意味
☞ 血液の概要を嘔吐！100のインタビューの質問Pythonのコレクション（上）
☞ コンテナ記事の技術的な在庫の2019年は、（A）：UCloudは風と水K8Sの話を聞く|筋金入りのプログラマ評価
☞ 17歳のプログラマーがあなたのプログラミングについての7つの重要な教訓を教えて！
オリジナル、ライブの予定を読むためにクリックしてください。
それぞれ「見た目」のあなたのポイント、私は真剣に好きなように