我可以通过封装， dependency injection ， 最小知识原理， 而不需要它来掌握“做一件事”的部分; 但是我怎么理解第二部分“做得好？”
给出的一个例子是在YAGNI文章中给出的完整性概念：
例如，在允许添加项目，删除项目或修改项目的特征中，可以使用完整性来推荐“重命名项目”。
但是，我发现这样的推理很容易被滥用到function蠕变中，从而违反了“做一件事”的部分。
那么，什么是一个function属于“做得好”类别（因此，包括在function/类/程序中）或其他“做一件事”类别（因此排除它） ？
第一部分“做一件事”最好通过UNIX的ls命令来理解，因为它包含了过多的格式化输出的标志，应该已经完全委托给另一个外部程序。 但是我没有一个很好的例子来看看第二部分“做得好”。
什么是一个很好的例子，删除任何进一步的function将使它不“做好？”
我把“做得好”看作是关于一个函数的执行质量，而不是关于一组函数的完整性（在你的例子中有重命名，以及创建和删除）。
做得好，体现在很多方面，一些思维方式：
针对“特殊”输入的行为 。 例如，计算一些整数的平均值：
int mean(int[] values) { ... }
如果数组有零个元素，这是干什么的？ 如果项目总数超过MAX_INT？
性能特点 。 随着数据量的增加，对行为有足够的重视吗？
依赖性故障 。 如果我们的实现依赖于其他模块或基础架构，当这些失败时会发生什么 示例：文件系统已满，数据库关闭？
关于蠕变本身，我认为你在这里确定一个紧张是正确的。 有一件事你可能会考虑：你不需要暗示每一个特性，只要很容易地添加一个特性，而不需要完全的重写。
这个建议的全部目的是让你更青睐质量而不是数量。
一件事的概念是主观的，取决于粒度。 你会说电子表格应用程序能做多件事，如果它也能打印的话，还是属于那一件事的呢？
关键是你应该确保任何功能和应用程序本身都已经完成，并且在争先恐后添加新功能之前会取悦客户 。
我认为你的问题指出了蠕变的基本有机本质，并且在了解自然的时候，你将被授权冥想更大的问题。
想想它就像一个花园：如果你种植一件东西，栽种好，菊花，你不是简单地种植种子。 事实上，你需要确保土壤保持良好的状态，保持足够的土地，季节是正确的，等等。
随着你的菊花（你的一个 ）的增长，其他有竞争力的植物也会这样 – 一些需要被淘汰，另一些可能实际上是赞美原来的一个东西 。 事实上，在某些情况下，这些其他生物可能对您的一件事情的生存至关重要。
就像YAGN的那些功能一样 ，需要一些警惕来确定哪些杂草代表蠕变特征，哪些代表了重要的和免费的功能。
无论做得好，只要你的菊花是健康的，健康的，准时的。 🙂
我会说一个没有附加功能的电子邮件程序就是一个很好的例子。
这听起来可能是一个很奇怪的例子，但我认为dropbox是一个很好的例子。
它设法击败了类似的竞争应用程序，通过致力于简化和缺乏功能蠕变，如你所说，将违反“做一件事”的原则。 ap允许您将文档存储在您可以在任何地方访问的文件夹中，这是关于它的限制。 他们深入研究了核心问题，并以90％以上的案例很好地解决了这个问题。
它很难对它做出一个硬性规定，但是我认为，应对90％左右的用例，忽视“边缘要求”是坚持这一规则的最佳方式。
我猜测90％以上的ls使用是没有参数的，或者是两三个最流行的。 “做得好”的原则应该把重点放在大多数用户所需要的东西上，而不是像高级用户或边缘案例那样迎合他们的需求。
这就是Dropbox的成功之处，为什么它很好地被认为是一个很好的应用程序设计的例子。