看到一篇文章写的挺有共鸣的，转载一下，文章中人月神话这本书也有看过。
原作者：云舒编程
链接：https://juejin.cn/post/7312724606605918249
来源：稀土掘金

一、前言

相信很多人有过接手别人的系统，也有将自己负责的系统交接给别人的经历。既有交接出去不用在费力治理维护技术债务的喜悦，也有接手对方系统面对一系列维护问题的愁容满面。

但是被人嫌弃的系统曾经也是「创建人」心中的白月光啊，是什么导致了「白月光」变成了「牛夫人」呢？是996，工期倒排、先上再优化，还是随时变动的需求？

让我们来复盘系统是怎么一步一步腐化的，让我们丢失了最初的兴趣，同时总结一些经验教训以及破局之策。

二、白月光到牛夫人的经历

一般当我们设计一个系统时，总是会抱着要把该项目打造为「干净整洁」的项目的想法，

但是随着时间的推移，最后总是不可避免的变成了这样：

2.1、从0到1

我们发现大多数人对于创建新项目总是会抱有极大的激情兴趣，会充分的考虑架构设计。但是对于接手的项目就会缺乏耐心。

这种心理在《人月神话》一书中被说为编程职业的乐趣：

“首先，这种快乐是一种创建事物的纯粹快乐。如同小孩在玩泥巴时 感到快乐一样，成年人喜欢创建事物，特别是自己进行设计 。我想这种 快乐是上帝创造世界的折射，一种呈现在每片独特的、崭新的树叶和雪 花上的喜悦。”

“第四，这种快乐是持续学习的快乐，它来自于这项工作的非重复特性。人们所面临的问题总有这样那样的不同，因而解决问题的人可以从 中学习新的事物，有时是实践上的，有时是理论上的，或者兼而有之。”

正是由于这样的心理，人们在面对新系统时，可以实践自身所学，主动思考如何避开曾经遇到的坑。满足了内心深处的对于创造渴望。当一个项目是从0到1开始设计的，并且前期是由少数「高手」成员主导开发的话，一般不会有债务体现。当然明面上没有债务，不代表没有埋下债务的种子。

2.2、抢占市场、快速迭代

系统投入市场得到验证后，如果顺利，短期会收获大量用户。伴随着用户指数增长的同时，各种产品需求也会随着而来。一般在这个阶段将会是「工期倒排、先上再优化，需求随时变动」的高发期。

同时由于需求的爆发，为了提高团队的交付率，在这个阶段会引入大量的“新人”。随着带来的就是新老思想的碰撞，新的同学不一定认同之前的架构设计。

在这个阶段，如果团队存在主心骨，可以“游说”多方势力，平衡技术产品、新老开发之间的矛盾，那么在这个阶段引入的债务将会还好。但是如果团队缺乏这样的角色，就会导致公说公有理婆说婆有理，最后的结果就是架构会朝着多个方向发展，一个项目里充斥着多种不同思路的设计。有些甚至是矛盾的。如果还有【又不是不能用】的想法出现，那将是灭顶之灾。

但是在这个阶段对于参与者又是幸福的，一份【有市场、有用户、有技术、有价值】的项目，无论是对未来的晋升还是跳槽都是极大的谈资。

2.3、维护治理

褪去了前期“曾经沧海难为水，除却巫山不是云”的热恋后，剩下的就是生活的柴米油盐。系统的最终结局也是“维护治理”。

在这个阶段，需求的数量将大大减少，但是由于前期的“快速建设”，一个小小的需求，我们可能需要耗费数周的时间去迭代。而且系统越来越复杂，迭代越来越困难。

同时每天需要花费大量的时间处理客诉、定位bug，精力被完全分散。系统的设计和技术慢慢的变得僵化。并且由于用户量巨大，每次改动都要承担很大的线上风险。这样的情况对于程序员的精力、体力都是一场内耗，并且如果领导的重心也不在此项目时，更会加重这种内耗。于是该系统就会显得“人老色衰”，曾经的「白月光」也就变成了「牛夫人」。

三、牛夫人不好吗？

3.1、缺乏成就感

《人月神话》中关于程序员职业的苦恼曾说过以下几点：

对于系统编程人员而言，对其他人的依赖是一件非常痛苦的事情。他依靠其他人的程序，而这些程序往往设计得并不合理、实现拙劣、发布不完整(没有源代码或测试用例)或者文档记录得很糟。所以，系统编程人员不得不花费时间去研究和修改，而它们在理想情况下本应该是可靠的、完整的。
下一个苦恼---概念性设计是有趣的，但寻找琐碎的bug却是一项重复性的活动。伴随着创造性活动的，往往是枯燥沉闷的时间和艰苦的 劳动。程序编制工作也不例外。

最后一个苦恼 ，有时也是一种无奈—当投入了大量辛苦的劳动 ，产品在即将完成或者终于完成的时候，却已显得陈旧过时。可能是同事或竞争对手已在追逐新的、更好的构思; 也许替代方案不仅仅是在构思 ，而且己经在安排了。

随着业务趋于稳定，能够发挥创造性的地方越来越少，剩下的更多是沉闷、枯燥的维护工作。并且公司的资源会更聚焦在新业务、新方向，旧系统获得的关注更少，自然而然就缺乏成就感。也就形成了【只见新人笑，不见旧人哭】

3.2、旧系统复杂、难以维护

《A Philosophy of Software Design》一书中对复杂性进行了如下定义：“Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system.”，即任何使得软件难于理解和修改的因素都是复杂性。

作者John 教授又分别从三个角度进行了解释复杂性的来源：

3.2.1、变更放大

复杂性的第一个征兆是，看似简单的变更需要在许多不同地方进行代码修改。对于复杂的系统来说，如果代码没有聚敛，那么一次小小的需求可能会导致多处修改。同时为了保证不出故障，需要对涉及的修改点、功能点进行完整的覆盖测试。这种隐藏在背后的工作量是巨大的。

3.2.2、认知负荷

复杂性的第二个症状是认知负荷，这是指开发人员需要多少知识才能完成一项任务。当一个系统经过多年的迭代开发，其复杂度将是指数级别的。并且会充斥这很多只有“当事人”才能理解的“离谱”功能。这就对维护者提出了极高的要求，需要掌握很多“冰山下”的知识才能做到手到擒来。而这对维护者的耐心、能力又是一次挑战。

3.2.3、未知的未知

未知的未知是指必须修改哪些代码才能完成任务，或者说开发人员必须获得哪些信息才能成功地执行任务。这一项也是John Ousterhout教授认为复杂性中最糟糕的一个表现形式。这句话看起来比较抽象，如果映射到我们日常的工作中就是“我也不知道为啥这么改就好了”、“在我这是好的呀”、“刚刚还能运行啊，不知道为啥现在突然不行了”。

这种情况就是我们不知道改动的这行代码是否能让程序正常运转，也不知道这行代码的改动是否又会引发新的问题。这时候我们发现，那些“上帝类”真的就只有上帝能拯救了。

我曾经维护一个老系统，源码是通过文件相互传递的，没有仓库，里面的框架是自己撸的轮子，没有任何说明文档。服务部署是先在本地编译成二进制文件，然后在上传到服务器启动。每次改动上线都是就是一次生死劫，幸好没过多久，这个系统就被放弃了。
四、为何变成了牛夫人

4.1、伪敏捷

“敏捷”已经成为了国内公司的银弹了。    需求不做市场分析、不考虑用户体验、不做设计分析、不考虑前因后果，美其名曰“敏捷”。    工期倒排、先上再说、明天能不能上、这个问题上了再优化，美其名曰“敏捷”。

我曾经参与过一个项目，最开始是给了三个月的时间完成产品规划+开发，但是项目立项后领导层迟迟无法达成统一，一直持续进行了两个月的讨论后，终于确定了产品模型，进入开发。到这里留给开发的时间还剩一个月，咬咬牙也能搞定。但是开发真正进场，上报了需要开发的周期后，上面觉得太慢了，要求3周搞定，过了一天还是觉得太慢，要求2周，最后变成了要求4天搞定。遇到这种情况能怎么办，只能加人，只能怎么快怎么来。

之前阿里程序员也开玩笑式的说出了类似的场景：“2月13号上午省领导问逍遥子全省的健康码今天上线行不行，逍遥子说可以。等消息传达到产研团队的时候已经是中午了，然后团队在下午写了第一行代码。”

4.2、人的认知局限

《人月神话》一书中提到了一种组建团队的方式「外科手术团队」：“十个人，其中七个专业人士在解决问题，而系统是一个人或者最多两个人思考的产物，因此客观上达到了概念的一致性。”    也就是团队只需要一个或者两个掌舵人，负责规划团队的方向和系统架构，其余人配合他完成任务。目前我所待过的团队也基本是按照这个模式组成的，领导会负责重要事情的决策和团队分歧时的拍板，其余人则相互配合完成目标任务。但是这样的模式也导致了一个问题：掌舵人的认知上限就决定了团队的上限，而这种认知上限天然就会导致系统架构设计存在局限性，而这种局限性又会随着“伪敏捷”放大。

4.3、人员流动

经历过这种离职交接、活水交接的打工人应该深有体会，很多项目一旦步入这个阶段，大多数负责人就会开始放飞自我，怎么快怎么来，只想快点结束这段工作，快速奔赴下一段旅程。    从人性的角度是很难评价这种情况的，毕竟打工人和老板天然就不是一个战线的，甚至可能是对立面的。而我们大多数人都不可能是圣人，从自身角度从发这种行为是无可厚非的。

五、如何保持白月光

这里想首先抛个结论，系统变腐化是不可避免的。就类似人一样，随着时间的流逝，也会从以前一个连续熬夜打游戏看小说第二天依旧生龙活虎的青年变为一个在工位坐半小时都腰酸背痛，快走几步都喘的中年人。而这都来源于生活的压力、家庭的压力、工作的压力。同样的，面对业务的压力、抢占市场的压力、盈利的压力，系统也不可避免会变成“中年人”。   就像人一样会使用护肤品、健身等手段延缓自己的衰老一样，我们也可以使用一些手段延缓系统“衰老”。    在网上，已经有无数的文章教怎么避免代码腐化了，例如“DDD领域驱动设计”、“业务建模”、“重构”等等。    今天我想从别的角度聊聊怎么延缓代码腐化。

5.1、避免通用

软件领域有个特点，那就是复用。程序员们总是在思考怎么样写一段到处通用的代码，以不变应万变。特别是当国内提出中台战略后，这种情况就如脱缰的野马一般，不可阻挡。要是你做的业务、架构不带上xx中台，赋能xx，你都觉得你低人一等。    但是其实我们大部分人做的都是业务系统，本身就是面向某块特定市场的、特定用户的。这就天然决定了其局限性。   很多时候你会发现你用了100%的力气，设计了一个80%你认为有用的通用中台，最后只有20%产生了作用，剩下60%要么再也没有动过，要么就是被后来参与者喷的体无完肤。   当然这里也不说，设计时就按照当前产品提出的需求设计就行，一点扩展的余地都不留，而是在「通用」与「业务需求」之间取一个平衡。而这种平衡就取决于经验了。如果你没有这方面经验，那你就去找产品要「抄袭」的是哪个产品，看看他们有哪些功能，可以预留这些功能的设计点。

5.2、Clean Code

说实话，国内的业务系统80%都没有到需要谈论架构设计的地步。能够做到以下几点已经赢麻了：

• 良好的代码注释和相关文档存档【重中之重】
• 避免过长参数
• 避免过长方法和类
• 少量的设计模式
• 清晰的命名
• 有效的Code Review【不是那种帮我CR下，对方1秒后回复你一个done】

5.3、学会拒绝

自从国内开始掀起敏捷开发的浪潮后，在项目管理方面就出现了一个莫名其妙的指标：每次迭代的需求数都有会有一个数值，而且还不能比上一次迭代的少。   这种情况出现的原因是需求提出者无法确定这个需求可以带来多大的收益，这个收益是否满足老板的要求。那么他只能一股脑上一堆，这样即使最后效果不及预期，也可以怪罪于用户不买账。不是他不努力。   在这种时候，就需要开发学会识别哪些是真需求，哪些是伪需求，对于伪需求要学会说不。当然说不，不是让你上来就是开喷，而是你可以提出更加合理的理由，甚至你可以提出其他需求代替伪需求。这一般需要你对这块业务有非常深入的研究，同时对系统有上帝视角。   基本上在每个公司的迭代周期都是有时间要求的，比如我们就是两周一迭代，如果需求是你可控的，那么你就有更多的时间和心思在维护系统上，延缓他的衰老。