必须理解的三大软件原则(3):YAGNI

原文地址：http://net.tutsplus.com/tutorials/tools-and-tips/3-key-software-principles-you-must-understand/

原则3：你不需要它(You Ain’t Gonna Need It)

Google+发布时，Facebook的创始人Mark Zuckerberg是第一批在这个社交网络中注册账号的人之一，而这个社交网络的目标就是将他打倒。他在“关于我”的章节只写了一句话“我在构建一些事物”。我真诚的认为这是一个聪明的总结，因为他用很少简单的词语描述出Coding的真谛。你为什么要成为程序员？热衷技术方案？追寻效率之美？不管答案是什么，但肯定不是“用标准函数创建第1000001个企业网站”。然而大多数人都是用它来挣钱的。不管在哪里工作，你都会不时的面对烦人且重复的任务。

原则“你不需要它（YAGNI）”就是用来处理这些任务的。基本的翻译就是：如果概念上没有提到，那代码中也不能出现。举个例子来讲，将数据库访问抽象在一层是惯例，他们处理不同驱动间的差异，像MySQL, PostgreSQL and Oracle。如果你正工作于一个发布在共享主机的企业网站上，那他们改变数据库的几率有多大呢？请记住概念是用预算记下来的。

如果数据库抽象没有预算，也就不会有数据库抽象。如果像改变数据库这种不太可能的事情真的发生了，那理所当然得为此变化买单。

你可能已经注意到了YAGNI与DRY驱动的模块化架构之间的不同：后者将项目切分成可控的组件来降低复杂度，而前者是通过减少组件个数来降低复杂度。YAGNI很像KISS原则，因为它也是致力于构建简单的方案。然而，KISS是通过尽可能容易的完成某件事情来实现精简方案；但YAGNI是通过根本就不实现它来达到精简。

Theodore Sturgeon,一名美国的科幻作家，阐明了一条法则：90%的一切都是废话。这是一个非常激进的想法，在现实世界的项目中没有多大用处。但请记住“废话”是很耗时的。一个很好的经验法则：软件项目中，大概80%的时间在做20%的功能。想想你自己的项目吧！每次我都会惊讶于这个机其精确的80：20规则。

如果你在一个因紧迫的期限和不精确的概念而臭名昭著的公司里，这将是一个强大的策略。你并不会因为实现了数据库抽象层而受到奖励。可能你的老大甚至都不知道什么是数据库抽象层。

正如这个概念听起来太简单，很难区分必须与非必须。例如，如果你对一个使用数据库抽象的类库或者框架很满意，你将会为其倾注大量的时间。主要的概念是以另一种方式看待软件：我们是被培训成书写可维护的且经的起时间考验的软件的。这意味着我们得培养自己的超前思想。未来将发生什么？这是大型项目的关键。但是面对小规模项目的开销问题时，不要想的太远（不知道这样翻译对不对）。如果一个小规模的企业网站确实发生了根本改变，他们可能不得不从头开始。这与全部的预算比起来不算什么重大问题。

项目计划

当你在为一个项目准备必做清单时，请考虑以下想法：

 

•  减少抽象层级以期较低水平的复杂度
• 将功能与特色区分开
• 适度假设非功能性的需求
• 找出耗时任务并且处理好

 

让我们稍微深入了解一些细节。对于清单中的第一个条目我已准备好了例子：在数据库抽象层不要隐藏数据库驱动。对任何可能增加你软件复杂度的事物都要持怀疑态度。请注意，抽象往往是由第三方类库提供的。比如，这取决于你的编程语言，一个持久层，像Java的Hiernate，PHP的Doctrine或者Ruby的Active Record等等都带有数据库抽象和对象关系映射。每个类库都增加了复杂度。我们必须要维护它。更新、补丁和安全修复是必须要做的。

       我们每天都在实现特性，因为我们期望他们是有用的。因此，我们想的比较超前，同时做的也很多。例如，很多客户想要一个手机站点。手机是一个被广泛接受的词汇，并不是设计决策。它只是一个用例！当然了，那些访问手机站点的人们手机。这就意味着，相对于那些悠闲自在的在桌面上访问站点的人们，他们可能想要获得其他信息或者功能。想一下影院网站：公共汽车上的人们可能更希望获取即将发布电影的上映日期，而不是50MB的预告片。

有了一笔适当的预算，你就可以为手机的需求完成一个专门的分析。如果没有这个分析，你会很简单的只提供一些和桌面站点一样的信息。很多情况下，这将是很不错的！因为手机浏览器足以聪明到可以自己调整桌面站点到他们的显示屏上，一个激进的YAGNI方法可能根本就不会写个手机站点。

非功能性的需求并不会描述软件行为，他们只会描述一些可以用来判别软件质量的附加属性。因为描述软件品质意味着软件知识，所以劣质的概念经常会被标记为缺少功能性需求。可维护性、文档化程度以及易集成度都是非功能性需求。非功能性需求是应该是可度量的。因此，如果说“这个页面应该加载的快些”，那就显得太不具体了，但要是这样说的话“在测试平均性能时，这个页面最多要在2秒内加载完毕”就显得非常具体且具度量性。如果你想应用YAGNI原则，请适度的假设些非功能性需求如果没有在概念中提到（或者他们被提到了，但没有被具体化）。如果是你自己在写非功能性需求，请从实际出发：一个日访问只有20-50个页面的小型公司不需要做出三天的性能调整——页面应该足够快因为服务器并不繁忙。如果公司可以增加日访问量，一台好的服务器或者托管方案不应该太贵。

最后，但并非不重要，请记住80：20的经验法则！我们必须认清耗时的部分。如果一个部分是完全必要的，那你必须实现它。问题是：你如何实现它？它必须是一个小范围内的最新框架吗？如果文档没有按时更新时你需要转换为（使用）仅仅是可以发布的类库吗？当并不是所有的CMS扩展都可用时，你应该使用新的CMS吗？这样做的话必须要投入多少调研呢？“这就是我们一直以来的做事方式”不是一个令人兴奋的做事方式，但这可以不带惊喜的完成工作。

但这并不是说你就可以开始编写漏洞百出的不洁代码了，认识到这一点很重要。你在编写一个轻量级的，而不是乱七八糟的应用程序。不管怎样，YAGNI是一个实用的方法。如果你为了减少一些代码重复而要改动很多代码，那我个人认为你或许可以在预算上下点功夫，有一些非DRY的代码也是OK的。因为它是一个小的应用，所以增加的维护复杂度是可以接受的。毕竟我们始终是生活在现实中的。

让我们回到最初的论题：我们喜欢构建事物。当Beethoven谱写Diabelli Variations时，这是合同工。我不认为他妥协于预算。他付出了更多的努力，因为他不想写出一首普普通通的乐曲；他想创作出一首完美的曲子。

我当然不是暗指我们全都是天才，每一行代码都熠熠闪耀着我们的聪明才智，但我喜欢像谱曲一样来构思软件架构。我是一名充满激情的开发者，因为我想构建完美的曲子，同时也想能对我自己构思的事物引以自傲。

如果你想成为一名经验丰富且久经业务考验的开发者，那你必须熟练掌握YAGNI原则。如果你想保持你的激情，你必须一直战斗着。

总结

软件原则是一种看待软件的方式。对于我而言，一个好的原则应该基于简单的概念，但当它在面对其他技术或者哲学时应该逐步发展成为一个复杂的思想体系。你最喜欢的软件原则是什么？