为何必须靠拆分，而非只靠"写好代码"：强制约束出错范围

面对[[可扩展的基本思想是”拆”，及三种拆分思路的范围关系]]，一个常见的疑问是：如果代码写得足够规范，即使不拆分系统，同样能控制修改范围，那为什么还要大费周章去拆分？如果团队里每个程序员都是高手、对业务都很熟悉、新人也能很快摸透所有细节，那确实不拆分也不会出大问题——但这只是理想情况。现实中团队水平参差不齐：有的是新手，遇到需求不知道该改A处还是B处，全凭自己觉得哪里”看起来好改”就改哪里；有的程序员比较粗心；有的人某天状态不好；新来的同事根本不了解某段代码历史上为什么写得那么”丑”，就贸然把它”顺手改漂亮”，结果破坏了背后隐藏的约束……这些问题在真实团队里几乎必然会出现。合理的拆分之所以有价值，正是因为它能在这些不确定因素存在的前提下，强制把出错的范围限定在一个可控的边界内——即使某个程序员改错了，影响范围也不会无限扩散到整个系统，而是被架构本身的边界天然约束住了。这说明拆分的价值不是”假设团队完美时才需要”，而恰恰是”为了应对团队不完美这个现实”而存在的。