程序员基操——如何应对需求变更的“范畴”和“形状”

前言

架构整洁之道读后感，随笔

原文引用有删减，虽然我认为原文每一个字都很有价值，值得推敲，但是考虑到自己程序员的身份，必须懒点，才能融入大家

喜欢交流的小伙伴私信加群

引用文字

为了达到软件的本来目的，软件系统必须够“软”——也就是说，软件应该容易被修改。当需求方改变需求的时候，随之所需的软件变更必须可以简单而方便地实现。变更实施的难度应该和变更的范畴成等比关系，而与变更的具体形状无关。

需求变更的范畴与形状，是决定对应软件变更实施成本高低的关键。这就是为什么有的代码变更的成本与其实现的功能改变不成比例。

从系统相关方的角度来看，他们所提出的一系列的变更需求的范畴都是类似的，因此成本也应该是固定的。但是从研发者角度来看，系统用户持续不断的变更需求就像是要求他们不停地用一堆不同形状的拼图块，拼成一个新的形状。整个拼图的过程越来越困难，因为现有系统的形状永远和需求的形状不一致。

问题的实际根源当然就是系统的架构设计。如果系统的架构设计偏向某种特定的形状，那么新的变更就会越来越难以实施。所以，好的系统架构设计应该尽可能做到与“形状”无关。

原文

原文如下：

感悟

这段文字我大概来来回回读了三五遍。

习惯了项目开发的程序员，抱怨最多的一句可能就是需求为什么总是不固定，来回变更，用户和产品经理都太不专业了。

殊不知，这是他架构设计的问题。

我们习惯了用解耦、分层等等词汇来掩盖我们贫瘠的思维，实际真正设计的时候，也不过是照猫画虎，真的问过自己这里为什么要解耦，那里为什么要分层吗。

业务和代码是没有办法完全割裂的，毕竟代码最终就是为了实现业务。但是代码里，究竟是百分百和业务关联，还是只有百分之一必须关联，是我们架构设计时必须要考虑的。

业务千变万化，我们控制不了和它相关联的代码大概率会有变动，但是我们可以控制，这部分代码尽可能控制在极小的范围内。而这极小的变动，又以一种极小的代价去适配新的“形状”变化，比如策略模式，比如“形状”的实现和“形状”的使用分离。

这里可以套用我曾经做过的比喻：程序员的工作就像是在做车轮，当不同的用户提出不同的需求，我们需要重新设计车轮的大小与品牌，这是“形状”的实现；但我们不需要重新设计车轮和汽车之间的螺丝，因为那是在架构设计之初就确定的输入与输出，这是“形状”的应用。