1 代码质量

优秀代码：可信赖、易维护、少Bug。具体来讲，完全满足产品需求；功能变更时只需要进行小的改动；异常时可优雅地报错或自我恢复；可优雅地处理未能提前预见的新场景；可防御安全攻击。

不优秀代码：不可信赖、难维护、多Bug。具体来讲，边界无法完全满足需求；功能变更时需要重写代码或需要较大规模重构；发生异常时系统进入未知状态、难于排查；面对新场景时系统进入未知状态、数据可能损坏；无法抵御安全攻击，面对安全攻击时系统可能被破坏，数据可能被泄露。

要使代码可维护性更高，需要有统一的编码规范（命名规范、代码格式、注释规范等）、稳定的工程结构（目录清晰、模块化、组件化、依赖可控、访问权限等）、优秀的方案实现（文档、用例、可测性、高内聚低耦合等）。

圈复杂度（Cyclomatic Complexity），一种软件度量手段，也称条件复杂度。计算方法：边数-节点数+2，或判定条件数+1。

2 代码评审

代码评审（Code Review, CR）的目标是前置发现代码问题。代码评审需要阅读源码、检查代码的规范性。

代码评审时，小Change List，即小的改动，是有好处的。这样审查更快，更容易合入代码。如果代码有问题，也容易再修改。对于审查者也更友好，因为对于审查者来说，不再需要大块时间，可以用更零碎的时间审查代码。

代码评审过程中会遇到不同的意见。需要谦逊坦诚地正视批评，对事不对人。收到意见后，应该修复代码本身，比如澄清代码、添加注释、修复问题。同时做自我反思，考虑意见。

重构是对软件内部的调整。目标：不改变软件可观察行为的前提下，提高可理解性。从而降低修改成本。

技术债是指本应采用最佳方案却妥协的做法。建议量化公开技术债，明确其影响和解决方案。每次迭代时也应确定一定数量的技术栈，作为目标消费掉。

重构方法：

重复代码->类型一般化，抽离公共代码

过多的函数参数->封装参数，通过函数调用获取参数

函数过长->提取方法，创建子函数

switch-case爆炸->策略模式，类型抽象

逻辑嵌套->提取方法，降低圈复杂度

长调用链->隐藏中间人调用

分支开发模式、Git Flow

持续集成（Continuous Integration, CI）：将代码频繁集成到代码仓库中，使bug更容易被发现、修正。

灰度发布：逐步向用户发布、扩大发布版本的使用用户群体。使用时可能要结合用户画像数据。

AB实验：排除干扰因素，通过AB实验对比，选择更优方案。

本节课主要介绍了研发人员应该具备的基本素养。在具体的某个深入钻研的方向之外，作为一名研发工程师，需要具备基本的工程师素养，以提升自己的代码质量、管理产品各版本、发挥更好的团队协作效益、增强产品的健壮性、减少线上事故。