编写只做一件事并把它做好的程序
我可以通过封装掌握“做一件事”部分，依赖注入，最少知识原则，以及你不会需要它< /a>;但我如何理解第二部分“做好”？
给出的一个例子是完整性的概念，在同一篇YAGNI文章中给出：
例如，在允许添加项目、删除项目或修改项目的功能中，完整性还可以用于推荐“重命名项目”。
然而，我发现这样的推理很容易被滥用到功能蔓延，从而违反“做一件事”部分。
因此，什么是看到某个功能的石蕊测试属于“做好它”类别（因此，将其包含到函数/类/程序中）或另一个“做一件事”类别（因此，排除它） ？
第一部分“做一件事”最好通过 UNIX 的 ls 命令来理解，作为反例，该命令包含过多数量的用于格式化输出的标志，这些标志应该完全委托给另一个外部程序。但我没有一个很好的例子来证明第二部分“做得好”。
有什么好的例子可以说明删除任何进一步的功能将使其无法“做好”？
I can grasp the part "do one thing" via encapsulation, Dependency Injection, Principle of Least Knowledge, and You Ain't Gonna Need It; but how do I understand the second part "do it well?"
An example given was the notion of completeness, given in the same YAGNI article:
for example, among features which allow adding items, deleting items, or modifying items, completeness could be used to also recommend "renaming items".
However, I found reasoning like that could easily be abused into feature creep, thus violating the "do one thing" part.
So, what is a litmus test for seeing rather a feature belongs to the "do it well" category (hence, include it into the function/class/program) or to the other "do one thing" category (hence, exclude it)?
The first part, "do one thing," is best understood via UNIX's ls command as a counterexample for its inclusion of excessive number of flags for formatting its output, which should have been completely delegated to another external program. But I don't have a good example to see the second part "do it well."
What is a good example where removing any further feature would make it not "do it well?"
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
我认为“做得好”与功能的实现质量一样重要，而不是一组功能的完整性（在您的示例中具有重命名，以及创建和删除）。
做得好体现在很多方面，一些思维方式：
响应“特殊”输入的行为。例如，计算一些整数的平均值：
如果数组有零个元素，这会做什么？如果项目总数超过 MAX_INT？
性能特征。随着数据量的增加，是否对行为给予了足够的关注？
依赖失败。如果我们的实现依赖于其他模块或基础设施，那么当这些模块或基础设施失败时会发生什么。示例：文件系统已满，数据库已关闭？
关于功能蔓延本身，我认为您在这里确定紧张局势是正确的。您可能会考虑一件事：您不需要实现每个功能，因为很明显可以轻松添加功能而无需完全重写。
I see "Do It Well" as being as much about quality of implementation of a function than about the completeness of a set functions (in your example having rename, as well as create and delete).
Do It Well manifests in many ways, some ways of thinking:
Behaviour in response to "special" inputs. Example, calculating the mean of some integers:
what does this do if the array has zero elements? If the items total more than MAX_INT?
Performance Characteristics. Has sufficient attention been given to behaviour as the data volumes increase?
Dependency Failures. If our implementation depends upon other modules or infrastructure what happens when these fail. Example: File System Full, Database Down?
Concerning feature creep itself, I think you're correct to indentify a tension here. One thing you might consider: you don't need to implment every feature providing that it's pretty obvious that a feature can be added easily without a complete rewrite.
此建议的全部目的是让您重视质量而不是数量。
一件事的概念是主观的并且取决于粒度。您是否会说，如果电子表格应用程序还可以打印，那么它就可以做不止一件事，或者这是一件事的一部分？
重点是，您应该确保任何功能以及应用程序本身，已完成，并且会在您忙于添加新功能之前取悦客户。
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.
我认为你的问题指出了特征蠕变的根本有机本质，在理解这种本质后，你将能够思考更大的问题。
把它想象成一个花园：如果你种了一件事并且种得很好，比如说一朵菊花，那么你仅仅只是种下种子就还不够。事实上，您需要确保土壤得到良好照料、该区域得到充分保护、季节合适等等。
随着您的菊花（您的一件事）的生长，它也会生长其他有竞争力的植物——一些需要被淘汰，另一些可能实际上补充了原来的某件事。事实上，在某些情况下，这些其他有机体可能对您的一个东西的生存至关重要。
就像YAGN的那些特征一样，需要保持一定的警惕来确定哪些杂草代表特征蠕变，哪些代表重要和互补的功能。
不管怎样，做得好仅仅意味着你的菊花是丰盛的、健康的、准时的。 :-)
I think your question points out the fundamentally organic nature of feature creep, and in understanding that nature, you will be empowered to meditate on the larger question.
Think of it like a garden: If you plant one thing and plant it well, say, a chrysanthemum, you aren't done at simply planting the seed. In fact you'll need to ensure that the soil is well tended, that the area is sufficiently protected, that the season is right, etc.
As your chrysanthemum (your one thing) grows, so too will other competitive plants - some that need to be weeded out and others that may actually compliment the original one thing. In fact, these other organisms may in some cases prove vital for the survival of your one thing.
Like those features that YAGN, a bit of vigilance is required to determine which weeds represent feature creep and which represent vital and complimentary functions.
Regardless, having done it well means simply that your chrysanthemum is hearty, healthy, and on-time. :-)
我想说，无法添加附件的电子邮件程序就是一个很好的例子。
I would say an email program without the ability to add attachments would be a good example.
这听起来像是一个奇怪的例子，但我想说 dropbox 是一个很好的例子，尽管很复杂。
它成功地击败了一系列类似的竞争应用程序，通过致力于简化和缺乏功能蔓延，正如你提到的，这将违反“做一件事”原则。该应用程序允许您将文档存储在您可以在任何地方访问的文件夹中，这就是它的限制。他们深入挖掘核心问题，并以在 90% 以上的情况下都能完美运行的方式解决了该问题。
很难为其制定一个严格而快速的规则，但我想说，满足大约 90% 的大多数用例并忽略“边缘需求”是遵守此规则的最佳方法。
我猜 90% 以上的 ls 用法都是没有参数的，或者可能是最流行的两三个。 “做好”原则应该关注大多数用户的需求，而不是像 ls 那样提供过多的选项来迎合高级用户或边缘情况。
这就是 dropbox 的成功之处，也是为什么它被广泛认为是良好应用程序设计的一个例子。
This may sound like an odd example, but I'd say dropbox is a good, albeit complex example.
Its managed to beat off a swathe of similar competing apps, through a dedication to simplification and a lack of feature creep tha,t as you mentioned, would violate the 'do one thing' principle. The ap lets you store documents in a folder that you can access anywhere, and that's about the limit of it. They drilled down to the core problem, and solved it in a way that works perfectly well in 90+% of cases.
Its hard to put a hard and fast rule to it, but I'd say that catering to around the 90% majority of use cases and ignoring 'fringe requirements' is the best way to stick to this rule.
I'd guess 90+% of ls use is with no arguments or maybe two or three of the most popular. The 'do it well' principle should focus on what the majority of users need, instead of catering for power users or fringe cases, as ls does with its plethora of options.
This is what dropbox does successfully and why it is pretty well agreed upon as an example of good application design.