架构的腐化是必然的

作者 | 曹春晖

来源 | 码农桃花源

架构的腐化是必然的，不以人的意志为转移。

我们先从一个故事开始，从前有一个公司，这个公司有一个部门，这个部门里有两个组。

两个组做的项目比较类似，都是策略类项目。

其中一个组做需求基本靠堆人，业务和 PM 的所有需求，能找到人，并且让这个人在各种场景，各种模块，各种分支里加 if else 就可以搞定，代码膨胀飞快。很快没人能说得清项目内的细节，但是公司业务涉及的策略又很多，需求做不过来，所以疯狂堆人，小组规模迅速膨胀到几十个人。大家都很忙碌，充实，每天都在加班，就是代码稍微有点看不懂，但这不重要。重要的是大家都很充实且周报饱满。小组 leader 也高升了，可谓皆大欢喜。

另一个小组做项目，老是喜欢做一些设计，接需求的时候总是边做边停，但是发展了一段时间以后，似乎剩下的工作就非常地简单而单薄，组员们写写配置，写写工作流。这都嫌麻烦又做了个前端，所以每天的工作变成了点点鼠标，再后来他们又觉得太麻烦。点鼠标的工作扔给业务去做。这些程序员就显得每天特别闲。很快变成老板的眼中钉，随便找个理由就把这个组拆掉去做更“核心”的业务了。

如果你在推崇田园敏捷的互联网公司工作（也许已经没有不是这样的公司了），可能每天都在经历着类似的故事。所谓太阳底下没有新鲜事，不幸的人都有着相同的不幸。

问题到底出在哪里呢？

互联网行业向国外学习，推崇敏捷开发，但实际上学习到的只不过是表面敏捷，只考虑交付敏捷，很多时候不考虑开发。所以他们看上去是敏捷开发，实际上可能连瀑布模型都不如。瀑布模型是什么样的？

瀑布模型需要做详细的需求调研，和长时间的设计规划，所以在互联网公司一日十年的发展速度下被人诟病。而现代的互联网公司又都是业务驱动，显著的特点是不管你看上去多么简单的软件，背后都有极其庞大而复杂的流程、策略系统。一个中型互联网公司的业务代码，单单流程可能就已经有几百万行。在持续演进过程中，业务本身又会持续变化。可能是策略变化，可能是流程变化，可能是领域变化，也可能是因为被竞争对手打得满地找牙需要自己主动做架构变化。瀑布模型这种需要长期做规划，并且规划以后没法变的工作方式确实不适合互联网公司。

悲剧的是，丢掉了瀑布模型，人们不只丢掉了流程，甚至把设计环节也完全丢掉了。大多数敏捷开发的流程图里也并没有把设计当回事，看看 Scrum 概念里，每个敏捷迭代周期的 planning 部分：

Scrum methodology advocates for a planning meeting at the start of the sprint, where team members figure out how many items they can commit to, and then create a sprint backlog – a list of the tasks to perform during the sprint.

为了体现出工作态度，工程师必然本能地避开重构工作，这些业务 task 才是能让我写周报加班晋升的好宝贝。多多益善，充分体现工作量。项目质量什么的，跟我有啥关系。

有时系统确实太复杂了，普通工程师搞不定了，也会有个装模作样的设计阶段，像瀑布模型那样的，专门拿一两个周来做。不过也只是架构师们聚在一起，设计一个看起来能跑的最初的 POC 架构，一旦软件进入开发阶段，架构师们可能就已经逃之夭夭去参加下一个复杂的项目设计了。

软件的后期迭代和进化架构师们往往是不参与的。业务的变化又不会少数人的意志为转移，随着变化，一定会有那些并不适合放进最初设计中的需求出现，这时候架构师远在天边。工程师们排期又紧，那就只能先临时用丑陋的方案把需求实现。在系统里留下技术债。

这种“不适合融入既有架构”的需求事件出现在什么时间点，谁也说不清楚。给每个项目都安排长期跟进的架构师，而项目又一直没出现大的变化，又会变成资源浪费。架构师日常的工作如果不是跟进某个项目，这个项目碰到问题的时候，需要再做设计评审，临时抱佛脚找架构师来 review，大多也是走马观花。

这还真是有点两难。

这种情况下，最合适的还是在团队内部培养合适的人选承担组内架构师的职责，负责一定的重构、设计和架构工作，但这个要求不见得总是可行。大家都是混口饭吃，不读书不学习不求上进的程序员何其多，一个几百人业务技术部门，可能真的遇到几个组都没有一个合格的架构师的情况。即使有能力，也可能没时间。一线工程师还是眼睁睁地看着系统一步步变成 shit。

回到开头的故事。以上帝视角来看，我们考虑的理想与非理想状况对于在故事中的角色们来说也并不公平。即使能有合理的流程，从外部招到公司的“架构师”很多也只不过只是工龄长罢了，言必谈 DDD，中台，战略，一到了落地环节提不出合理的见解和建议。也有挂着架构师的头衔，实际上却是个“管理专家”，在催进度上更在行。何况对于某些人来说，没有合理的架构，从结果上来说可能更好。这和互联网行业扭曲的价值观相匹配，大多数时候衡量身价是用一个人的 小弟数目*公司光环加成，用简单的算术就能算出来，可喜可贺。这样大家的奋斗目标都是怎么样招更多的小弟，系统做成什么样根本无所谓啦。

能碰到一个靠谱的架构师，对于一个一线工程师来说，很多时候也是奢望。对于那些中小公司的人来说，可能就是绝望。

怎么避开这种绝望？只能凭运气，从客观规律来讲，大公司也是从小公司中公司发展而来，在它发展的前期阶段，靠谱的架构师 90% 不会愿意加入，而公司真的做大了，可能你手边系统的架构问题已经被靠谱的架构师解决完了，至少短时间内不会遇到问题。如果你不是陪着公司长大，很难体验到优秀的架构能给自己的日常工作带来多大的收益。

所以这是一个无解的问题。对于一个工程师来说，平常还是要多多学习，一方面提高个人实力，能够承担更高级的工作职责，实力强大了也可以有更多选择。至于那些外来的和尚，一般情况下都是指望不上的。

PS. 开头的故事是我编的。