我可以通过封装、依赖注入、最少知识原则和你不需要它来掌握“做一件事”的部分；但是我如何理解第二部分“做好”？
给出的一个例子是完整性的概念，在同一篇 YAGNI 文章中给出：
例如，在允许添加项目、删除项目或修改项目的功能中，完整性也可用于推荐“重命名项目”。
但是，我发现这样的推理很容易被滥用到功能蠕变中，从而违反了“做一件事”部分。
那么，什么是查看某个功能属于“做得好”类别（因此，将其包含到函数/类/程序中）或其他“做一件事”类别（因此，排除它）的试金石?
第一部分“做一件事”最好通过 UNIX 的ls命令来理解，作为一个反例，因为它包含过多的标志来格式化其输出，这些标志应该完全委托给另一个外部程序。但是我没有一个很好的例子来看到第二部分“做得好”。
什么是一个很好的例子，删除任何进一步的功能会使其“做得不好”？
The whole purpose of this advice is to make you favor quality over quantity.
The concept of one thing is subjective and depends on granularity. Would you say that a spreadsheet application does more than one thing if it can also print, or is that part of that one thing?
The point is that you should make sure that any feature, and the application itself, is done and will delight customers before you scramble to add new features.
我认为“做得好”与函数实现的质量有关，而不是与一组函数的完整性有关（在您的示例中具有重命名以及创建和删除）。
做好事体现在很多方面，一些思维方式：
响应“特殊”输入的行为。例如，计算一些整数的平均值：
int mean(int[] values) { ... }
如果数组有零个元素，这会做什么？如果项目总计超过 MAX_INT？
性能特点。随着数据量的增加，是否对行为给予了足够的关注？
依赖失败。如果我们的实现依赖于其他模块或基础设施，那么当它们失败时会发生什么。示例：文件系统已满，数据库已关闭？
关于功能蠕变本身，我认为您在这里识别紧张是正确的。您可能会考虑一件事：您不需要实现每个功能，只要很明显无需完全重写即可轻松添加功能。
我认为您的问题指出了特征蠕变的基本有机性质，并且在理解这种性质时，您将有权思考更大的问题。
把它想象成一个花园：如果你种了一棵东西并且种得很好，比如菊花，你就不会仅仅种下种子。事实上，您需要确保土壤得到很好的照料，该地区得到充分保护，季节合适等等。
随着您的菊花（您的一物）的生长，其他具有竞争力的植物也会生长——一些需要被淘汰，而另一些可能实际上是对原来的一物的补充。事实上，这些其他生物在某些情况下可能证明对你的一件事的生存至关重要。
与YAGN的那些特征一样，需要一些警惕来确定哪些杂草代表特征蠕变，哪些代表重要和互补的功能。
无论如何，做得好仅仅意味着你的菊花是丰盛的，健康的，准时的。:-)
我想说一个不能添加附件的电子邮件程序就是一个很好的例子。
这听起来像是一个奇怪的例子，但我想说 Dropbox 是一个很好的例子，尽管它很复杂。
它通过致力于简化和缺乏功能蠕变，成功击败了一大堆类似的竞争应用程序，正如你提到的那样，这将违反“做一件事”的原则。该应用程序允许您将文档存储在您可以在任何地方访问的文件夹中，这就是它的限制。他们深入研究了核心问题，并以在 90+% 的情况下都能完美运行的方式解决了这个问题。
很难给它制定一个硬性规定，但我想说的是，满足大约 90% 的大多数用例并忽略“边缘要求”是坚持这条规则的最佳方式。
我猜 ls 使用的 90+% 没有参数，或者可能是最流行的两个或三个。“做好”的原则应该关注大多数用户的需求，而不是像 ls 的众多选项那样迎合高级用户或边缘情况。
这就是 Dropbox 的成功之处，也是为什么它被广泛认同为良好应用程序设计的一个例子的原因。