前言

过去两年对电商平台的web端项目进行了2次重大重构

php-Laravel前后端混合开发项目架构改为前后端分离，后端php,前端vue框架单页面应用—解决前后端研发配合的高耦合度问题。
vue框架升级，利用vue-cli3构建SSR服务端渲染项目，Node服务框架Express—解决了SEO优化局限性问题，以及移动端首屏渲染性能问题。

以上两次重构都一定程度上提升了项目代码的可扩展性和可维护性，提升了研发团队的开发效率，提升了系统稳定性。
那接下来如果要对IOS APP做重构，我们先聊聊架构的演进的本质。

工程架构演进本质

快速的业务发展对技术支撑提出了更高的要求，为了保障敏捷的业务开发，提升跨团队的协同合作效率，提高本地研发和 CI/CD 效率，iOS App工程架构在不同的阶段需要进行不同的技术方案的改进，满足合理的架构演化，同时又不影响正常的业务迭代速度。

架构演进的本质是为了提高研发效率，提高代码稳定性和保证代码质量。架构要解决的问题是如何组织代码。

合理的架构设计可以解决大型项目跨团队协作分工和多业务线并行开发的效率问题。抖音工程代码从一开始就采用了组件化思路，依赖管理工具是定制版的 Cocoapods。

什么时候重构？很多时候，研发会因为各种原因，推迟重构，直到这件事情被一拖再拖，从重要而不紧急的事情变成了既重要也紧急的事情。重构需要提前计划，不要赶时间。大部分重构都是代码债务的偿清的过程，赶时间容易积累新的债务。而对于一个突发的重构需求，其实已经错过了解决问题的最佳时机。小步慢跑，尽可能保证肉眼可见的正确性。大多数时候，我们很难找到整块时间重构，这往往意味着你可能会相对分散地修改到正常需求开发不会触碰的逻辑，这种情形对于 QA 同学来说是非常容易发生误判的——即使和对方同步过，但双方仍然可能对问题的影响面判断不一致。

单兵收敛重点

有些复杂的事情必须要有单点管控，人越多越乱，因为很多重构必须要有全局观，才能抽象出比较符合项目实际情况的方案。
可能的场景：

组件化：接口打沉，代码规范
代码逻辑收敛：大量散装代码的封箱
不易切分的大块修改：复杂模块线程模型更新

这可能是重构里面最棘手情况了，解法需要看实际情况来决定，没有定式。所以需要把握节奏
重构往往影响比较大，需要综合考虑和 QA 同学的协作。

团队杠杆

在实际工作中，劣币逐良币是非常常见的：一旦烂代码成为普遍现象，写好的模块的成本就会变得非常高——这好比在浮沙筑高台。
这里涉及到两个关键问题：

治理已经比较乱的模块
保持重构的结果不滑坡

从治理的角度来说，一个足够有经验的研发，如果被给予充裕的处理时间，往往是能够比较好的完成任务的

但是这里仍然有几个关键因素可能会影响最终结果，按重要性：

人——这个人必须足够了解过去的需求，以及用来填坑的代码，需要确保重构完的代码必须能够等效达到之前的体验。
时间——如果要项目停下来等重构完成，是一个过于奢侈的要求。
务实——重构容易过于理想化，比如为了代码的整洁，某些回调会被提前或者压后，类似的场景还有网络请求等。

上面这些问题需要执行重构的人和使用方达成共识，才不会产生过于理想主义的问题；不过，这里没有标准答案，下面这条建议是很多即便很优秀的研发也容易弄反的东西。

如果模块内部设计优雅和模块外部使用简洁发生冲突的时候，优先保证模块外部使用简洁——对复杂度的封装既是模块本身存在的意义，也是代码治理的目的。