1 简介

“YAGNI”代表“你不会需要它”。它源自极限编程，“你不会需要它。”
YAGNI 是一种源自极限编程 （XP） 的软件开发原则，它指出程序员在必要时不应添加额外的功能它建议开发人员只实现当前需求所需的功能，而不是添加将来可能需要的任何其他功能。

这一原则基于这样一种想法，即添加不必要的功能会导致复杂性增加、开发时间延长以及潜在的更多错误。
它鼓励开发人员避免向系统添加特性或功能，直到明确需要它们。

它基于这样一个前提，即添加不必要的功能会导致复杂性增加、开发时间延长以及潜在的更多错误。
相反，开发人员应该专注于提供满足当前要求的最简单的解决方案。避免了功能蠕变，这意味着开发人员不会使用将来几乎不会使用的功能。

YAGNI原则与“KISS”原则（“保持简单，愚蠢”）密切相关，该原则提倡设计简单，避免不必要的复杂性。
这两个原则都鼓励开发人员专注于提供满足当前需求的最简单解决方案，而不是试图预测和满足潜在的未来需求。

它应该遵循以下原则

构建成本：
构建成本是创建功能或解决方案所花费的时间、精力和资源。它包括从规划和编码到测试的所有内容。如果你构建的东西被证明是不需要的，那么构建成本代表你在创建它时所做的投资。

延迟成本：
延迟成本是因未及时交付功能或解决方案而错失的机会或经济影响。如果您将时间花在不太重要的功能上，则可能会延迟更重要功能的实现。这种延迟可能导致错失获得收入或其他利益的机会。

携带成本：
携带成本是由于软件中的特定功能而导致的持续困难和额外工作。当一个功能增加复杂性时，它可能会使处理软件的其他部分变得更加困难，从而导致额外的时间和精力。这就像在试图前进时背负额外的重量。

修复成本：
修复成本，也称为技术债务，是与修复功能开发过程中做出的错误、错误或错误选择相关的持续成本。如果您构建了一些需要稍后调整的东西，那么解决这些问题会产生额外的时间和资源，类似于偿还债务。

2 为什么YAGNI重要

它有助于保持软件开发的专注和高效。通过仅实现必要的功能，开发人员可以避免在不必要的功能上浪费时间和资源。这可以缩短开发时间、降低复杂性和更易于维护的代码库。

	granularity 颗粒度 + banlance 平衡 = YAGNI

当使用该原则，这就像有一个实用的指南来保持你的工作专注和高效。

获取必要的需求 --> 在您的团队中讨论 --> 分析解决方案的简单计划 --> 拒绝不适合解决方案的工作 —>记录您的进度

分步解析

• 1. 获得必要的要求

您的项目需要的所有东西，并将它们分类为“必备品”和“可以等待”。这有助于您确切地知道要做什么。无论您是将其写在纸上还是在屏幕上打出来，拥有一份清单都能让您井井有条。

• 2. 与您的团队讨论

之后，是时候与您的团队交谈了。与他们分享您的计划和目标。这确保每个人都在同一页面上并了解需要做什么。这就像是队长，确保每个人都在玩同一个游戏。

• 3. 分析解决方案的简单计划

现在，在计划实际工作时，请保持简单。将你的大目标分解成更小的任务。这有助于您避免不知所措，并确保您专注于真正重要的事情。可以把它想象成为你的项目建立一个分步的路线图。

• 4. 如果不适合解决方案，请拒绝

有时，您的团队可能会提出新的想法或想要添加额外的内容。虽然这些想法可能很酷，但你必须准备好说“不”，除非这是一个微小的改进。说“不”可能很难，但它可以防止你偏离轨道和错过最后期限。

• 5. 记录你的进度

记录你所做的事情。这就像在比赛中保持得分一样。这有助于你了解你已经走了多远，以及你是否朝着正确的方向前进。帮助您管理此流程的工具就像开发人员的记分牌，帮助他们保持正轨并交付客户真正需要的东西。

2 与其他原则对比

KISS（保持简单，愚蠢）：KISS是一个原则，倡导设计的简单性，避免不必要的复杂性。

YAGNI 通过建议不要添加不必要的功能来补充 KISS，这可能会导致复杂性增加。

DRY（Don’t Repeat Yourself）：DRY是倡导代码重用和避免重复的原则。DRY 专注于消除冗余代码，而 YAGNI 则专注于避免不必要的功能。

SOLID：SOLID 是一组面向对象设计的原则，可促进模块化、可维护和可扩展的代码。SOLID 原则侧重于代码的设计和架构，而 YAGNI 则侧重于代码的功能。

SOLID希望你对代码在未来可能如何变化有一个想法，即使一点点，

特别是单一责任原则（SRP）。这就像希望你能预测一些事情一样。

另一方面，YAGNI假设大多数时候，你不知道代码未来的发展方向。这就像未来太不可知，并且对我们的预测能力有点怀疑。

TDD（测试驱动开发）：TDD是一个开发过程，涉及在编写代码之前编写测试。TDD 专注于编写测试来推动开发过程，而 YAGNI 则专注于避免不必要的功能。

敏捷：敏捷是一套软件开发的原则和实践，强调协作、灵活性和客户反馈。YAGNI可以被看作是一个敏捷原则，因为它鼓励开发人员首先专注于提供最重要的功能，并适应不断变化的需求。

YAGNI的优点		其他原则如何解决它									YAGNI如何解决

简单			  如KISS（保持简单，愚蠢），也提倡设计的简单性，避免不必要的复杂性。	 YAGNI 通过建议不要添加不必要的功能来补充KISS

效率	        如敏捷和精益软件开发，强调为客户提供价值和消除浪费。                  YAGNI专注于提供满足当前需求的最简单的解决方案，
                                                                             从而加快开发周期并更有效地利用资源。

灵活性	   如敏捷和 Scrum，强调协作、灵活性和适应不断变化的需求。	          YAGNI鼓励开发人员首先专注于提供最重要的功能，并适应不断变化的需求。

降低风险	   如测试驱动开发 （TDD） 和持续集成 （CI），                    	YAGNI建议不要添加不必要的功能，
           侧重于交付满足当前要求的高质量代码。                             这可以降低在代码库中引入错误和其他问题的风险。

以用户为中心	 如敏捷和精益软件开发，专注于为客户提供价值。	         YAGNI有助于将重点放在首先提供最重要的功能上，
                                                                   这可以确保软件满足用户的需求和期望。

节省成本	   如敏捷和精益软件开发，侧重于消除浪费和为客户提供价值。	    YAGNI可以通过避免不必要的功能并专注于首先提供最重要的功能来节省成本。

可维护性	   如 SOLID（单一责任、开放/封闭、Liskov 替换、接口隔离、依赖关系反转），  YAGNI有助于保持代码库的简单和集中，使其更易于理解和维护。
        侧重于代码的设计和架构。	

• 如何应用YAGNI的一些示例：

避免了功能蠕变：开发团队正在开发 Web 应用程序。他们最初计划包括一项允许用户创建和共享自定义头像的功能。但是，在考虑了实现此功能所需的时间和资源后，他们决定推迟它，直到他们收到用户的反馈，表明这是必要的。

降低复杂性：开发人员正在开发一个移动应用程序，允许用户跟踪他们的锻炼程序。最初，他们计划包括一项功能，该功能可根据用户的健身目标自动生成个性化锻炼计划。但是，在考虑了实现此功能的复杂性以及对应用程序性能的潜在影响后，他们决定坚持使用一种更简单的方法，允许用户手动创建自己的锻炼计划。

资源分配：一个开发团队正在开发一个电子商务平台。他们最初计划包括一项功能，允许用户创建愿望清单并与朋友分享。然而，在考虑到项目可用的时间和资源有限后，他们决定专注于对平台成功更至关重要的其他功能。

范围管理：开发团队正在为客户开发软件项目。客户最初要求提供他们认为对项目成功所必需的几个附加功能。但是，在考虑了项目的预算和时间表后，开发团队决定将项目的范围限制为仅包含最关键的功能。

反馈驱动开发：一个开发团队正在开发一种新的软件产品。他们最初计划包括一项功能，允许用户提供有关产品性能的反馈。但是，在考虑了对产品可用性的潜在影响以及实现此功能所需的时间后，他们决定推迟它，直到他们收到用户的反馈，表明这是必要的。

• YAGNI的优势
  YAGNI（你不会需要它）在软件开发中的好处很多，可以对开发过程、最终产品的质量和项目的整体成功产生重大影响。以下是一些主要优势：

更快的开发：通过只关注当前需要的东西，开发人员可以避免将时间花在可能永远不会使用的功能上。这可以加快开发周期并更有效地利用资源。

简单性：不必要的功能会增加代码库的复杂性，使其更难维护和理解。YAGNI 有助于保持代码库的简单性和重点，使开发人员更容易使用。

灵活性：通过避免不必要的功能，开发人员可以保持代码库的灵活性和适应性。这在需求可能经常变化的快节奏环境中尤为重要。

降低风险：不必要的功能可能会将错误和其他问题引入代码库。通过避免这些功能，开发人员可以降低在代码库中引入错误和其他问题的风险。

以用户为中心：YAGNI有助于专注于为最终用户提供价值。通过仅实现用户所需的功能，开发人员可以确保软件满足用户的需求和期望。

节省成本：通过避免不必要的功能，开发人员可以节省原本用于实现和维护这些功能的时间和资源。这可以为组织节省成本。

改进的可维护性：更简单的代码库更易于理解和维护，使开发人员更容易进行更改和修复错误。

更好的用户体验：通过专注于首先提供最重要的功能，开发人员可以确保用户更快地获得所需的功能，从而获得更好的整体用户体验。

3 警示

YAGNI原则的核心警告：有时提前计划太久只会让项目变得更加困难。

在软件开发中，应该始终在试错和计划之间取得平衡。在第二类中摇摆不定的开发人员冒着过度设计项目的风险。
开发人员认为，他们现在通过为他们期望的客户请求创建功能来节省时间，但有时他们的期望是错误的。
这就是为什么敏捷强调与客户建立紧密而持续的反馈循环的重要性——否则，你最终可能会在一些永远不需要的事情上做大量的工作。

过度工程的真正危险在于它可能会影响当前的可交付成果。如果将未来的期望融入到代码库的不同部分，然后这些期望是错误的，那么开发人员必须返回并删除更改。
这种延迟可能会导致开发团队错过当前可交付成果的最后期限，并留下混乱的代码库。

YAGNI通过摒弃传统的、提前计划的软件开发方法来解决这些问题。它与增量设计的极端编程概念有关：一次构建一个元素，并在此过程中测试功能和业务价值。
如果客户需求或增长领域绝对需要特定的特性或功能，请构建它，并快速构建它。否则，请稍候

但是YAGNI定义很容易;实施起来更难。与杂乱无章的产品经理合作过的开发人员可能会担心未来的功能不会获得必要的后端支持。
根据生产力评估开发人员的团队也会发现程序员渴望在产品路线图上提前工作。

“你应该知道你的团队什么时候在做这件事，因为你会听到这样的话，'当我们打开引擎盖时'，此时的前提是有引擎和它的盖子。

果然发生了这样的事，当开发人员到达需要新字段的路线图功能时，实际调用和需求发生了变化，他们不得不返回并再次进行这项工作。

工程师通常作为问题的最终解决者，他们很难对需求说不。
但是，根据当下的需求确定工作的优先级——一次只处理一件事——是比试图同时处理多项任务更好的方法