过度工程的具体症状[关闭]

过度工程化?

解决您没有的问题的代码。

过度工程的一个非常强烈的警告信号是,当一切都经过如此多的间接过程时,很难找到真正实现某些具体的、域级功能的代码段。如果您发现大多数函数只做很少的具体工作,而只调用其他虚拟函数,那么您可能会遇到问题。

无聊

无聊是过度设计代码的良好前兆。我承认,当我得到第一份工作时,我觉得自己没有得到充分利用。我只是觉得无聊。当我感到无聊时,我就写代码。不仅仅是任何代码——代码的大教堂。

看到这些模式在一起为我自己工作真的很吸引人,但回想起来,我对我留下的不虔诚的混乱感到完全羞愧。

如果您正在编写自己的框架和DSL代码,以消磨工作中不太刺激的时间,请停止。时间最好花在阅读上 Wards Wiki ,或写作 an open source book

编写自己的框架

很可能有人已经做过了。更重要的是,他们已经比你做得好了1000倍。更重要的是,他们所做的一切可能已经成为行业标准,因此学习这项技术将使你在其他工作中更具竞争力。

factory factory “我可以这么说。

请注意,这段代码实际上非常出色,但重点是什么?

编写更好的核心库

在我目前的公司,程序员似乎总是在编写无用的代码来复制.NET框架中已经存在的功能。

• ASP.NET webforms中用于表单身份验证的active directory框架——因为ASP.NET内置了此功能,所以无法解释。
• 网站的可热插拔主题和皮肤——同样令人费解,因为代码的功能不如内置的ASP.NET主题,需要增加1000%的膨胀。
• 他们莫名其妙地编写了自己的类型化数据集和数据适配器。这些对象提供的功能比VS自动生成的类型化数据集少,同时需要比NHibernate域对象更多的样板代码。

我能想到的重新实现的库比原始库更好的例子非常少(参见 Jane Street Core Library C5 Generic Collections for .NET , a real currency class ),但很有可能,您不会编写更好的标准库。

至于关于你是否是一名建筑宇航员的问题:如果你意识到让你领先于许多人的危险。你也不想走你的奶牛工人的路,听起来他们中的一些人已经变成了脾气暴躁的老抱怨者。

过度工程化是优先级问题的结果,该问题导致系统的某些部分受到过多关注。因此,过度工程最明显的症状是,你可以看到整个系统的其他部分由于缺乏关注而受到伤害。

(还有一种趋势是,过度设计会使系统面临更大的不良设计风险,这是因为在决定过度设计的方面时会增加复杂性和容易出错的猜测,但正如评论所指出的,这不会自动发生。)

对于大多数内部业务应用程序,您的大多数代码都应该关注实现业务关注点,而不是与业务无关的技术关注点(如“断开连接的更改跟踪体系结构”)。目前可用的框架相当成熟,支持最常见的用例。如果您正在发明新技术,或者(在业务应用程序开发的上下文中)只是为了包装而包装其他现有框架或库,那么您可能做得不对。理想情况下,您构建的每一个体系结构都应该可以追溯到某些业务需求。保持简单。

我想你得到的大多数关于你的应用程序的评论都不是关于过度工程的,因为过度工程不是关于技术的。这是关于建筑的。新技术可以在合理的时间内学习和理解。理解过度设计的应用程序通常要困难得多,有时甚至是不可能的。这使得第2、4和5点无效。第一点并不是真的有效,因为很明显,你是因为编写应用程序而获得报酬的,如果它能工作,你在这里就没有问题了。

这是我的“快速测试”,以确定应用程序 倾向于

• 包装纸是有用的,但很容易过度使用。检查是否只包装真正需要包装的东西(我基本上只包了一次我自己的包装纸。我知道我在说什么;-))
• 经典。这是很常见的,你已经提到过了。您实现了一些功能吗 给你 到您的框架做了什么,而其他可用库做不了什么?
• “感觉”过度设计: 这是最重要的一点,也是最难看到的一点。看看你的代码,看看哪些部分感觉过于复杂。然后问问你自己,是否有更简单的方法来实现它,以及为什么你没有选择这种方法。如果你没有得到好的答案,这部分可能是过度设计。

这些只是我在应用程序中使用的快速提示。它们不能保证是“过度工程检测”的全部。

当一台同事的电脑飞过你的头顶,因为他们花了6个小时试图用你那可笑的框架显示一个奇怪的对话框,但却失败了,这就是一个非常具体的症状。

YAGNI DRY KISS 当看到过度设计的东西时,你会想到这一点。如果有许多部分似乎是部分完成的,而代码的许多部分似乎有一个问题,“如果发生这种情况怎么办?”?如果真的发生了呢?“感觉一下,那将是另一点。忽略 good principles of OO design SOLID principles 这是另一个值得注意的问题。如果您认为自己已经编写了完美的代码,那么这将是另一个麻烦的迹象,因为对于任何人来说,编写无法以这种或那种方式改进的代码是极其罕见的。

在我看来,要注意,有些人可能对你的工作过于挑剔,因为任何代码库都可能涉及到喜欢某种方式的人,例如方法、测试和变量的命名约定。事情就是这样。现在,你可能需要弄清楚的是,如何处理诸如 conflict 或 persuasion/influence ,那里有可以帮助的工具。

为应用程序提供固有功能的插件

如果您不需要对应用程序进行特别添加,也不要期望任何人编写第三方扩展,并且应用程序的范围定义得相当好,那么您不需要可插入的体系结构。

同时,你是团队中的新手,即使他们喜欢你所做的,你也会受到一些嘲笑。

这一切都要小心。接受他们的批评,点头,然后和他们一起喝杯啤酒。

尝试评估您是否在代码的预期生命周期内尽可能减少了工作量。这包括维护和开发。

此外,不同的应用需要不同的工程量。如果此应用程序失败,是否会导致生命损失?也就是说,它是机械心脏的控制器,还是航天飞机导航火箭的控制器?或者是无聊青少年的联系名单?

I feel that when there's a gap between the complexity of the problem and
the complexity of the solution, then you have a clear case of overengineering. 

实现这一目标的途径是什么? 解决你没有的问题,看到问题比实际情况更复杂,试图对未来做太多的预测,构建太一般的东西,等等。

您是否在合理的时间范围内实施了您的项目?现在能用吗?如果是这样的话,你可能会放松一点,因为过度工程最糟糕的问题之一就是永远无法完成任何有用的事情。

其中一半是老年人(我和他们一样)坚持使用他们所知道的久经考验的真正的蒸汽机。另一半是真的,但没有告诉你任何新的东西。

最难的 我日常设计的一部分&编程工作。

事后诸葛亮

我有过多次事后的经验,我对自己说:“我希望我不要把这件事复杂化太多”,但也“如果我能听一下脑后的小声音,让它在这里更普通一点就好了”。

我还没有提炼出打电话的绝对规则。。。

我怀疑我有过度设计的倾向,所以我把这张照片做成了我电脑的墙纸

我有点想提供一个不同的视角,但我认为这个词应该删掉,用一个更合适的描述代替。它给“工程”打上了一个烙印,而“工程”最重要的是简单性、可维护性和实用性,因为许多被称为“过度工程”的东西具有完全相反的性质(好像工程太多,或太认真,应该会产生最复杂的解决方案)。例如,我们经常会看到过度工程化和糟糕的测试程序之间的相关性(至少我经常看到这两个过程是同时进行的),以及什么样的过度工程化会执行最少的正式测试?

有很多人真正认识到“过度工程”的真正味道,但这个词至少可以说是误导性的。

至于症状,除了已经提供的优秀症状外,对我来说,能够正确评估和重新评估摆在你面前的工作是一个盲点。程序员可以在他们的想象中构建世界,沉迷于高耸的概念并全神贯注于其中。虽然这是一种枯燥而笼统的回答,但这可能会导致一种危险,即不再看到我们眼前的实际问题和优先事项。过于深入的概念化往往会形成一个盲点,使问题变得过于复杂,与现实和实际的用户终端需求失去联系。对我来说,最需要注意的症状是心理问题。

围绕制作的各种职业都容易受到这一基本趋势的影响,人们会因为过于沉迷于概念而忽视需要解决的实际和紧迫问题(例如:电影导演)。对于一般的编程来说,一种解决方法是在概念化到第n个层次之前(为我们赢得更多的时间重新评估,以免我们太深地爱上任何想法)提倡简洁、简单、实用、编码。接受这些理想不会有太大的错误,但对我来说,关键是避免形成阻碍我们正确评估自己工作的盲点。过度设计的代码库不会在一夜之间产生——它需要在错误的方向上进行大量的专门工作才能产生,而对我来说,最大的可预防问题不是与预见相关的,而是通常发展适当的后见之明太迟了。