代码评审:超越代码，融入公司文化
代码评审:超越代码，融入公司文化
原文：https://medium.com/hackernoon/code-review-beyond-code-into-company-culture-36233561941a
总结:很多公司练习' 代码评审 '来减少技术债。然而，通过更多的思考和关注，“代码评审”可以影响公司的 文化 ，培养谦逊、开放&的积极沟通，朝着更好的方向前进，并获得尊重。本文提出了三个简单的步骤来挖掘“代码审查”的潜在潜力，其中包括引入两个概念指导方针:“情境批评”和“基于意图的批评”。
代码评审起源
许多年前，术语代码评审会让人联想到产品开发的缓慢。就像没有‘黑暗’就无法充分欣赏的‘光’一样，技术债，在很多博文中阐述的，成了代码评审从中闪耀的‘黑暗’。技术债务产生于每一段新代码，它降低了代码库的整体可维护性和可扩展性。这可能是由编码器造成的:
- 不知道某种编码最佳实践
- 不知道代码不同部分之间的所有依赖关系
- 没有完全理解一段代码的原始意图，从而无意中破坏了任何计划的可扩展性
- 由于个人有限的编码经验导致的狭隘视野，忽略了构建特性的更好方法
- 不断地优先考虑特性的最后期限，而不是精心制作的代码，并且之后不进行代码重构
- 过度工程化，或过早优化代码，而不是经常&尽早发布代码，导致代码膨胀
代码评审带来了一双新鲜的眼睛，它减轻(而不是根除)了前 4 个问题，并作为后 2 个问题的制衡机制。
顺便说一下，代码评审也在团队中传播关于代码库的知识。
代码审查的潜在潜力
代码评审除了减少技术债务，平衡开发发布周期之外，还能发挥更深远的作用；如果处理得当，它可以建立伟大的团队文化。它培育了:
- 谦逊:团队学会了接受没有人会永远正确，犯错是人之常情，因此他们乐于接受积极的批评
- 开放的积极沟通:团队张开双臂接受积极的批评，作为学习的机会，这反过来鼓励其他人不断提供反馈
- 向更好的目标看齐:团队理解代码评审的意图，以改进代码库，以及与它一起工作的人，因此总是与那些心灵相通的人交流。意图上的一致鼓励每个人容忍冲突，以及有利于保留意图的模糊性
- 尊重:团队学习尊重指导方针，这包含了每个人的兴趣，当指导方针有所欠缺时，每个人都朝着尊重更大利益的方向努力
不幸的是代码审查和它所孕育的文化不会在一夜之间发生，他们要求我们为之努力。幸运的是，有了一套编码和行为指南，我们可以释放它的全部潜力。
释放代码审查的文化潜力
代码审查，如果在没有支持机制的情况下被提倡，通常会以其中一个极端结束:
- 有人滥用代码评审作为提升自己地位和压制他人的机会，这让代码评审变成了噩梦
- 每个人都小心翼翼地保持一个和谐的环境，不互相批评，这违背了代码评审的目的
为了克服这些，代码评审需要一个意图(目的)的正式声明，以及一套指南来支持意图。
代码审查:意图
代码评审的目的集中在每个人的利益上，以鼓励他们支持它，并把它作为抵御破坏它的行为的原则。代码审查应该:
- 构建可维护和可扩展的代码，这是一种乐趣
- 提高每个人的编码能力，以及对代码库的理解
代码审查:指南
有两种类型的指导方针(编码和行为)需要让每个人都快速地在同一页面上保持代码审查的意图，以及什么构成了违反。它们也成为调和分歧的参照点。
编码指南
这些是被社区接受的众所周知的编码实践，它们关注于代码组成和代码风格。前者实施编码原则，例如数据完整性，它要求在数据库表中使用外键等。，而后者鼓励一致性，这有助于可读性和理解，例如，代码首选项，它记录了一些细节，如对于循环，更喜欢使用而不是。有很多关于这两方面的文章，所以我给你一个建议:
不要花费数周时间去思考使用哪种最佳实践；现在就从任何一个开始，然后随着团队的发展进行调整
行为准则
人们很容易对“积极的批评”这个词吹毛求疵，但它的解释范围太广，而且过度依赖于给予者的机智和谨慎，而这可能不是程序员天生就有的，尤其是初级程序员。
为了万无一失的“积极批评”，我们要求它既是一种情境批评又是一种基于意图的批评。
情境批评
- 一段批评应该基于一段特定的代码，在特定的环境下，在特定的时间
这就消除了批评者对接受者的影射，从而传达了一种解脱感，使给予和接受都变得容易。
此外，它转移了确保批评确实是针对接受者的责任；同样的情景批评的重复出现就相当于对惯犯的申斥。
基于意图的批评
- 任何批评都必须坚持代码评审的形式意图
因为代码审查的目的是改进每个人和代码库，所以基于目的的批评有一种积极的氛围，应该非常有用，使给予和接受都很容易。
代码评审的具体例子(更新 2018–06–02)
这里有几个结合了情境和意图的“好”代码评审示例，以及几个“不好”的示例。
好的
例 1 :
如果我们在这里使用 switch 语句，将来会更容易理解吗？
- “更容易理解”:阐明让代码更容易理解的意图
- “在这里使用 switch 语句”:进行代码审查情景
例二:
在这部分代码中，使用工厂模式是否有可能在未来处理新的用例？
- “使处理新用例成为可能”:阐明使代码易于使用的意图
- '在这部分代码中':进行代码评审情景
不好
例 1 :
使用 switch 语句代替多个 if 是一个好习惯。
- 缺少对意图的解释
例二:
您应该使用工厂模式来确保代码可以处理新的用例。
- 暗示编码者不理解工厂模式，因此代码审查似乎不是情境
注意，好的代码评审例子通常也是有启发性的，吸引人的讨论，或者格式化成问题的形式。
数据驱动的文化
如果你热衷于使用数据为你的公司提供动力，并且相信持续的实时反馈(而不是挥挥手，“我们有一个开放的政策，你可以随时进来告诉我们你的问题)，那么只需点击一下re:Culture就可以开始了解团队采用代码评审的情况。
包扎
我们希望你对代码审查在建立伟大的公司文化中的潜在作用深信不疑并感到兴奋。通过 3 个简单的步骤:形式化代码审查的意图，用社区最佳实践实现编码指南，用情境和基于意图的批评实现行为指南，您就拥有了转变公司文化的所有工具。
黑客中午是黑客如何开始他们的下午。我们是 @AMI 家庭的一员。我们现在接受投稿并乐意讨论广告&赞助机会。
要了解更多信息，请阅读我们的“关于”页面、赞/在脸书给我们发消息，或者简单地说， tweet/DM @HackerNoon。