要“软件工艺”还是要“足够用的设计”

InfoQ的一篇译文：http://www.infoq.com/cn/news/2010/05/sufficient-design

Joshua Kerievsky：要“软件工艺”还是要“足够用的设计”

作者 Mike Bria 译者 韩锴 发布于 2010年5月30日 下午7时42分
社区 架构 , Java, Ruby, .NET, 敏捷 主题 商业, 企业级敏捷 标签 精益, 设计准则
分享 |

在过去的一段时间里，“软件工艺”在不断地被热议。 针对软件工艺运动所强烈崇尚的“代码必须时刻保持干净”的信仰，Joshua Kerievsky提出了另一种可能从反方向审视的视角，他称之为“足够用的设计”。在此我们将探究Joshua的想法，并听一听Bob Martin和Ron Jeffries对此的评价。

Kerievsky首先讲述了他遇到的问题，然后表示会发表一系列关于“足够用的设计”的文章。

...有些程序员坚持软件的每一段代码的设计质量都应该尽可能地高。“不能生产干净的代码就称不上软件匠人”...

这个建议的初衷是好的。我们中的很多人都见过被沉重的技术债拖垮的项目。

然而，软件工匠的观点并没有考虑到一个简单的经济学：如果你花时间去雕琢那些对用户价值不高的代码，你就是在浪费时间和金钱。

事实上，有些代码并不需要非常卓越的设计，比如一些实验性的代码，或者不重要的特性。

Joshua接下来讲述了一个发生在他自己的开发团队中的故事：应用程序中的Action类的processWith方法按照基类的约定，应该返回字符串类型的值，但是其中一个Action不需要返回值，因此他们决定让Action直接返回null。这就带来了一个设计上的坏味道。这段有问题的代码就这样存在了很多年，期间还团队还尝试过重构代码将它移除，但没有成功，它依然存在。Joshua说，这段问题代码并有影响到他的团队。他非常肯定，这个问题并没有阻碍他的团队的开发进度，因此花时间去处理这个问题并不明智，还不如把时间用于开发更重要的特性上。这个故事的寓意是：

对于关键的部分，我们需要高质量的设计，反之，可以放低对质量的要求。

...

今天，软件设计质量的艺术是这样定义的，它取决于个人或者团队能否根据特性的重要程度来调整设计的表盘，从而创造人们喜爱又能赚钱的产品。

对于软件质量，没有放之四海皆准的方法。

如果你个“新特性瘾君子”，总是不断地增加新特性，而不对软件的设计多做些思考的话，那么在发布4.0版的时候就会被技术债拖垮了。

如果你是个“质量瘾君子”，那么就会对所有事情都过度设计。

当精益遇到工艺时，就有了“足够用的设计”。

最近一直引领着“软件工艺运动”的Bob大叔（Bob Martin）很快给出了回复，可能令所有人惊讶的是，他竟然也支持Joshua的结论：

在我看来，Josh的行为正说明他是一个十足的软件工匠。他担心过那些软件工匠们应该担心的事情。他也做出了软件工匠们应该做出的务实的决定。他没有在系统中尚残留着大量糟糕设计的时候，就急着去实现下一个特性。相反，他非常在乎他的代码。
Martin还继而澄清了他的立场，“软件工艺”传达的并不是“要么完美，要么完蛋”的二元选择，就像Joshua已经暗示的那样：

软件工匠们首先是实用主义者。他们对高质量代码的嗅觉非常灵敏；但是他们也不会为了追求完美而严重地牺牲经济利益。
Ron Jeffries也发表了类似的观点。他也一直在积极倡导保持编程成果清晰干净。Ron的文章可以浓缩为两句话：第一，设计债是“迟早都要还的”；第二，我们应该努力让自己的有能力干得又快又好：

如果你以牺牲质量换速度，那么从长期质量来看，欠下的债总是要还的。

从另一角度来看，如果那时我们自身比现在更优秀，就不必通过牺牲质量来换速度了。我们需要提高。但是不能一口吃成胖子：今天我们暂时通过牺牲质量来换取速度。但是应该在墙上写下：

如果牺牲质量能让我们更快一些的话，那么这就清楚地表明我们还有很大的空间有待提升，以更快的速度交付更好的软件。

不久之后，Kerievsky又发表了该系列的第二篇文章（正如他表示过的，会有很多），这一次他更加直率地表示，有时候“足够用”就意味着不必把某些事情做得足够好。他讲了另一个发生在Industrial Logic开发团队的故事，这次的主角是一个“巨型类”，它出现在实现“播放列表”功能的代码中。播放列表特性包含在eLearning的一次重要发布中：

经过不断地使用播放列表，并且对使用数据进行分析，一年以后我们知道：

我们的用户的确在使用播放列表。
还没有用户抱怨过播放列表。
用户并没有像极力称赞其他一些特性那样，称赞播放列表。
在销售的时候，当听到播放列表将来会针对一些特定的主题提供一个具有时效性的信息列表后，未来潜在的用户表现得很有兴趣。
那么，我们不要不花钱去解决播放列表中存在的设计问题呢？

不。

原因如下：

没有新行为：在过去的一年里，我们没有添加或者改变原来的播放列表的任何行为。
不用改变代码：在过去的一年里，我们只在UserLibrary（播放列表设计债的主要来源）中做了少量的修改，这些变化也不会影响到播放列表的功能。
问题被隔离了：尽管播放列表的设计很糟，但是它被隔离了，并没有渗入到过去一年中其它新特性的开发中。
播放列表只是取悦我们最大的客户的一份甜点而已。

这个特性确实有用，但是它并不属于产品开发的关键部件。

在播放列表中的代码坏味道，比如“巨型类”和“复杂的条件判断”，并没有让我们的开发慢下来。

我们管理质量的出发点是：

如果我们决定给用户一个更加完善的播放列表功能，那么在开始以前，我们会无怨无悔地偿清设计债的。

Joshua解释说，当未来的特性牵涉到播放列表时再来解决这些问题，他并不觉得很麻烦。这种信心从大的方面讲是由于他的团队的能力和严格遵守的TDD，另一方面也是因为他明白并接受这一点：有时候低质量也是可接受的，有时候表盘也要调节到高质量档。他总结道：

这一年来我们对播放列表的代码满意吗？

由于我们没有对它投入必要以外的时间和金钱，对此我们很满意。

我们乐于让设计变得更干净，但是要等到正确的时间。

这就是“足够用的设计”。

你怎样想？Joshua的建议能够被普遍接受吗？你用类似的方法在自己的项目中取得成功了吗？还是失败了？进一步的讨论还需要再考虑哪些因素？

查看英文原文：Joshua Kerievsky Introduces "Sufficient Design" To The Craftsmanship Discussion