架构的腐化是必然的 _架构

文章插图
作者 | 曹春晖
来源 | 码农桃花源
架构的腐化是必然的，不以人的意志为转移。
我们先从一个故事开始，从前有一个公司，这个公司有一个部门，这个部门里有两个组。
两个组做的项目比较类似，都是策略类项目。
其中一个组做需求基本靠堆人，业务和 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 。