Contrary to most answers, I do not believe that "presently unneeded functionality" is over-engineering; or it is the least problematic form.
Like you said, the worst kind of over-engineering is usually committed in the name of future-proofing and extensibility - and achieves the exact opposite:
Empty layers of abstraction that are at best unnecessary and at worst restrict you to a narrow, inefficient use of the underlying API.
Code littered with designated "extension points" such as protected methods or components acquired via abstract factories - which all turn out to be not quite what you actually need when you do have to extend the functionality.
Making everything configurable to "avoid hard-coding", with the effect that there's more (complex, failure-prone) application logic in configuration files than in source code.
Over-genericizing: instead of implementing the (technically uninteresting) functional spec, the developer builds a (technically interesting) "business rule engine" that "executes" the specs themselves as supplied by business users. The net result is an interpreter for a proprietary (scripting or domain-specific) language that is usually horribly designed, has no tool support and is so hard to use that no business user could ever work with it.
The truth is that the design that is most easily adapted to new and changing requirements (and is thus the most future-proof and extensible) is the design that is as simple as possible.
In the cases where we've considered things over engineered, it's always been describing software that has been designed to be so generic that it loses sight of the main task that it was initially designed to perform, and has therefore become not only hard to use, but fundimentally unintelligent.
To me, over-engineering is including anything that you don't need and that you don't know you're going to need. If you catch yourself saying that a feature might be nice if the requirements change in a certain way, then you might be over-engineering. Basically, over-engineering is violating YAGNI.
If you spend so much time thinking about the possible ramifications of a problem that you end up interfering with the solving of the problem itself, you may be over-engineering.
There's a fine balance between "best engineering practices" and "real world applicability". At some point you have to decide that even though a particular solution may not be as "pure" from an engineering standpoint as it could be, it will do the job.
For example:
If you are designing a user management system for one-time use at a high school reunion, you probably don't need to add support for incredibly long names, or funky character sets. Setting a reasonable maximum length and doing some basic sanitizing should be sufficient. On the other hand, if you're creating a system that will be deployed for hundreds of similar events, you might want to spend some more time on the problem.
It's all about the appropriate level of effort for the task at hand.
I'm afraid that a precise definition is probably not possible as it's highly dependent on the context. For example, it's much easier to over-engineer a web site that displays glittering ponies than it is a nuclear power plant control system. Redundancies, excessive error checking, highly instrumented logging facilities are all over-engineering for a glittering ponies app, but not for a nuclear power plant control system. I think the best you can do is have a feeling about when you are applying too much overhead to your features for the purpose of the application.
Note that I would distinguish between gold-plating and over-engineering. In my mind, gold-plating is creating features that weren't asked for and will never be used. Over-engineering is more about how much "safety" you build into the application either by coding checks around the code or using excessive design for a simple task.
To me it is anything that would add any more fat to the code. Meat would be any code that will do the job according to the spec and fat would be any code that would bloat the code in a way that it just adds more complexity. The programmer might have been expecting a future expansion of the functionality; but still it is fat.!
Basically, you can sit down and spent too much time trying to make a perfect design, without ever writing some code to check out how it works. Any agile method will tell you not to do all your design up-front, and to just create chunks of design, implement it, reiterate over it, re-design, go again, etc...
Over-engeneering means architecting and designing the applcation with more components than it really should have according to the requirements list.
There is a big difference between over-engeneering and creating an extensible applcaiton, that can be upgraded as reqirements change. If I can think of an example i'll edit the post.
Over-engineering is simply creating a product with greater functionality, quality, generality, extensibility, documentation, or any other aspect than is required.
Of course, you may have requirements outside a specific project -- for example, if you forsee doing future similar applications, then you might have additional requirements for extendability, dependent on cost, that you add on to the project specific requirements.
Disclaimer #1: I am a big-picture BA. I know no code. I read this site all the time. This is my first post.
Funny I was just told by my boss that I over-engineered a new software produce we're planning for mentoring (target market HR people). So I came here to look up the term.
They want to get something in place to sell now, re-purposing existing tools. I can't help but sit back and think, fewer signups, lower retention, if it doesn't allow some of the flexibility we talked about. And mainly, have a highly visual UI that a monkey could use.
He said we could plan future phases to improve the product, especially the UI. We have current customers waiting on "future improvements" that we still aren't doing. They need it though, truly need it.
I am in the process of resigning so I didn't push back.
But my definition would be.............making sure it only does as little as possible, for as cheap as possible, and still be passable for the thing you say it is. Beyond that is over engineering.
Disclaimer #2: This site helped me land my next job implementing a more configurable software.
发布评论
评论（19）
与大多数答案相反，我不认为“目前不需要的功能”是过度设计； 或者它是问题最少的形式。
就像你说的，最糟糕的过度设计通常是以面向未来和可扩展性的名义进行的 - 并达到完全相反的效果：
事实是，最容易适应新的和不断变化的需求（因此最具前瞻性和可扩展性）的设计是尽可能简单的设计。
Contrary to most answers, I do not believe that "presently unneeded functionality" is over-engineering; or it is the least problematic form.
Like you said, the worst kind of over-engineering is usually committed in the name of future-proofing and extensibility - and achieves the exact opposite:
The truth is that the design that is most easily adapted to new and changing requirements (and is thus the most future-proof and extensible) is the design that is as simple as possible.
与普遍的看法相反，过度工程实际上是当工程师变得“傲慢”并认为他们理解用户时出现的一种现象。
我做了一个简单的图表来说明这一点：
Contrary to popular belief, over-engineering is really a phenomena that appears when engineers get "hubris" and think they understand the user.
I made a simple diagram to illustrate this:
在我们考虑过度设计的情况下，它总是描述被设计得如此通用的软件，以至于忽视了它最初设计要执行的主要任务，因此变得不仅难以使用，但本质上是不聪明的。
In the cases where we've considered things over engineered, it's always been describing software that has been designed to be so generic that it loses sight of the main task that it was initially designed to perform, and has therefore become not only hard to use, but fundimentally unintelligent.
对我来说，过度设计包括了你不需要的东西以及你不知道你会需要的东西。 如果你发现自己说如果需求以某种方式发生变化，某个功能可能会很好，那么你可能是过度设计了。 基本上，过度设计违反了 YAGNI。
To me, over-engineering is including anything that you don't need and that you don't know you're going to need. If you catch yourself saying that a feature might be nice if the requirements change in a certain way, then you might be over-engineering. Basically, over-engineering is violating YAGNI.
这个问题的敏捷答案是：每一段代码都对所请求的功能没有贡献。
The agile answer to this question is: every piece of code that does not contribute to the requested functionality.
Joel on Software 中有这样一个讨论，开头是：
并且，通过示例进行讨论。
There is this discussion at Joel on Software that starts with,
And, gets into a discussion with examples.
如果你花费太多时间思考问题可能产生的后果，最终却干扰了问题本身的解决，那么你可能是过度设计了。
“最佳工程实践”和“现实世界适用性”之间存在着良好的平衡。 在某些时候，您必须决定，即使从工程角度来看，特定的解决方案可能不那么“纯粹”，但它仍然可以完成工作。
例如：
如果您正在设计一个供高中同学聚会一次性使用的用户管理系统，您可能不需要添加对超长名称或时髦字符集的支持。 设置合理的最大长度并进行一些基本的清理就足够了。 另一方面，如果您正在创建一个将部署数百个类似事件的系统，您可能需要花更多时间来解决该问题。
这完全取决于手头任务的适当程度的努力。
If you spend so much time thinking about the possible ramifications of a problem that you end up interfering with the solving of the problem itself, you may be over-engineering.
There's a fine balance between "best engineering practices" and "real world applicability". At some point you have to decide that even though a particular solution may not be as "pure" from an engineering standpoint as it could be, it will do the job.
For example:
If you are designing a user management system for one-time use at a high school reunion, you probably don't need to add support for incredibly long names, or funky character sets. Setting a reasonable maximum length and doing some basic sanitizing should be sufficient. On the other hand, if you're creating a system that will be deployed for hundreds of similar events, you might want to spend some more time on the problem.
It's all about the appropriate level of effort for the task at hand.
恐怕不可能有一个精确的定义，因为它高度依赖于上下文。 例如，过度设计一个显示闪闪发光的小马的网站比设计一个核电站控制系统要容易得多。 冗余、过多的错误检查、高度仪器化的记录设施对于一个闪闪发光的小马应用程序来说都是过度设计的，但对于核电站控制系统来说却不是。 我认为您能做的最好的事情就是了解何时出于应用程序的目的对功能施加了过多的开销。
请注意，我会区分镀金和过度设计。 在我看来，镀金正在创造一些没有被要求也永远不会被使用的功能。 过度工程更多的是通过围绕代码进行编码检查或对简单任务使用过度设计来在应用程序中构建多少“安全性”。
I'm afraid that a precise definition is probably not possible as it's highly dependent on the context. For example, it's much easier to over-engineer a web site that displays glittering ponies than it is a nuclear power plant control system. Redundancies, excessive error checking, highly instrumented logging facilities are all over-engineering for a glittering ponies app, but not for a nuclear power plant control system. I think the best you can do is have a feeling about when you are applying too much overhead to your features for the purpose of the application.
Note that I would distinguish between gold-plating and over-engineering. In my mind, gold-plating is creating features that weren't asked for and will never be used. Over-engineering is more about how much "safety" you build into the application either by coding checks around the code or using excessive design for a simple task.
这与我有争议的编程观点有关“最简单的方法总是最好的方法”。
This relates to my controversial programming opinion of "The simplest approach is always the best approach".
引自此处：“......当你实际时实施事情需要它们，而不是当您预见需要它们时。”
Quoting from here: "...Implement things when you actually need them, never when you just foresee that you need them."
对我来说，它是任何会给代码增加更多脂肪的东西。 “肉”是指任何能够根据规范完成工作的代码，而“脂肪”则是任何会使代码变得臃肿、只会增加更多复杂性的代码。 程序员可能期待未来功能的扩展； 但还是很胖。！
To me it is anything that would add any more fat to the code. Meat would be any code that will do the job according to the spec and fat would be any code that would bloat the code in a way that it just adds more complexity. The programmer might have been expecting a future expansion of the functionality; but still it is fat.!
我的粗略定义是“提供满足需求规范不需要的功能”
My rough definition would be 'Providing functionality that isnt needed to meet the requirements spec'
我认为它们与镀金相同并被金锤 :)
基本上，你可以坐下来，花太多时间尝试做出完美的设计，而无需曾经编写过一些代码来检查它是如何工作的。 任何敏捷方法都会告诉您不要预先完成所有设计，而只需创建设计块、实施它、重申它、重新设计、再次进行等等......
I think they are the same as Gold plating and being hit by the Golden hammer :)
Basically, you can sit down and spent too much time trying to make a perfect design, without ever writing some code to check out how it works. Any agile method will tell you not to do all your design up-front, and to just create chunks of design, implement it, reiterate over it, re-design, go again, etc...
过度工程意味着使用比需求列表实际应有的组件更多的组件来构建和设计应用程序。
过度设计和创建可扩展的应用程序之间存在很大差异，可扩展的应用程序可以根据需求的变化进行升级。 如果我能想到一个例子，我会编辑这篇文章。
Over-engeneering means architecting and designing the applcation with more components than it really should have according to the requirements list.
There is a big difference between over-engeneering and creating an extensible applcaiton, that can be upgraded as reqirements change. If I can think of an example i'll edit the post.
过度设计只是创建一个具有比所需功能、质量、通用性、可扩展性、文档或任何其他方面更好的产品。
当然，您可能有特定项目之外的要求 - 例如，如果您预见将来会进行类似的应用程序，那么您可能会对可扩展性有额外的要求（取决于成本），您可以将其添加到项目的特定要求中。
Over-engineering is simply creating a product with greater functionality, quality, generality, extensibility, documentation, or any other aspect than is required.
Of course, you may have requirements outside a specific project -- for example, if you forsee doing future similar applications, then you might have additional requirements for extendability, dependent on cost, that you add on to the project specific requirements.
有关更多信息，请访问：
http://www.codesimplicity.com/post/what-is -过度设计/
More on this at:
http://www.codesimplicity.com/post/what-is-overengineering/
免责声明#1：我是一名大局观文学士。 我不知道代码。 我一直在阅读这个网站。 这是我的第一篇文章。
有趣的是，我的老板刚刚告诉我，我过度设计了我们计划指导（目标市场人力资源人员）的新软件产品。 所以我就来这里查一下这个词。
他们希望现在就可以出售一些东西，重新利用现有的工具。 我忍不住坐下来想一想，如果不允许我们谈到的一些灵活性，那么注册人数就会减少，保留率就会降低。 主要是有一个猴子可以使用的高度可视化的用户界面。
他说我们可以计划未来的阶段来改进产品，特别是用户界面。 我们现有的客户正在等待“未来的改进”，但我们仍然没有这样做。 但他们需要它，真正需要它。
我正在辞职，所以我没有拒绝。
但我的定义是............确保它只做尽可能少的事情，尽可能便宜，并且仍然可以满足你所说的要求。 除此之外就是工程设计。
免责声明#2：这个网站帮助我找到了下一份工作，实现了一个更可配置的软件。
Disclaimer #1: I am a big-picture BA. I know no code. I read this site all the time. This is my first post.
Funny I was just told by my boss that I over-engineered a new software produce we're planning for mentoring (target market HR people). So I came here to look up the term.
They want to get something in place to sell now, re-purposing existing tools. I can't help but sit back and think, fewer signups, lower retention, if it doesn't allow some of the flexibility we talked about. And mainly, have a highly visual UI that a monkey could use.
He said we could plan future phases to improve the product, especially the UI. We have current customers waiting on "future improvements" that we still aren't doing. They need it though, truly need it.
I am in the process of resigning so I didn't push back.
But my definition would be.............making sure it only does as little as possible, for as cheap as possible, and still be passable for the thing you say it is. Beyond that is over engineering.
Disclaimer #2: This site helped me land my next job implementing a more configurable software.
我认为您的问题的最佳答案可以在这个其他问题中找到
I think the best answers to your question can be found in this other qestion
敏捷编程的美妙之处在于，如果做得正确，就很难过度设计。
The beauty of Agile programming is that it's hard to over engineer if you do it right.