5.1 模块化，知易行难

从入职到架构师，我们在逐级台阶慢慢往上爬，入职——团队——抽象——复用——架构——标准化，现在我们又迈上了一个新的台阶：模块化和抽象层。

学习软件编程时，老师会告诉我们软件模块接口要清晰，要追求低耦合强内聚，这样，整个程序才能具备易扩展易维护的特点。

可惜理想很丰满，现实很骨感。在真实产品中，我们会发现软件模块初期还能相对清晰，但几次迭代下来，模块之间就会冒出很多相互调用，用不了多久，模块化就名存实亡了。

此时，经常会出现一种现象：我们增加或修改一些功能时，需要修改多处代码，即使小心翼翼，也容易犯错。我早期工作经历，就经常会面对刚发布的程序就被反馈一堆问题的尴尬。这种情况进一步恶化，会导致某些产品只能由特定老人维护。新人上不了手，老人脱不开身，是这种困局最生动的写照。

为何会出现这种现象呢？思考其背后的原因，我认为最主要的原因有两点：

1. 程序本身有强耦合特性，如果不持续通过外力纠偏，随着需求增加，会自动长成一团。
2. 真实工作中，任务往往是紧急的，需要快速解决。此时，程序员喜欢使用hack大法，怎么快怎么来，或者怎样容易怎么来。但hack大法很多情况下是不充分的，程序在修修补补中就凌乱了。

如何克服这两点呢，我们团队多年迭代出两条关键的策略：

1. 持续积累模块化技巧。手里有粮，心中不慌，大画家随意的几根线条都是精品，同理，胸中有丰富的模块化策略，就自然的不乐意使用hack大法了。
2. 将模块接口作为审核标的物，