YAGNI（You “Ain‘t Gonna Need It）---您“不需要”

编码与构建事物有关。

当Google+推出时，Facebook的创始人马克·扎克伯格（Mark Zuckerberg）是最早在社交网络上创建一个旨在取缔自己的账户的人之一。他只在“关于我”部分添加了一行：“我正在建造东西。”。老实说，我认为这是一个很棒的句子，因为它用几个简单的词描述了编码的本质。您为什么决定成为一名编码员？热衷于技术解决方案？效率之美？无论您的答案是什么，它都可能不是»用标准功能构建第1.000.001个公司网站«。但是，我们大多数人都是这样赚钱的。无论您在哪里工作，都可能时不时面临无聊且重复的任务。

花在软件项目上的时间的80％用于20％的功能。

“您将不需要它”原理（YAGNI）处理这些任务。它的基本含义是：如果不在概念中，则不在代码中。例如，一种常见的做法是在处理各种驱动程序（例如MySQL，PostgreSQL和Oracle）之间的差异的层中抽象数据库访问。如果您正在LAMP堆栈上托管的公司网站上，在共享主机上工作，那么他们将如何更改数据库？请记住，该概念是在考虑预算的情况下编写的。

如果没有用于数据库抽象的预算，那么就没有数据库抽象。如果确实发生了数据库更改的不太可能的事件，则对更改请求收取费用是很自然的事情。

您可能已经注意到YAGNI和DRY驱动的模块化体系结构之间的区别：'DRY'通过将项目划分为可管理的组件来降低复杂性，而'YAGNI'则通过减少组件数来降低复杂性。YAGNI类似于KISS原则，因为它努力寻求一种简单的解决方案。但是，KISS试图通过尽可能容易地实现某些东西来寻求一种简单的解决方案。YAGNI通过根本不实现简单性来追求简单性！

美国科幻作家西奥多·斯特金（Theodore Sturgeon）表示法律：“所有事物的百分之九十都是垃圾”。这是一种非常激进的方法，在实际项目中并不过分。但是请记住，“废话”可能非常耗时。一个好的经验法则是：在软件项目上花费的时间中大约80％花费在20％的功能上。考虑一下您自己的项目！每当我这样做时，我都会对80:20规则的准确性感到惊讶。

80％的软件项目时间投入了20％的功能。

如果您所在的公司因期限紧迫和概念不精确而臭名昭著，那么这是一个强大的策略。实现数据库抽象层将不会给您带来任何回报。您的老板很可能甚至都不知道数据库抽象层是什么。

虽然这个概念听起来很简单，但是很难将必要部分与不必要部分区分开。例如，如果您对使用数据库抽象的库或框架感到满意，则在转储它时不会节省太多时间。关键概念是看待软件的另一种方式：我们受过培训，可以编写面向未来和可维护的软件。这意味着我们已经训练好要思考。未来可能会发生什么变化？这对于较大的项目至关重要，而对于较小的项目则非常重要。不要想未来！如果小型公司网站进行了根本性的更改，则可能必须从头开始。与总预算相比，这不是一个重大问题。

规划项目
在准备项目的待办事项清单时，请考虑以下几点：

• 通过降低抽象级别来降低复杂性。
• 功能与功能分开。
• 假设有适度的非功能性要求。
• 确定费时的任务并摆脱它们。

让我们再详细一点！我已经为列表中的第一项提供了一个示例：不要在数据库抽象层周围包装数据库驱动程序。怀疑会增加软件堆栈复杂性的所有内容。注意，抽象通常是由第三方库提供的。例如，根据您的编程语言，诸如Hibernate（Java），Doctrine（PHP）或Active Record（Ruby）之类的持久层附带了数据库抽象和对象关系映射。每个库都会增加复杂性。必须对其进行维护。必须应用更新，补丁和安全修复程序。

我们每天都会实施功能，因为我们希望它们会有用。因此，我们超前考虑并实施过多。例如，许多客户希望拥有一个移动网站。移动是广泛理解的术语；这不是设计决定。这是一个用例！使用移动网站的人可以移动。这意味着他们可能希望访问其他信息或功能，而不是访问位于桌面上的用户。考虑一个电影院站点：公交车上的用户可能会希望访问即将上映的电影的开始时间，而不是50 MB的预告片。

错误的概念通常可以通过缺乏非功能性需求来识别。

有了适当的预算，您将对移动设备的需求进行专门的分析。如果没有这种分析，您将只提供与桌面站点相同的信息。在许多情况下都可以！由于移动浏览器非常聪明，可以将桌面网站调整为适合其显示的内容，因此，一种根本的YAGNI方法可能是根本不编写移动网站！

非功能性需求并未描述软件的行为，而是描述了可用于判断软件质量的其他属性。由于描述软件质量是假定有关软件的知识，因此通常可以通过缺乏非功能性需求来识别不良概念。可维护性，文档级别和易于集成是非功能需求的示例。非功能性需求应该是可测量的。因此，»该页面应该快速加载。«太具体了，»该页面应该在平均性能测试期间最多在两秒钟内加载。«是非常具体和可衡量的。如果要应用YAGNI原则，请在概念中未提及（或提及但不具体）适度的非功能性需求。如果您自己编写非功能性需求，请现实一些：每天访问20-50个页面的小型公司不需要进行三天的性能调整-因为页面应该加载得足够快，因为服务器不忙。如果公司可以增加每日访问的次数，那么更好的服务器或托管程序包应该不会太昂贵。

最后但并非最不重要的一点，请记住80:20的经验法则！

最后但并非最不重要的一点，请记住80:20的经验法则！我们必须确定耗时的部分。如果绝对需要零件，则必须实施它。问题应该是：您将如何实施？它必须是小型社区的最新框架吗？如果文档不是最新的，是否需要切换到库的最新版本？当并非所有扩展都可用时，您应该使用新的CMS吗？为此需要进行多少研究？“这就是我们一直做到的方式。”这不是一种令人兴奋的方法，但是它将毫无意外地完成工作。

重要的是要了解，所有这些并不意味着您可以一路上开始用黑客编写肮脏的代码！您正在编写一个轻量级的应用程序，而不是一个凌乱的应用程序！但是，您将不需要它是一种实用的方法。如果这将导致多行代码减少几行代码重复，那么我个人认为您可以将精力与预算相关联，并且可以进行一些不干燥。这是一个小应用程序。因此，增加的维护复杂性是可以接受的。我们在现实世界中。

让我们回到最初的想法：我们喜欢建造东西。贝多芬写《迪亚贝利变奏曲》时，是合同工作。我认为他在预算上没有妥协。他跑了更多的路，因为他不想写普通的音乐。他想写一个完美的构图。

我当然不是在暗示我们都是天才，我们的才华应该遍及每一行代码，但是我喜欢将软件体系结构视为组成部分。我是一个充满热情的开发人员，因为我想构建完美的构图，并且为自己正在构建的东西感到自豪。

如果您想成为一名经验丰富且符合业务要求的开发人员，则必须掌握“您将不需要它”的原则。如果您想保持激情，就必须时不时地与之抗争。

原文：https://code.tutsplus.com/tutorials/3-key-software-principles-you-must-understand–net-25161