Architecture 过度工程的具体症状

我最近发现自己的职位是解释一份（内部）申请，我给我的公司喜欢雇用的两名候选人写了一封信，以帮助他们进行维护和添加次要功能

这是我写的第一个“生产”应用程序，它有45k个LOC，我花了将近两年的“单独”开发时间。我相当年轻（18岁），在与一位离开公司的前开发人员签订代理合同时，我从头开始编写了该应用程序。我在设计这种规模的应用程序方面没有经验，我尝试使用通用的架构和设计模式

今天，我知道我在工程上做了一些认真的工作，例如，使用了一个断开连接的变更跟踪体系结构，而不是工作单元模式，所选择的ORM已经实现了这种模式。我可能永远不必去“真正的”三层

两位候选人都有10年以上的相关平台内部应用程序开发背景。由于年龄只有他们的一半，经验不足，我尊重他们的意见。当我向他们解释应用程序体系结构时，评论大致如下：

• 天哪，没有人会付钱让我做那样的事，我必须把事情做好
• 坚持框架的功能，不要使用花哨的库/技术
• 不要包装框架代码。在团队中，每个人都会编写自己的包装器代码
• 您正在使用.NET3.5？我们使用的是2.0
• 那LINQ的东西给我买了什么？所有这些查询组合和投影看起来都太复杂了

现在我在问自己：
我是一个年轻人吗？我怎么知道我在建筑方面走得太远了？过度工程的常见症状是什么？

避免使用，并在查看过度工程的事物时想到。如果有许多部分似乎是部分完成的，而代码的许多部分似乎有一个“如果发生这种情况会怎样？如果发生这种情况会怎样？”的感觉，那将是另一点。忽略或将是另一个需要注意的问题。如果您认为自己已经编写了完美的代码，那么这将是另一个麻烦的迹象，因为对于任何人来说，编写无法以这种或那种方式改进的代码是极其罕见的

---

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

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

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

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

常见的症状是什么 过度工程化

---

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

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

---

你也谈到过的人可能有一些好的建议，但这并不意味着你需要把他们说的一切都当作福音。例如，在一个新项目上使用最新版本的.NET对我来说没有什么可担心的。他们真的在抱怨吗？

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

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

这是我的“快速测试”，以确定应用程序是否有过度设计的倾向：

• 用于“一切”的包装纸：包装纸很有用，但很容易过度使用。检查是否只包装真正需要包装的东西。（我基本上自己包装过一次。我知道我在说什么；-））
• 重塑车轮：经典之作。这是很常见的，你已经提到过了。您实现了一些功能，因为您需要您想要的吗？您的框架做了什么，而其他可用库做不了什么
• “感觉”设计过度：这是最重要的一点，但也是最重要的一点

  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.