本节书摘来自异步社区《重构与模式（修订版）》一书中的第1章1.3节设计不足，作者【美】Joshua Kerievsky，更多章节内容可以访问云栖社区“异步社区”公众号查看。
1.3 设计不足
重构与模式（修订版）
设计不足比过度设计要常见得多。所谓设计不足（under-engineering），是指所开发的软件设计不良。其产生原因有如下几种：
程序员没有时间，没有抽出时间，或者时间不允许进行重构；
程序员在何为好的软件设计方面知识不足；
程序员被要求在既有系统中快速地添加新功能；
程序员被迫同时进行太多项目。
随着时间的推移，设计不足的软件将变成昂贵、难以维护甚至无法维护的大麻烦。Brian Foote 和Joseph Yoder曾经创造了一种名为Big Ball of Mud（大泥球）的模式语言，他们是这样描述类似软件的。
数据结构的构造非常随意，甚至近乎不存在。任何东西都要与其他东西通信。所有重要的状态数据都可能是全局的。在状态信息被隔开的地方，需要通过错综复杂的后端通道杂乱地传递，以绕开系统的原有结构。
变量名和函数名信息量不足，甚至会起误导作用。函数可能使用大量全局变量以及定义模糊的冗长的参数列表。函数本身冗长、费解，完成多项毫无关联的任务。代码重复很多。控制流很难看清，难以找到来龙去脉。程序员的意图几乎无法理解。代码完全不可读，近乎难于破译的天书。代码中有许多经过多个维护者之手不断修修补补留下的明显印记，这些维护者几乎都没有理解自己的修补会造成怎样的后果。[Foote and Yoder, 661]
虽然你开发的系统也许不会这么恐怖，但是很可能也曾经有过设计不足的时候。我知道自己肯定这样干过。迅速使代码运行起来是压倒一切的要求，而这往往伴随着巨大的压力，使我们无法改进既有代码的设计。有些情况下，我们会有意地不对代码进行改进，因为我们知道（或者自认为知道）软件的生命期不会太长。而另一些时候，是别人迫使我们不对代码进行改进，因为好心的经理会这样说：“不出事的地方就不用改了，这样我们公司能够更有竞争力，更可能在市场竞争中取胜。”
长期的设计不足，会使软件开发节奏变成“快、慢、更慢”，可能造成这样的后果：
(1) 系统的1.0版很快就交付了，但是代码质量很差；
(2) 系统的2.0版也交付了，但质量低劣的代码使我们慢了下来；
(3) 在企图交付未来版本时，随着劣质代码的倍增，开发速度也越来越慢，最后人们对系统、程序员乃至使大家陷于这种境地的整个过程都失去了信心；
(4) 到了4.0版时或者之后，我们意识到这样肯定不行，开始考虑推倒重来。
这种事情在我们的行业里司空见惯。它的代价非常高昂，而且会极大地降低企业本应具备的竞争力。幸运的是，我们还有更光明的道路可走。
本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。
