及时偿还技术债务

一 点睛

互联网业务变化很快，一方面是随着产品特性不断增多，多团队同时开发导致代码量逐渐增大，系统架构也越来越复杂。时间长了，会导致代码风格不统一，代码中引入了一些不合理的地方。另一方面，系统架构经过长期的发展，系统间调用的约束可能被打破，随着系统越来越复杂，很少有人能够了解整个系统的调用顺序。这时需要定期梳理，及时调整重复的架构模块和不合理的调用关系。

随着产品运营的变化，有些产品的方向也要进行修改和调整，导致从前正确的代码和架构变成了技术债务，需要进行清理或重新整理。

对于架构师的要求是：及时发现产品中不合理的地方和代码中的“坏味道”，有信心和勇气对系统进行重构，让系统永远“轻装上阵”。

“冰冻三尺，非一日之寒”，系统的代码质量不是一下子变得不好，而是有一个缓慢的过程，不做一些代码优化工作，短时期内系统也能正常运行，但对系统的长期维护是有影响的。而且每次新增功能和开发的隐形成本是很难测量的，也是引入事故的隐患。

采用“运动式”的清理来说不是最好的方案——这样会导致一次性修改的成本较大，而且发布变更比较多，同时很难一直保持如此高强度的优化。

常见的污染代码和运营环境的因素如下。

1 产品表现

• 已经废弃的功能还能通过隐藏接口使用。

• 为用户提供的默认选项不是最优的。

• 产品文案过时，与功能冲突。

2 代码

• 单文件、单函数代码过长，难以理解。

• 文档和代码脱节，没有借鉴意义。

• 废弃的代码注释后还保存在代码之中。

• 引入多种日志库，并且同时使用。

• 一些针对特殊业务逻辑硬编码的临时代码，时间长了没人知道是什么意思。

3 架构

• 系统间的调用从层级变成网状

• 多种功能的接口并存，本应下架的模块还在提供服务。

• 把本来没有依赖或启动顺序的模块变得互相耦合有依赖。

有些开发人员可能会想，这个业务不是我写的，只是维护，还是不要改了——这种想法是不对的。我们开始维护一个项目，就要对这个项目负责。从接手这个项目后，对比接手前在稳定性和性能方面的提升，就是我们维护这个项目所做的贡献。

有些开发人员有“洁癖”，看不得代码有一点“污染”，特别是针对别人写的代码，一切都要推倒重来，进行彻底的重构。彻底重构需要时间，一般互联网产品的需求和开发的时间都很紧迫，很难有专门的时间进行重构。从前的代码虽然不规范，但经过了验证。如果直接重构，则开发和测试的工作量较大，出现问题的概率也大大增加。

二 定期重构

重构可以针对代码架构，也可以针对代码段、函数等。随着技术的发展、机型的变化，系统的架构和代码也需要定期重构。重构能够缩减代码的复杂度，让代码更简单，更容易扩展。

为什么要定期重构？

1 代码风格

随着项目的时间越来越长，修改越来越多。这时要定期重构代码，保证风格一致，去掉风格不合适的代码。

2 系统逻辑复杂

定期重构能够减少技术债务，让系统越来越“清爽”，系统后期发展会更好。

3 用户增多

随着系统发展，用户量逐渐增大，对资源的需求也逐步变大。从前不需要优化的地方，现在可能稍加优化，就能节省很多机器资源。

4 长期演化产生很多互相调用关系

很多软件在最初发布时架构都是简单的，随着功能不断叠加，增加的模块越来越多，模块间的调用关系错综复杂，最后仅靠一名开发人员是梳理不出调用关系的。在众多调用关系中，肯定有破坏了原始架构层级的地方。这时就需要架构师定期评审，发现问题。

三 及时清理

系统经过多次修改和需求升级后，有些代码已经出现了问题。如果不及时清理，则容易形成“破窗”，越往后越不敢修改这些代码。

有些代码需要删除，但有的开发人员舍不得删，只注释掉，在需要时候打开注释就可以恢复代码。这种做法会增加代码的行数，让看代码的人分散注意力。当发现过期代码时，直接删除就可以了。

架构师发现代码中了有“坏味道”，就要及时制止。在修改需求的同时，也要把代码进行重构。

四 对技术有追求

开发人员对自己写的程序要有一种工匠精神。

工程师在发现“不干净”的地方要及时清理。

平时要多关注业内动态， 学习新技术，定期重构一些由于技术水平导致的设计缺陷。