咱们作为软件工程师，工作上放弃代码审查的习惯是很重要的。 而审查其实就像编写代码一样，必须一直练习并提供反馈，这一点至关重要。 以下是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-t...

以上信息来源于网络，由“京东智联云开发者”公众号编辑整理，

不代表京东智联云立场

浏览原文