"目标错误"比"遗漏需求"更糟糕

软件企业要控制成本、实现盈利，需要同时做对两件事：一要重视质量——这是”做正确的事”，质量差的软件维护成本一定高，这一点几乎没有企业会反对；二要重视对质量——这是”正确地做事”，即便重视质量这个大方向没错，如果引入了错误的质量目标，结果不会是”锦上添花”，反而会给后续设计凭添障碍。这个区分之所以关键，是因为架构设计本质上是”分”与”合”的艺术——决定怎么切分、怎么协作，是架构设计里最核心、影响最深远的决策。一旦架构基于错误的质量目标完成了切分和协作方式的设计，这套结构就会反过来阻碍其他真正需要的设计被引入，甚至这个”切分和协作”方式本身就会危及真正需要的质量目标——换句话说，错误的架构决策不是”中性的、可以后续纠正的浪费”，而是会主动排斥、压制正确方案的负资产。这就是为什么”每向错误目标迈进一步，就可能离正确目标远一步”：遗漏一项需求，通常还能在后续迭代中补上；但如果架构的根基（切分和协作方式）就建立在错误的关键需求判断上，纠正的代价往往是推倒重来，而不是局部修补。这条原理直接推出了一条实践准则：架构设计时”确定关键需求”这一步必须一次做对，因为它的纠错成本和其他环节完全不在一个量级上。