Martin Fowler 是 Thoughtworks 的著名作者和顾问,他在最近的一篇博客文章中描述了YAGNI 实践,分析了它的重要性以及创建“推定特性”(presumptive feature —— 意指某些已经完成编码,但并未投入实际应用的特性)所造成的成本。YAGNI 是“你不会需要它”(You Aren’t Gonna Need It)的缩写,它是一种极限编程(XP)实践,表示程序员不应为目前还不需要的功能编写代码。
XP 的联合创始人 Ron Jeffries 说道:
只在真正需要某些功能的时候才去实现它,而不是仅仅因为你预见到它将出现。
根据 Cunningham & Cunningham 的 wiki 页面所说:
即使你非常确信将来你需要某个特性,也不要现在就去实现它。在很多情况下,你会发现或许最终你不需要它了,或者是你真正所需的特性与你之前预计的有很大的出入。遵循 YAGNI 实践有两个主要原因:
- 你节约了时间,因为你避免了编写最终证明不必要的代码。
- 你的代码质量更高了,因为你使代码不必为你的“推测”所污染,而这些“推测”最终可能或多或少有些错误,但此时这些错误已牢牢地依附在你的代码中了。
Martin 说道,当我们在考虑推定特性时,很有可能我们是错的。在这种情况下,推定特性一个很明显的成本就是整个构建过程的成本,也就是对这个在当下没有用处的特性进行分析、编码以及测试所耗费的精力。他同时表示,假设我们对这个需求的理解恰好是正确的,但即使在这种比较理想的情况下,创建这个推定特性同样会带来两种巨大的成本。第一种成本是软件价值的延误成本,第二种成本是延续这一特性所带来的成本。他是这样解释这些成本的:
延误成本:团队本可以将精力投入到那些能够产生实际收益的特性上。
延续成本:为推定特性所编写的代码增加了软件的复杂性,这种复杂性使得对软件的修改与调试变得更加困难了,因而增加了其它特性的成本。这就为特性的开发造成了额外的成本,并且造成了进一步的延误成本,因为将它投入到生产环境的时间变得更长了。
Martin 还表示,如果特性是正确的,但对它的创建有错误,那么这还会导致额外的修复成本。
开发团队总是在不断地进行学习,一方面要学习他们的用户,一方面也要学习软件的代码。他们要对代码中使用的各种工具进行学习,而且这些工具会不断地更新。他们还需要学习这些代码是怎样配合工作的。以上这几点意味着,你很可能意识到:六个月之前所编写的某个特性并不是按照如今你所认识到的正确方式进行编写的。这样一来,你不仅积累了技术债,而且不得不考虑今后对其重写所带来的成本,或是出于困难而采用临时方案所带来的持续性成本。
Martin 说道,YAGNI 不仅适用于大型特性,同样也适用于较小的特性。将大量较小的 YAGNI 决策累积在一起,就能够使代码的复杂性得到很大程度的简化,同时又能够加速交付需求更紧急的特性。
查看英文原文: Martin Fowler on “Yagni: You Are Not Gonna Need IT” XP Practice
感谢张龙对本文的审校。
给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ , @丁晓昀),微信(微信号: InfoQChina )关注我们,并与我们的编辑和其他读者朋友交流(欢迎加入 InfoQ 读者交流群)。
评论