从入职到架构师,我们在逐级台阶慢慢往上爬,入职——团队——抽象——复用——架构——标准化,现在我们又迈上了一个新的台阶:模块化和抽象层。
学习软件编程时,老师会告诉我们软件模块接口要清晰,要追求低耦合强内聚,这样,整个程序才能具备易扩展易维护的特点。
可惜理想很丰满,现实很骨感。在真实产品中,我们会发现软件模块初期还能相对清晰,但几次迭代下来,模块之间就会冒出很多相互调用,用不了多久,模块化就名存实亡了。
此时,经常会出现一种现象:我们增加或修改一些功能时,需要修改多处代码,即使小心翼翼,也容易犯错。我早期工作经历,就经常会面对刚发布的程序就被反馈一堆问题的尴尬。这种情况进一步恶化,会导致某些产品只能由特定老人维护。新人上不了手,老人脱不开身,是这种困局最生动的写照。
为何会出现这种现象呢?思考其背后的原因,我认为最主要的原因有两点:
- 程序本身有强耦合特性,如果不持续通过外力纠偏,随着需求增加,会自动长成一团。
- 真实工作中,任务往往是紧急的,需要快速解决。此时,程序员喜欢使用hack大法,怎么快怎么来,或者怎样容易怎么来。但hack大法很多情况下是不充分的,程序在修修补补中就凌乱了。
如何克服这两点呢,我们团队多年迭代出两条关键的策略:
- 持续积累模块化技巧。手里有粮,心中不慌,大画家随意的几根线条都是精品,同理,胸中有丰富的模块化策略,就自然的不乐意使用hack大法了。
- 将模块接口作为审核标的物,