我可以通过封装，Dependency Injection，Principle of Least Knowledge和You Ain't Gonna Need It来掌握“做一件事”的部分;但我如何理解第二部分“做得好”？
给出的一个例子是完整性的概念，在同一YAGNI article中给出：
例如，在允许添加项目，删除项目或修改项目的功能中，完整性可用于建议“重命名项目”。
然而，我发现这样的推理很容易被滥用到特征蠕变中，从而违反了“做一件事”的部分。
那么，看到相当一个特征属于“做得好”类别（因此，将其包含在函数/类/程序中）或其他“做一件事”类别（因此，排除它）？
第一部分“做一件事”最好通过UNIX的ls命令来理解，因为它包含了过多数量的标志来格式化它的输出，这些标志应该完全委托给另一个外部程序。但我没有一个很好的例子来看第二部分“做得好”。
什么是一个很好的例子，删除任何进一步的功能会使它“做得不好？”
答案 0 :(得分：1)
这个建议的目的是让你赞成质量而不是数量。
一件事的概念是主观的，取决于粒度。您是否可以说电子表格应用程序如果还可以打印，或者是
重点是，在争夺添加新功能之前，您应该确保任何功能和应用程序本身完成并让客户满意。
答案 1 :(得分：1)
我认为你的问题指出了特征蠕变的根本有机性，在理解这种性质时，你将有权思考更大的问题。
把它想象成一个花园：如果你种植一种东西并种植它，比如说，菊花，你就不能简单地种植种子。事实上，你需要确保土壤得到良好的保护，该区域得到充分的保护，季节是正确的等等。
随着你的菊花（你的一件事）的增长，其他有竞争力的植物也会增长 - 有些需要被淘汰，有些可能实际上是在赞美原来的一件事。事实上，在某些情况下，这些其他生物可能对你的一件事的生存至关重要。
与 YAGN 的那些功能一样，需要一点警惕来确定哪些杂草代表特征蠕变，哪些代表重要和补充功能。
无论如何，做得好意味着你的菊花是丰盛的，健康的，准时的。 ： - ）
答案 2 :(得分：1)
我认为“做得好”与功能的实现质量相关，而不是设置功能的完整性（在你的例子中有重命名，以及创建和删除）。
做得好很好地体现了一些思维方式：
响应“特殊”输入的行为。例如，计算一些整数的平均值：
int mean(int[] values) { ... }
如果数组元素为零，这会怎么做？如果项目总数超过MAX_INT？
效果特征。随着数据量的增加，是否对行为给予了足够的重视？
依赖性失败。如果我们的实现依赖于其他模块或基础架构，当这些失败时会发生什示例：文件系统已满，数据库已关闭？
关于功能蠕变本身，我认为你在这里识别紧张是正确的。您可以考虑的一件事是：您不需要实现每个功能，只要很明显可以轻松添加功能而无需完全重写。
答案 3 :(得分：0)
我会说一个没有附加功能的电子邮件程序就是一个很好的例子。
答案 4 :(得分：0)
这可能听起来像一个奇怪的例子，但我会说Dropbox是一个很好的，虽然很复杂的例子。
它设法击败了大量类似的竞争应用程序，通过致力于简化和缺乏功能蠕变，如你所提到的那样，会违反“做一件事”的原则。 ap允许您将文档存储在您可以在任何地方访问的文件夹中，这是关于它的限制。他们深入研究了核心问题，并以90％以上的情况完美地解决了问题。
很难对它施加严格的规则，但我认为迎合90％的大多数用例并忽略“边缘要求”是坚持这一规则的最佳方式。
我认为90％以上的ls使用的是没有参数或者最流行的两三个。 “做得好”原则应该关注大多数用户需要的东西，而不是为高级用户或边缘案件提供服务，因为它有很多选择。
这就是Dropbox成功的原因，以及为什么它作为良好应用程序设计的一个例子得到了很好的认同。