近期团队内部举行了几次代码评审，初衷是想通过代码评审，发现潜在问题，减少上线后影响用户体验。与此同时，交流编程技巧，拓宽编程思路，提升整体的编码能力。

整个代码评审采用由易入难，先总体再具体的思路，主要流程如下。

首先要讲述分享的代码，在系统架构中的位置。具体功能、调用关系、交互流程。给大家一个整体印象。

• 系统架构：整体介绍系统功能，突出模块在系统架构中的位置，例如，接入层或者逻辑层 ，各层的功能差异较大。
• 模块功能：详细介绍模块的功能，讲解实现方法，突出实现关键点。
• 调用关系和交互流程： 介绍模块与其他模块间的调用关系，有利于分析出一切潜在风险，例如环形调用、流量控制、过载保护等问题。
• 代码实现：根据模块功能，设计类图的结构，介绍类与类之间的关系，辅助分析代码实现。

按照上面的流程串讲代码，基本都能理解模块的功能，并对一些关键点展开讨论。

赞同源码编译，主要观点如下。

• 统一编译环境，有利于快速上手，开发效率高。
• 方便定位问题，有全部源码，异常问题可以跟踪到全部堆栈信息。
• 有利于多方协作，所有组件源码开放，沟通成本更低。

赞同静态库依赖编译，主要观点如下。

• 第三方组件代码量大，现阶段基本都是单机开发，源码编译速度慢，影响开发效率。
• cmake自带的编译加速不够完善，会带来异常问题。例如，新增文件，需要重新生成依赖关系，容易踩坑。
• 部分组件涉及到其他团队核心技术，不愿意提供源码。
• 公司内依赖的组件有专业团队维护，盲目修改代码，可能会带来不可预期的问题。

在串讲中发现，凡是运营多年的模块，经过不断的迭代，代码逻辑越来越混乱，历史代码阻碍了项目的推进。仔细想来，产生这种现象的原因如下。

•  对于功能需求，缺乏需求评估，引入大量不合理需求。
• 上线时间紧，开发周期短，开发前缺乏逻辑实现分析，实现中没有采用最优方案，引入大量额外代码，增加复杂度。
• 模块在传承的过程中，部分功能缺乏相关文档，新同学不理解特性，在开发过程中，只做加法，引入大量分支语句，导致逻辑复杂。
• 开发者不知道什么是优秀代码，缺乏学习目标，只会根据历史代码的痕迹，结果只会越来越差。
• 接手的同学也意识到，代码逻辑很混乱，缺乏历史特性的理解，不敢重构。

​

效率与完美，难以兼顾。源码编译一切尽在掌握中，很完美。却带来了编译耗时的增长，效率的降低。静态库依赖，看似带来效率的提升，排查异常时，却带来沟通成本。如果我们从收益的角度来考虑，同时提供源码编译和静态库依赖这两种方式，模块上线时用源码编译。本地调试采用静态库依赖，这样做可以达到收益最大化。思考问题，最怕陷入极端，却忽视了其它收益最佳的方案。

风物长宜放眼量，注重长期得失。铁打的营盘，流水的兵，公司的代码是需要不断传承的，代码可读性是第一要义。在开发的过程中，对代码进行适时的重构，短期来看会多花费部分时间，在重构的过程中，理清楚代码逻辑，开发新功能更加的心入手，BUG更少。

阅读优秀开源代码，提升编程技巧。参与开源项目开发，向技术大拿学习，拓宽眼界，提升格局。维护代码，就要对代码负责。