代码审阅Code Review金字塔
当涉及到代码审查Code Review时，一个普遍的现象是，围绕着代码格式和风格等平凡的方面有很多关注和冗长的讨论，而重要的方面（代码修改是否做了它应该做的事情，它是否具有性能，它是否向后兼容现有的客户端，以及其他许多方面）往往不太受关注。
此图原出处.
- 自动化检查： 代码风格和单元测试，这个可以在代码提交时进行、并由SonarQube定期检查，着重于代码的简洁、可测试，可维护
- 人工代码检查：主要关注文档、实现语义及API语义，着重于代码的性能、可扩展性、可靠性。
每个现代软件开发过程都包含某种形式的代码审查。他们确保所有的代码都由作者以外的人审阅。这改善了上下文，提高了代码质量，并普遍导致了一个更强大的团队和产品。然而，代码审查有很大的不同，峰值在最高层，但如果不通过较低的层级，就不可能达到最高层。另一个观察结果是，较低的层次可以由个人完成，但倒数第二层则需要团队努力。
风格。这就是我猜想的大多数人认为的代码审查，范围包括告诉作者添加注释、修正错别字或重命名变量的反馈。这一点很重要，因为它是其他一切工作的基础，但同时它也不会改变任何功能。
代码。在这个层面上，反馈的目的是改变代码本身--哪怕只是稍微改变一下。这包括提出方法的替代实现或清理代码的方法，使其更容易阅读和测试。在这个层次上，有经验的工程师也可以指出现有的方法或库，以避免代码的重复，或推动较大的方法被分割成较小的、更可测试的方法。
架构。如果做得好的话，架构在写代码之前就已经确定了，但很多时候，在写代码的过程中或之后就会出现问题或想法。当然，我们可以按原样发送代码，但如果它是一个关键的组件，清理它是有好处的--即使它迫使你重做应用程序的组织和架构方式。
哲学。功能最强的团队都是围绕着代码哲学凝聚起来的。他们对代码库有一个共同的、隐含的理解，并理解应该在哪里以及如何实现功能。他们不是专注于低层次的实现细节，而是考虑功能应该存在于哪里，以便在代码的其他部分有意义，以及如何保持事情的一致性。那些长期合作的团队通常会有机地开始这样做，但这也是所有团队都应该努力的。
大多数人把代码审查与金字塔的第一层联系起来，但这只是一个开始。为了实现最好的代码，我们需要推动我们自己和我们的团队对代码进行更深入的思考，而不是仅仅关注表面的因素。
今天先到这儿，希望对云原生，技术领导力， 企业管理，系统架构设计与评估，团队管理, 项目管理, 产品管管，团队建设 有参考作用 , 您可能感兴趣的文章:
领导人怎样带领好团队
构建创业公司突击小团队
国际化环境下系统架构演化
微服务架构设计
视频直播平台的系统架构演化
微服务与Docker介绍
Docker与CI持续集成/CD
互联网电商购物车架构演变案例
互联网业务场景下消息队列架构
互联网高效研发团队管理演进之一
消息系统架构设计演进
互联网电商搜索架构演化之一
企业信息化与软件工程的迷思
企业项目化管理介绍
软件项目成功之要素
人际沟通风格介绍一
精益IT组织与分享式领导
学习型组织与企业
企业创新文化与等级观念
组织目标与个人目标
初创公司人才招聘与管理
人才公司环境与企业文化
企业文化、团队文化与知识共享
高效能的团队建设
项目管理沟通计划
构建高效的研发与自动化运维
某大型电商云平台实践
互联网数据库架构设计思路
IT基础架构规划方案一(网络系统规划)
餐饮行业解决方案之客户分析流程
餐饮行业解决方案之采购战略制定与实施流程
餐饮行业解决方案之业务设计流程
供应链需求调研CheckList
企业应用之性能实时度量系统演变 如有想了解更多软件设计与架构, 系统IT,企业信息化, 团队管理 资讯，请关注我的微信订阅号：
作者：Petter Liu
出处：http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。 该文章也同时发布在我的独立博客中-Petter Liu Blog。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！ |
