标签：同步 blog 记录 系统 解决方案 阶段 高质量 内容 检查
我们作为软件工程师，工作上保持代码审查的习惯是很重要的。 而审查其实就像编写代码一样，必须不断练习并提供反馈，这一点至关重要。 以下是VTS工程师制订的代码审查目标及一些改善建议。
代码审查的两个主要目标是：
1
提高代码质量
审查可以通过以下方式提高代码质量：
查找并修复代码漏洞—我们需要高质量的代码，特别是在应用程序已经面向大众的情况下。
验证现在的程序是否能够配合未来的更新。
找到bug和极端情况—并非所有的bug或极端情况都能被发现，但是通过审查可以减少它们。而且扫除过程中的专注阅读是很好的学习机会。
遵循良好的commit规范。
2
共享技术和领域知识
代码审查的交互过程让编程人员和审查人员可以相互学习分享，共同进步。
下面的实践可以帮助您在进行代码审查时实现以上目标。
1
寻找自己及团队对代码审查的角度
试问自己—为什么您(或您的团队)要求对代码进行审核? 您立即会以您所属领域的技术知识来回答，而思考出发点的不同可以使您以不同的角度审查代码，同样地，您团队的成员也会带着自己的角度去进行代码审查。因此您可以选择自己一个人以单一的角度审查所有代码，或者与团队协作，以不同角度去审查代码。
团队一旦熟悉了不同队员的审查角度，个人就更容易知道如何为代码做出贡献。您可以改善新架构的设计吗？您可以帮助重构某些代码吗？您是否可以从您自身的经验中发现到一些未解决的edge cases？这些问题都可以帮助您找出自己专业的领域。
即便代码问题成功解决了，你仍然可以从您的角度考虑如何解决问题。您的解决方案是否不同，或者更好？您的解决方案可能会有所不同，因为您：
具有不同的技能和/或经验水平。
在要解决的问题上没有刻板认知。
为问题带来不同的领域知识（例如在数据质量与性能方面）。
对代码库有不同程度的了解和经验。
不同的解决方案并不一定意味着一个要比另一种更好，这仅仅是解决问题的另一种方式。如果您觉得其他解决方案更好，请务必向团队说明原因。这些差异可能会引起有关开发者的疑问，有机会因此而引发建设性对话。
上述做法的结果是—您可以提供原作者没有或可能没有考虑过的观点。
2
不要批准您不了解的项目
这适用于所有级别的工程师。如果您需要更多信息，请询问原作者。 如果原作者希望您为他们审查代码，那么他们将花时间向您解释代码。
您在开口请求代码审查时不应感到压力，您也不应因为不了解内容所以主动发问而感到惭愧。 对于每个工作场所而言，提高团队的心理安全感至关重要，这样每个人都可以自由地分享想法和提出问题。
还有一种可能是，如果您不理解内容，那么可能作者自己其实也不理解内容。 他也许是从Stack Overflow复制/粘贴的；也许他们放弃了代码，不记得自己想做什么；也许太复杂了。所以在代码合并及修改前请确保理解原作者的想表达的意思。
上述做法的结果是—令我们找到更简单的解决方案，更易于维护和开发。
3
在本地检验运行
有时候您需要查看代码在整个系统中的使用情况。 在这种情况下，您需要在您的编辑器中浏览文件并在本地检验运行。 提出类似的问题：
该方法是否正确使用？
这是否遵循与其他类别相同的设计？
是否还有更多重构的机会，它们是否可以与此代码合并？
测试足够全面吗？
这如何与系统的其余部分集成？
上述问题的回答是—能帮助您更好地理解代码与软件整体相适应的关系。甚至可以引导您找到进一步的机会来重构或修复原代码。
4
避免无建设性意见的批评
如果代码合并上确实存在缺陷，那么指出错误是很重要的。 但同样重要的是，在能改进和不破坏原结构的前提下，提出有关修复或避免该缺陷的建议。
您可以先是解释无法正常工作的内容，然后提出更好的解决方案来做到这一点。您还可以透过一些链接文章或使用stack overflow来为其找出答案。
诚然，有时您可能知道有一种改进方法，但是不确定该怎么做。如果面对这种情况，请务必为原作者留下一个开放式问题，以便您可以就如何解决此问题进行对话。
这种做法的结果是—原作者理解为什么提出批评以及可以采取什么解决方案。
5
寻找赞赏别人的机会
我们都需要正向的反馈，以增强我们的信心。 请求其他人修改代码是一项艰巨的任务。 我们需要找到方法，以不断鼓励彼此尽力而为。 您知道原作者正在努力学习更强的代码重构技术？ 如果您看到他们的努力，请不要吝啬并告诉他们现阶段取得的成果。 代码现在更具可读性了吗？ 为此赞美他们—这些赞美对团队中的所有人都管用。
另一个好处是，这些对他人的赞美表明您认真对待了此次审核。 有时我们没有任何反馈，只是批准修改。 作者怎么知道您真的看过它？ 给予代码中某特定部分很高的评价是一种方法。
这种做法的结果是—使原作者感到鼓舞，他们继续为该代码做出贡献，并继续学习来提高自己的技能。
6
保持紧密的反馈
在编写代码的整个过程中，反馈很重要。 选择适当的时机，在代码合并之前寻求他人的反馈。 在项目初期，通常不必询问与代码有关的问题。 您可以查看是否还有未考虑过的想法，或者目前境况是否就是继续努力的最佳途径。 尽早与您的队友或具有领域/背景知识的人交谈。
在收到反馈后，请务必快速回应每一个观点。 继续回头去处理代码合拼很重要，只有这样代码才不会被放弃。 它还将帮助您不用过于频繁地进行上下文切换修改。
您还应该平衡异步和同步对话。 有时，面对面交谈并确保各方之间的理解会更快。那么如果面对异步交流，就请务必以书面形式记录下来。
上述做法的结果是—更快地完成您的代码合拼。如果恰好您要处理包含大量合并的大型代码库，那么这一点尤其重要。
7
建立有关commits的笔记
这个简单的细节是值得做的，笔记作为代码检查实践的一部分，是至关重要的。为了帮助代码审查人的阅读，作者需要保持干净且内容丰富的commits笔记。良好的commits笔记可以帮助开发者获得最有用的反馈。
良好的commits笔记代表commits是垂直而不是水平分解的。这也意味着每次commits后都能通过所有测试，并且不会破坏主分支。良好的commits笔记也代表修改后的代码能够融入主架构。透过commits笔记，这使得审查代码的人可以知道开发者的想法和决策。良好的commits笔记还留下了您进行修改的详细原因。简单来说，commits笔记可以记录您在代码的修改，可以充当应用程序的文档。最后，良好的commits笔记应该是独立的，这意味着它们自身的存在就是有价值的，并且不需要审阅者查看其他笔记就可以理解它们。
作为审阅者，您也需要寻找机会来做出好的commits笔记。
上述实践的结果是—能生成一个信息全面且丰富的代码库，这些commits笔记能帮助使您的应用程序可持续发展。另一个积极的结果是，它使代码审查更加容易。
??原文链接：
https://buildingvts.com/how-to-make-the-most-out-of-code-reviews-53ba14a11948
以上信息来源于网络，由“京东智联云开发者”公众号编辑整理，
不代表京东智联云立场
标签：同步 blog 记录 系统 解决方案 阶段 高质量 内容 检查
原文地址：https://www.cnblogs.com/jdclouddeveloper/p/13380189.html
