软件设计真的有回报吗？

许多开发者都曾遇过被要求减少设计的环节并“尽快把东西做出来”。Martin Fowler对这种做法表示质疑，并认为对于大多数项目来说，以设计质量为代价换取开发速度是不现实的。Martin说道：

\

设计活动的确要花费时间和精力，但这是有回报的，因为设计使得将来程序的发展更为畅顺。忽略设计能使你在短期内节省时间，但这笔技术负债越积越多，最终会逐渐降低你的生产效率。为软件设计投注精力可以让你的项目更具生命力，让你的项目可以走得更快更长久。

\

\

这里所说的设计活动包括各种风格，从经典的预先设计（Up-Front Design）到自然出现设计（Emergent Design），都是在敏捷项目中常见的。

\

人们对好的设计的影响程度意见不一，而Martin更多次听到一种相当极端看法：

\

\

确实有数次让我印象深刻的看法是，即使降低开发速度，也要使设计上的成果让程序员们保持心情愉快。

\

\

牺牲设计上的投入来或换取开发速度在大多数项目中都行不通，这是因为系统很快就变得难以下手，在设计上节省的时间很快就由于生产效率的降低而得不偿失。

\

在削减任何设计投入之前，如果我们能找到正在开发的系统的设计投入和回报的边际曲线，当然结果会最好，但我们只能依靠经验和直觉来做到这一点，因为我们没办法测量软件开发的生产效率。

\

然而，在特定条件下，估算设计回报的边际需要经验，正如Antti Tarvainen所指出的，缺乏经验不光让软件开发的新手难以作出直觉判断——也使经理难以评估设计投入的经济价值：

\

\

我们的软件开发新手无法直觉判断设计的价值，因为他的概念模型还不够丰富……问题是，他不知道与没有设计直接去编写软件功能相比，设计到底有多大的价值。对设计的低估导致糟糕的代码质量，并陷入编码——修补错误的循环。高估设计的价值导致项目瘫痪在分析阶段（对于大型的预先设计）或者降低迭代速率（对于敏捷方法）。

\

\

Dennis E. Hamilton（又名Orchid）将设计成熟前就武断结束设计环节归因于几个常见错误：

\

\

这解释了新手常犯的疏失：好高骛远。我已经揪住了猪尾巴，下一步该怎么做红烧肉？如果一开始能预见到结局，我就不会搞砸了，但谁说我一定会搞砸呢，对不对？让我在没有设计的野地里撒撒野，反正在这里我也没有起到什么作用。除了Fowler说的安全降落区域，肯定会有什么看不见的东西接住我，摔不死的。

\

这也解释了常见的管理疏失：没有深思熟虑就将泰山压顶的技术负债丢到一边，也从不想法去补救。管理层也许应该比软件工人们更加理解软件生命周期和风险管理，虽然他们没有技能（当然也不会蠢到）自己去完成这些工作。

\

\

Fowler的文章以他对设计回报的边际所在的看法作结：

\

\

我认为它比大多数人想象的要低：通常是数周而非数月。但这仍然只是我的直觉判断。

\

\

如果这个观点是正确的，那么几乎所有软件系统都会为设计上的妥协付出代价。