标签：工程师 代码 评审 作者 随笔 流程 变更

代码评审时一个由作者意外的人评审代码的流程，通常在将代码引入代码库之前进行。

一些组织在整个代码库中由一组经过选拔的“看门人”，负责评审代码变更。

每天变更在提交强都要经过评审，每个工程师都要负责发起评审和评审变更。

 

代码评审通常需要一个流程，以及支持该流程的工具。

 

代码评审流程

• 作者会在其自己的工作去中编写代码变更。上传代码到代码评审工具中。
• 作者可以对这个补丁进行自动化评审，或者自我评审。
• 平射这在代码评审工具中打开变更，并在差异出处发表评论。
• 作者根据反馈意见修改并上传新的快照，回复给评审人员
• 评审人员对变更的最状态感到满意后，它们同意该变更，并通过标记它为“看起来不错”来接受该变更。
• 编辑为“看起来不错”的变更，允许作者将变更提交到代码库。

 

谷歌如何进行代码评审

　　代码评审由三个方面的“批准”：

　　　　来自另一个工程师的正确性和礼节性检查，以确保代码是适当的，并且代码和作者描述的是一样的。

　　　　来自代码左右着之一的批准，确保代码适合于代码库的这一特定部分，并且可以嵌入到特定的目录中。

　　　　来自具有语言“可读性”认证的人的批准，确保代码负责语言的风格和最佳实践，并检查代码是否以我们期望的方式编写。

 

代码评审的好处

　　检查代码正确性

　　确保代码变更能够被其他工程师理解

　　增强整个代码库的一致性

　　心里上促进团队的责任感

　　知识共享

　　提供代码评审本身的历史记录

 

　　代码正确性

　　　　让一双眼睛来审视一个变更，有助于确保变更达到预期效果。

　　　　评审人员通常关注变更是否由适当的测试、设计得当、功能正确且有效。

　　　　为防止对正确性的评价变得主观化而非客观化，无论是设计上还是在引入变更的功能上，作者通常都会遵循它们的特定方法。

　　　　在初始代码评审流程中检查缺陷任然是一般“左移策略”中一个不可分割的组成部分，旨在尽早发现并解决问题，从而无需在开发周期中进一步增加成本和资源。

　　代码理解

　　　　根据作者的视角体哦那个不带偏见的反馈。

　　　　代码评审通常是对给定的变更是否“对更广泛的读者而言是可以理解的”的第一次测试。

　　　　找一个与作者观点不同的评审者通常是有用的，尤其是哪些可能需要维护或者使用变更代码的评审者。

　　　　代码正确性于代码理解性检查是另一个获得工程师“看起来不错”的主要标准，它是代码评审所需的批准之一。

　　代码一致性

　　　　达到一定规模以后，你编写的代码就会依赖其他人，并最终由其他人维护。

　　　　许多人需要阅读你的代码，并理解你所做的东西。

　　　　代码应该遵循某些一致性标准，以便理解和维护。

　　　　代码可应该避免过于复杂，更简单的代码更容易让其他人理解和维护。

　　心里和文化方面的好处

　　　　代码评审还有重要的文化好处。

　　　　它向软件工程师强调，代码不是“他们的”，而是一个集体企业的一部分。

　　　　为自己的技艺感到自豪，不愿向他人公开代码，这是人类的天性。

　　　　代码评审的另一个在心理方面的好处是验证。即使最有能力的工程师也可能患上“冒名顶替综合征”，并且过于自我批评。

　　　　当一个工程师在他们的领域知识增长中，他们有时很难得到关于他们如何提供的积极反馈，代码评审可以提供这种机制。

　　　　启动代码评审也迫使所有作者对他们的变更更加小心。

　　知识共享

　　　　代码评审最重要的却被低估的好处之一是知识共享。

　　　　代码评审的一部分：反馈和确认是用来询问为什么以特定的方式完成变更。

 

代码评审最佳实践

　　礼貌而专业

　　　　代码评审甚至会给最有能力的工程师带来焦虑和压力，因此他们需要保持反馈和批评的专业性。

　　　　一般而言，评审者应尊重作者对特性方案的意见，只有在作者作用的实现方案有缺陷时，才提出替代方案。

　　　　评审者应该即使反馈意见。

　　　　正如我们期望评审者专业性一样，我们也期望作者的专业性。

　　　　将代码评审中的每个评审者的评论视为TODO项是很重要的。

　　小的变更

　　　　保持代码评审流程灵活最重要的实践可能算是保持小的变更。

　　　　代码评审应该易于理解，只关注单个问题。

　　　　“小的变更”通常应该限制在大约200行代码以内。

　　　　保持小的变更也允许 评审者 更快的批准任何给定的变更。

　　清晰的变革描述

　　　　变更描述应该在第一行以摘要的形式说明其变更类型。

　　评审者数量最小化

　　　　代码评审最好是有一个人完成

　　尽可能的自动化

　　　　代码评审是一个人工流程，人工输入很重要，但是如果编码过程又可以自动化的部分，那么尝试这样做。

 

代码评审类型

　　绿地评审和新特性开发

　　行为变更、改进、优化

　　缺陷修复和回滚

　　重构和大规模变更那个

 

　　绿地代码评审

　　　　最不常见的代码评审类型是全新代码，即所谓的绿地评审。

　　　　绿地评审是评估代码是否经得起时间考验的最重要时间。

　　　　随着时间和规模的改变，代码的基础假设随之改变，代码维护起来更加容易。

　　　　为确保代码的可持续性，绿地评审应该i确保API与商定的设计相匹配，并经过充分测试。

　　　　所有API端点，都由某种形式的单元测试，并且当代码的假设发生变化时，这些测试会失败。

　　行为变更、改进和优化

　　　　适用绿地评审的准测。

　　　　对代码库的一些最好的修改实际上是删除，消除无效或者过时的代码是改进代码库整体代码库健康状况的最好方法之一。

　　　　任何对行为的修改都必须包括任何新的API行为对应的测试用例进行的修订。

　　缺陷修复和回滚

　　　　提交一个新的变更用于修复缺陷时，应该避免试图去解决其他问题。

标签：工程师,代码,评审,作者,随笔,流程,变更
来源： https://www.cnblogs.com/use-D/p/16449178.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。