许多开发者都曾遇过被要求减少设计的环节并“尽快把东西做出来”。Martin Fowler对这种做法表示质疑,并认为对于大多数项目来说,以设计质量为代价换取开发速度是不现实的。Martin 说道:
设计活动的确要花费时间和精力,但这是有回报的,因为设计使得将来程序的发展更为畅顺。忽略设计能使你在短期内节省时间,但这笔技术负债越积越多,最终会逐渐降低你的生产效率。为软件设计投注精力可以让你的项目更具生命力,让你的项目可以走得更快更长久。
这里所说的设计活动包括各种风格,从经典的预先设计(Up-Front Design)到自然出现设计(Emergent Design),都是在敏捷项目中常见的。
人们对好的设计的影响程度意见不一,而 Martin 更多次听到一种相当极端看法:
确实有数次让我印象深刻的看法是,即使降低开发速度,也要使设计上的成果让程序员们保持心情愉快。
牺牲设计上的投入来或换取开发速度在大多数项目中都行不通,这是因为系统很快就变得难以下手,在设计上节省的时间很快就由于生产效率的降低而得不偿失。
在削减任何设计投入之前,如果我们能找到正在开发的系统的设计投入和回报的边际曲线,当然结果会最好,但我们只能依靠经验和直觉来做到这一点,因为我们没办法测量软件开发的生产效率。
然而,在特定条件下,估算设计回报的边际需要经验,正如 Antti Tarvainen 所指出的,缺乏经验不光让软件开发的新手难以作出直觉判断——也使经理难以评估设计投入的经济价值:
我们的软件开发新手无法直觉判断设计的价值,因为他的概念模型还不够丰富……问题是,他不知道与没有设计直接去编写软件功能相比,设计到底有多大的价值。对设计的低估导致糟糕的代码质量,并陷入编码——修补错误的循环。高估设计的价值导致项目瘫痪在分析阶段(对于大型的预先设计)或者降低迭代速率(对于敏捷方法)。
Dennis E. Hamilton (又名 Orchid)将设计成熟前就武断结束设计环节归因于几个常见错误:
这解释了新手常犯的疏失:好高骛远。我已经揪住了猪尾巴,下一步该怎么做红烧肉?如果一开始能预见到结局,我就不会搞砸了,但谁说我一定会搞砸呢,对不对?让我在没有设计的野地里撒撒野,反正在这里我也没有起到什么作用。除了 Fowler 说的安全降落区域,肯定会有什么看不见的东西接住我,摔不死的。
这也解释了常见的管理疏失:没有深思熟虑就将泰山压顶的技术负债丢到一边,也从不想法去补救。管理层也许应该比软件工人们更加理解软件生命周期和风险管理,虽然他们没有技能(当然也不会蠢到)自己去完成这些工作。
Fowler 的文章以他对设计回报的边际所在的看法作结:
我认为它比大多数人想象的要低:通常是数周而非数月。但这仍然只是我的直觉判断。
如果这个观点是正确的,那么几乎所有软件系统都会为设计上的妥协付出代价。
评论