架构为什么会腐化.docxVIP

架构为什么会腐化 2021-12-30 架构腐化一词我已经忘了从哪本书上看到的了，但是这个词给我留下了格外深刻的印象。关键在于“腐”一词，充分而又笼统的描述了架构是怎样一步一步从简约清新走向简单污秽的。请允许我用“污秽”一词来描述一个蹩脚的架构，由于蹩脚的架构就像是一潭分发着臭味的淤泥，让你不想靠近，一旦涉入其中就会难以自拔，苦不堪言。 我信任全部的开发者都不期望本人的参与项目是一潭淤泥，但是为什么会消灭这么多蹩脚的架构呢？莫非是项目最后的设计者阅历不够，又或者项目开发周期太赶？我生疏现实并非如此。现在，软件开发者的水平都普遍提高了，由于我们有前人那么多阅历可以自创，连刚毕业的高校生也晓得用MVC模式来搭建框架。莫非是MVC模式太挫了，不够用，实际上80%的项目用MVC模式足以应对。那到底是什么缘由导致了项目腐化呢？我认为有以下三个缘由： 1. 不理解项目的业务价值 实际上，几乎全部的软件（尤其是商业软件）都有其所属的业务价值，理解你所开发的软件的业务价值对项目的成功来说至关重要。我发觉很多程序员对业务需求不屑一顾，而对那些所谓的非功能性需求盲目的崇拜和追捧，其实这是一种本末倒置的行为。 现实世界是一个商业的世界，而商业世界则会充斥着各种各样的业务规律。理解这些业务规律会极大地添加你的见识、拓宽你的视野。假如你是一个在金融行业工作的程序员，那么长时间在金融领域工作的精力将极大地提高你的市场竞争力。但是假如你不情愿花时间去学习金融领域的学问，而是去盲目的追求最新的技术，那么其实你是丢芝麻捡西瓜，铺张了这个行业带个你的附加价值。我不是不鼓舞程序员瞎折腾，实际上我本人有时候也宠爱瞎折腾，倒腾一些新玩意，这视乎是程序员的一种天性。我的意思是说不要放弃了解本人所外行业/领域的学问视为不见，而盲目的追求其他的“高大上”的技术。 为什么说理解项目的业务价值至关重要呢，那是由于只要理解了其业务价值你才能识别出来这个项目的核心领域所在，这样这个项目才不会走偏。传统的软件开放流程中有一个格外重要的角色存在，叫做“业务分析员”，他的工作在项目的概要设计和具体设计处理格外重要。虽然我也没见过有专职的人员干这个，但是这却是格外重要的一个角色。他会帮你分析你的业务，和产品经理沟通，理解产品的真正意图。在这个沟通过程中，你的领域模型也就渐渐的清楚起来了，哪些是核心哪些是支撑部分也就清楚了。 有些程序员在接到产品需求后立马就开头工作了，吭哧吭哧地撸袖子上阵，我认为这是格外要不得的。接到产品需求的第一反应不是要想着我要建哪些表哪些字段，而是要多问问本人这个需求是干啥的，产品经理真正的意图是啥，为什么要我来做，跟我的系统有啥关系。千万不要盲从产品经理的话，实际上有些时候他们本人也不晓得本人要干啥，为啥要这么干。这个时候必要的沟通是不行少的，随着对话的深化，你和产品对真是的需求都会有着更深地生疏。新人和实习生在这方面阅历往往不足，此时最好找一个比较资深的程序员帮你梳理一下业务流程。 相反，假如你不晓得你的系统的业务价值或者核心所在，什么需求你都来着不拒，那么恭喜你，你的系统正在腐化。当你在埋怨说“为什么这个业务要放在我这里”，“这个我有什么关系”之类的话的时候就可以闻到一丝“腐化”的闻到。你可能会说项目工期紧、人手太少、需求太多之内的外部缘由，所以临时地先加到系统中搞一下。Ok，这没有任何问题。但是我还是要说，你晓得你的系统的核心价值所在吗？假如你的回答是Yes，那么恭喜你，你是一名合格的程序员了。否则，你可能需要学习一下技术之外的东西的了－那就是沟通。 2. 过度设计 软件开发的头号敌人就是简单度。现在软件开发是如此的困难，动不动就有十几万行代码消灭，但是现实世界就是如此的简单，不会由于你接受某种架构或者奇淫巧技就能把代码行数降下来。好的架构设计会将系统的简单度把握在一个合理的范围之内，由于人所能驾驭的代码行数最多也就几十万行，假如一个系统的代码行数达到百万行，那么这个系统就很危急了。现在微服务架构如此火爆，不得不说有这方面的缘由。 假如你在设计一个新系统，那么我需要提示你肯定要把握好简单度。一个好的系统的核心域往往是简约的、直观的，其他人很快就能理解其核心的工作原理。假如一开头系统设计的格外简单，那么这个系统的扩展性就会很差，后续的维护将不行想象。但是是不是在设计之初就完全不考虑后续的变化了呢？我的建议是你只需要把你的核心领域模型建好，多问问本人系统最核心的价值是供应什么服务的，照着这个方向去设计，那么你的系统就不会走偏。机警性和可扩展型往往只是领域模型的延长，这是一个水到渠成的过程。 非要给个度的话，我认为5%刚刚好。不要消灭超过5%的跟你本次需求无关的概念和行为，而且这5%还是你能确定在不久的将来就会使用的扩展。 还是那句话，好的设计往往是简