致敬《重构》：客户端重构场景分析

《重构：改善既有代码的设计》是计算机领域的一本经典之作，本书清晰揭示了重构的过程，解释了重构的原理和最佳实践方式，并给出了何时以及何地应该开始挖掘代码以求改善。

距离该书首次出版已经过去了二十余年，这二十多年里行业发生了很多变化，但有一件事的必要性并没有随着技术的进步，工具的升级，方法论的扩展而被消灭：

这就是重构本身。

因为在大部分工程师的职业经历中，能够从头开始搭建一个项目，并且在时间充裕、需求明确的条件下，用正常节奏设计开发完整系统的过程只是一个美好的理想——更多时候是在接手的现有系统/模块中如何平衡好代码质量和需求迭代

本文的重点不是为了说明重构的细节，而是从工程角度，在客户端场景下给提出一些关于重构的建议；如果大家关心重构方法论本身，直接去阅读《重构》就是最好的解答。

首先，为什么要强调客户端？客户端和其他场景有什么区别？

我们简单和后台研发模式做个对比：

• 一般意义上的后端研发都是基于 SOA 思想的，通常一个子系统 3 个人一起维护，就已经是很充分的人力了，更多时候是 1 个主力 + 1 个 backup 的人力配置；

• 而客户端则不同，一个公司战略级的 app，多则一个端 50+人，少则十来个人也是正常配备。

但客户端有个特征：

除非做了非常完善容器化，否则大家就得一起开发一些东西。

而即使做了容器化，很多状态的共享是不可回避的，比如：

• A 模块的 zombie，就足够造成 B/C/D 任何一个模块的 crash；

• A 模块的线程设计不合理很容易把接收回调的 B 模块变得不可靠。

这一点和基于 SOA 思路设计的后台服务中，一般故障都局限在某个服务内部的特点有非常大的不同, 所以：

客户端一个模块被写烂了，相比一个基于 MQ/RPC 相互连接的后台模块或子系统，会对整个项目造成更大危害。

（这里只是就代码形式而言——不是说后台就简单了，后端复杂的场景往往在别的方面，会有类似架构设计是否支持平行扩展，故障如何隔离，服务怎么降级等其他问题）

那么什么情况下必须立即重构，什么情况下可以推迟重构？

其实没有标准答案，但这就是造成问题的原因。

很多时候，研发会因为各种原因，推迟重构，直到这件事情被一拖再拖，从重要而不紧急的事情变成了既重要也紧急的事情

下面我会从之前的一些项目经验中给出一些建议，供大家参考。

重构的建议

要提前计划重构，不要赶时间

大部分重构都是代码债务的清偿的过程，赶时间容易积累新的债务。

• 紧急情况下做短期方案，但是必须比现在的状况更优

比如：费了很大劲才读懂了一个长函数，如果本期没时间优化，至少可以分解下这个大方法，写出更多命名准确的子方法，在函数体内部调用，提升可读性。

而对于一个突发的重构需求，其实已经错过了解决问题的最佳时机。

小步稳跑，尽可能保证肉眼可见的正确性

大多数时候，我们很难找到整块时间重构，这往往意味着你可能会相对分散地修改到正常需求开发不会触碰的逻辑，这种情形对于 QA 同学来说是非常容易发生误判的——即使和对方同步过，但双方仍然可能对问题的影响面判断不一致。

如果某些修改导致了用户可感知的 bug，那么这个时候往往容易因为面临各方压力，而停止重构过程。

什么叫 肉眼可见的正确性？ 概念很简单，就是一些相对可靠的推论而已，比如：我改了一个变量类型，只要我足够认真，同时确认过编译器所有警告——那么一个有经验的程序员是可以保证这个修改风险可控的

不同程度的工程师，能看出不同深度的问题，这一点需要执行重构的人，对自己的段位有客观的评价，不要贪图效率

如果我没有完全的把握确保这里的线程使用是正确的，此时应该通过认真自测 + 和 QA 同学详细同步影响面来确保安全，并且最好将自己怀疑会出问题的情形和对方指明。

多做系统性方案，考虑越周到越好

之所以会重构，有很大一部分原因是因为补丁方案已经快要 hold 不住了，这个时候再次使用小规模，单点方案，大概率会退化成另一种补丁

时间紧的情况下，想 100%，每次落地 x%, 保持方向正确，一步到位不了，两步，三步……

坚持做，代码会累积的你的努