YAGNI原则，即"You Aren't Gonna Need It"（不需要它），是敏捷开发中的一个重要理念。它的核心思想是：在软件开发过程中，不应该实现那些当前并不需要的功能。因为很多时候，投入时间去开发的功能，最终可能并不会被用户使用。这不仅会浪费开发时间，还会增加软件维护的成本，因为软件的功能越多，维护起来就越复杂。
在看来，YAGNI原则是区分优秀开发者和杰出开发者的关键因素之一。一个杰出的开发者，不仅需要深刻理解YAGNI原则，更重要的是，他需要具备遵循这一原则的能力。没有什么比不写代码更能节省时间，也没有什么比遵循YAGNI原则更能提升开发效率。
YAGNI思考方式是一种需要培养和练习的技能，就像其他开发技能一样。在日常的开发工作中，开发者需要做出许多小决策。将YAGNI思考方式融入到这一过程中是非常重要的。
例如，可能会有这样的想法：“已经实现了一个为照片添加评论的功能，猜还需要实现一个为相册添加评论的功能。虽然现在不需要它，但相信未来如果允许用户评论他们的相册，就会需要它。”或者，“已经完成了Album类中的CanonizeName方法。认为最好将其提取到一个工具类中，因为未来其他类可能也需要它。”
这些例子都反映了一种超前思考的方式，这与YAGNI思考方式是相反的。可能已经注意到，在这两种情况下，都提到了“未来”。大多数情况下，当发现有人在做这样的陈述时，这是一个强烈的信号，表明他们没有遵循YAGNI原则。
作为软件开发者，擅长于泛化和超前思考。虽然这在日常工作中非常有帮助，但它也有一个缺点，那就是倾向于认为，提前做的一些工作，可以在将来节省更多的努力。然而，现实情况是，这几乎从未发生过。
这可能看起来有争议，但在实践中，为现在不需要的功能打下基础，而且可能在未来需要，几乎从来都不值得。最终只是在浪费时间。
每次即将做出决策时，问问自己：将要实现的方法/类/功能真的现在就需要吗？还是只是假设它在未来的某个时候会需要？如果第一个问题的答案是否，那么请确保放弃它。
这看起来可能很容易做到，但实际上通常并非如此。已经习惯了创建可重用的代码。即使不需要，也会这样做，以防万一。记得心理转变非常艰难。这需要重新评估当时的许多编码习惯。
最终，这是值得的。这种转变如何帮助提高整体生产力是惊人的。它不仅加快了开发速度，还允许保持代码库的简单性，从而使其更易于维护。
在某些情况下，超前思考可能会让陷入通常不想陷入的境地。想指出这些情况。
分析瘫痪。当想到一个新功能时，可能会很容易地被其开发所涉及的细节所压倒。当试图考虑到所做的决策的所有可能的未来影响时，情况会变得更糟。在极端情况下，它可能会完全瘫痪开发过程。
框架之上的框架。另一个极端情况是超前思考可能会让陷入构建自己的框架。几年前，加入了一个旨在自动化一些商业活动的项目。到那时为止，它已经拥有丰富的功能，允许用户配置他们需要的几乎所有流程。唯一的问题是，用户不想这样做。
该项目最终采用了单一的预定义配置，几乎从未改变过。每次有人需要更改流程时，他们都会要求开发者这样做。然后开发者更改配置并重新部署整个应用程序。
除了开发者自己之外，没有人使用这个全新的高度可配置的框架。该项目的实现带来了巨大的开销，只是为了实现程序员最初通过修改源代码就可以实现的功能。
在这种情况下，遵循YAGNI原则非常有帮助。此外，它通常对项目的成功至关重要。
YAGNI原则不仅适用于开发者。为了取得成功，将其应用于业务层面也很重要。这与构建正确的事情的概念密切相关：当专注于当前用户的需求，而不是试图预测他们未来可能想要什么时。
在所有层面上坚持YAGNI原则的项目更有可能成功。此外，在业务层面上遵循它最有利，因为它有助于节省大量的工作。
尽管业务决策通常被认为是软件开发者无法影响的领域，但情况并非总是如此。即使如此，也不要让它阻止尝试。
如果看到一个现在不需要的功能即将被实现，说出来。告诉业务人员他们最好不实现它。在这种对话中，通常使用两个主要论点：
不知道真正的需求是什么。如果现在实现这个功能，那么将来可能需要改变实现方式，从而浪费提前投入的努力。
添加功能总是会增加可维护性成本。每个功能都会增加实现所有后续功能所需的时间和努力，特别是如果该功能与其他现有功能交互（即，是交叉的）。在需要变得明显时再添加该功能，有助于加快其他功能的开
遵循YAGNI原则：自测试
遵循YAGNI原则吗？如果是，做得有多准确？这里有一个简单的测试可以帮助评估。不过，不要太认真。
假设需要创建一个计算2和3之和的函数。会如何实现它？向下滚动查看答案。
public int Sum(int x, int y) {
return x + y;
}
看到这里的问题了吗？这里有过早的泛化：实现了一个函数，它返回任意两个数字的和，而不是问题定义中要求的计算2和3的和。
public int SumTwoAndThree() {
return 2 + 3;
}
当然，这是一个玩具示例，但它展示了习惯于泛化的程度。
结论
没有什么比遵循YAGNI原则更能提高效率了。它有助于避免与过度工程相关的一系列问题。
虽然完全主张坚持它，但也有一些情况，这个原则并不完全适用。例如，如果开发一个第三方库，需要至少考虑当前用户的需求，因为未来的更改可能会破坏太多现有的代码。
除了这个例外，遵循YAGNI原则是软件开发中必须实践的。