架构腐化一词我已经忘了从哪本书上看到的了，但是这个词给我留下了非常深刻的印象。关键在于“腐”一词，充分而又形象的描述了架构是怎样一步一步从简单清爽走向复杂污秽的。请允许我用“污秽”一词来描述一个糟糕的架构，因为糟糕的架构就像是一潭散发着臭味的淤泥，让你不想靠近，一旦涉入其中就会难以自拔，苦不堪言。

我相信所有的开发者都不希望自己的参与项目是一潭淤泥，但是为什么会出现这么多糟糕的架构呢？难道是项目最初的设计者经验不够，又或者项目开发周期太赶？我认识事实并非如此。现在，软件开发者的水平都普遍提高了，因为我们有前人那么多经验可以借鉴，连刚毕业的大学生也知道用MVC模式来搭建框架。难道是MVC模式太挫了，不够用，实际上80%的项目用MVC模式足以应对。那到底是什么原因导致了项目腐化呢？我认为有以下三个原因：

1. 不理解项目的业务价值

实际上，几乎所有的软件（尤其是商业软件）都有其所属的业务价值，理解你所开发的软件的业务价值对项目的成功来说至关重要。我发现很多程序员对业务需求不屑一顾，而对那些所谓的非功能性需求盲目的崇拜和追捧，其实这是一种本末倒置的行为。

现实世界是一个商业的世界，而商业世界则会充斥着各种各样的业务逻辑。理解这些业务逻辑会极大地增加你的见识、拓宽你的视野。如果你是一个在金融行业工作的程序员，那么长时间在金融领域工作的精力将极大地提高你的市场竞争力。但是如果你不愿意花时间去学习金融领域的知识，而是去盲目的追求最新的技术，那么其实你是丢芝麻捡西瓜，浪费了这个行业带个你的附加价值。我不是不鼓励程序员瞎折腾，实际上我自己有时候也喜欢瞎折腾，倒腾一些新玩意，这视乎是程序员的一种天性。我的意思是说不要放弃了解自己所在行业/领域的知识视为不见，而盲目的追求其他的“高大上”的技术。

为什么说理解项目的业务价值至关重要呢，那是因为只有理解了其业务价值你才能识别出来这个项目的核心领域所在，这样这个项目才不会走偏。传统的软件开放流程中有一个非常重要的角色存在，叫做“业务分析员”，他的工作在项目的概要设计和详细设计解决十分重要。虽然我也没见过有专职的人员干这个，但是这却是非常重要的一个角色。他会帮你分析你的业务，和产品经理沟通，理解产品的真正意图。在这个沟通过程中，你的领域模型也就逐渐的清晰起来了，哪些是核心哪些是支撑部分也就清楚了。

有些程序员在接到产品需求后立马就开始工作了，吭哧吭哧地撸袖子上阵，我认为这是十分要不得的。接到产品需求的第一反应不是要想着我要建哪些表哪些字段，而是要多问问自己这个需求是干啥的，产品经理真正的意图是啥，为什么要我来做，跟我的系统有啥关系。千万不要盲从产品经理的话，实际上有些时候他们自己也不知道自己要干啥，为啥要这么干。这个时候必要的交流是不可少的，随着对话的深入，你和产品对真是的需求都会有着更深地认识。新人和实习生在这方面经验往往不足，此时最好找一个比较资深的程序员帮你梳理一下业务流程。

相反，如果你不知道你的系统的业务价值或者核心所在，什么需求你都来着不拒，那么恭喜你，你的系统正在腐化。当你在抱怨说“为什么这个业务要放在我这里”，“这个我有什么关系”之类的话的时候就可以闻到一丝“腐化”的闻到。你可能会说项目工期紧、人手太少、需求太多之内的外部原因，所以临时地先加到系统中搞一下。Ok，这没有任何问题。但是我还是要说，你知道你的系统的核心价值所在吗？如果你的回答是Yes，那么恭喜你，你是一名合格的程序员了。否则，你可能需要学习一下技术之外的东西的了－那就是沟通。

2. 过度设计

软件开发的头号敌人就是复杂度。现在软件开发是如此的困难，动不动就有十几万行代码出现，但是现实世界就是如此的复杂，不会因为你采用某种架构或者奇淫巧技就能把代码行数降下来。好的架构设计会将系统的复杂度控制在一个合理的范围之内，因为人所能驾驭的代码行数最多也就几十万行，如果一个系统的代码行数达到百万行，那么这个系统就很危险了。现在微服务架构如此火爆，不得不说有这方面的原因。

如果你在设计一个新系统，那么我需要提醒你一定要控制好复杂度。一个好的系统的核心域往往是简单的、直观的，其他人很快就能理解其核心的工作原理。如果一开始系统设计的十分复杂，那么这个系统的扩展性就会很差，后续的维护将不可想象。但是是不是在设计之初就完全不考虑后续的变化了呢？我的建议是你只需要把你的核心领域模型建好，多问问自己系统最核心的价值是提供什么服务的，照着这个方向去设计，那么你的系统就不会走偏。灵活性和可扩展型往往只是领域模型的延伸，这是一个水到渠成的过程。

非要给个度的话，我认为5%刚刚好。不要出现超过5%的跟你本次需求无关的概念和行为，而且这5%还是你能确定在不久的将来就会使用的扩展。

还是那句话，好的设计往往是简单的，复杂是万恶之源。

3. 懒于重构

过度设计不好，完全不设计也不行，尤其是随着敏捷开发的流行，持续交付优于提前设计的思想逐步流行。现在软件交付速度是如此之快，很有可能刚刚设计好的系统，下个月就全变样了。应对这种变化的唯一方法就是持续重构。

没有任何设计能预料到未来的变化，代码可能会发生变化。新的功能会持续的添加进来，老的功能也在持续的改变。而且每次迭代或者交付，都可能会对核心领域产生影响。千万不要对这种影响视而不见，因为它在改变着你的领域模型。正确地方式是经常调整领域模型以适应新功能所带来的变化，虽然每次调整的幅度可能很小，但是这却能让你的领域模型处于健康的工作状态。没有领域模型或者系统在一开始就是完美的，之所以它们能在后续的迭代过程中良好的工作离不开不断地重构。

重构不是等到你的系统无药可救的时候才想到的事，而是应该在其不断开发过程中一直进行的工作。如果说持续交付提高了你系统的竞争力，那么持续重构则是这种竞争力的有力保障！