我相信这是因为我们将讨论创建产品时最普遍的问题之一：过度设计。在我看来，与缺乏良好的开发实践相比，过度设计杀死了更多的产品。
在详细介绍之前，让我先和您谈谈我的背景。在成为产品经理之前，我是一名工程师。事实上，我的正规培训是计算机科学。虽然在我的职业生涯中，我一直更接近业务而不是自己编写代码，但我创建、扩展和管理工程和产品团队都是平等的。
所以我并不是从外部谈论过度设计。我为造成并遭受了它而感到内疚。正因为如此，我知道了解它是什么、它的成本以及我们如何预防它是至关重要的。
什么是过度工程？
过度工程 （或过度工程， 或过度杀伤）是以过于复杂的方式设计产品或为问题提供解决方案的行为。
在软件方面，我喜欢Paweł Głogowski 的这个定义：
解决您没有的问题的代码或设计。
现在你会想，谁设计或编码来解决她没有的问题？看起来很可笑，对吧？好吧，因为经过 20 年的职业生涯并自己完成了这件事，我可以向您保证，过度设计也不例外；这是常态。
过度设计的原因
没有人怀着恶意这样做。在很多情况下，过度工程的发生是因为我们试图预测未来 并为未知事物做好准备。
当我们编写一个功能时，很容易认为我们可以通过多花一点时间“以防万一”来使它面向未来。
现实情况是，十有八九，“以防万一”永远不会到来。但在此过程中，我们失去了宝贵的时间并增加了项目的复杂性，而这将贯穿其整个生命周期。
过度设计的另一个原因通常是缺乏经验。一般来说，你的资历越高，你就越不容易过度设计，因为你已经经历了很多人为复杂性在你面前爆炸的情况。
关于工程师经验的学习曲线通常遵循与此非常相似的模式：
- 您可以从直接编程开始。
- 您会发现诸如面向对象编程之类的范式，并跟上潮流。
- 您阅读了设计模式并开始寻找在各种情况下实现它们的机会。
- 在经历了几年不必要的复杂性之后，你又回到编写简单的代码。
松散定义的需求也 增加了这个问题。如果工程师没有明确定义的问题，他会倾向于过度设计以保护自己免受不确定性的影响。
无聊也会导致过度设计。如果工程师没有要面对的激动人心的挑战，他可能会通过尝试新事物而最终使任何问题复杂化。
过度设计的后果
当我在文章开头说过度设计会杀死初创公司时，我并不是在开玩笑。它对任何系统都有两个特别有害的影响。
一方面， 它增加了我们的开发成本。如果我们的工程师不选择最简单的解决方案来解决问题，我们的时间和金钱成本就会增加，从而阻止我们更快地迭代。
另一方面，它也会增加您的维护成本。简单的代码更容易编程、测试和修改。当我们将其复杂化时，复杂性会呈指数级增长，从而影响我们的迭代速度。
所以我再次肯定自己。过度设计会扼杀产品。不仅仅是缺乏良好的工程实践。
过度工程示例
首先想到的是基于微服务的架构。几年前，它们就像一波又一波的浪潮，他们应该取消比合并的项目更多的项目。
我将它们作为过度设计的一个例子，因为它们在 99% 的情况下都不是必需的，特别是对于必须找到适合市场的初创公司，并且将从使用更直接的架构模式。
过早优化 通常是过度设计的另一个典型例子。一种常见的情况是，当您仍然没有用户时，准备一个系统以通过过于复杂的基础设施设置来吸收大量流量。在大多数情况下，您只需在单个服务器上运行单体应用即可验证您的业务模型。
过早优化最糟糕的例子之一就是我们花费大量时间设计一个系统，试图防止在未来重复我们自己，并且不得不丢弃部分已完成的工作。
如果你从来没有看到它工作，因为你以前破产了，那么你的设计或实现有多完美并不重要。世界上帮助你验证假设的最糟糕的代码比因为害怕重复自己而停滞不前要好。
，软件重写是过度设计的一个明显例子。通常，工程师不喜欢在遗留代码库上工作。他们的自然倾向是从头开始做任何事情。重写很少能达到目的，甚至会夺走你的业务。
说起来很明显，但你的客户并不关心你的系统内部有多优雅。你的客户关心你帮助他解决他的问题。投入到不给他们价值的每一分钟都是浪费的一分钟。
...
防止过度设计的心理模型
- YAGNI
过度设计的问题在行业中非常普遍，以至于工程师们自己有一个术语来指代“以防万一”添加代码的情况：YAGNI，“你不需要它”的首字母缩写词。
YAGNI 试图阻止您添加任何对于解决您面前的问题并非绝对必要的内容，因为现实情况很可能是“您不需要它”。
- KISS
术语 KISS，“保持简单愚蠢”，指的是简单系统更容易修复、发展和维护的事实。因此，简单应该是任何设计的目标之一，避免任何不必要的复杂性。
- 更糟更好
越差越好，我们强调的是，选择越少，选择越多。这样做是因为它可以简化我们产品的使用，使其对更广泛的市场具有吸引力。
换句话说，它鼓励我们保持产品最基本的功能，避免添加会增加产品复杂性的脂肪。
如何防止过度设计？
在我看来，防止过度设计的最佳方法是将您的工程师变成真正的产品工程师。
我们可以通过让他们参与日常业务，在每个计划之后解释原因，并将其与对组织及其愿景重要的指标联系起来来实现它。观看此MTP 面板以了解有关定义重要指标的更多信息。
我们需要让他们更接近我们的用户，邀请他们与他们进行访谈和发现会议。您希望您的团队密切关注用户的问题，以便他们可以迅速放弃任何无法尽可能有效解决问题的工程工作。
如果您将工程团队视为单纯的生产链资源，其唯一任务是从积压工作中实现用户故事，那么不要期望您的工程团队有动力去避免复杂性。他们需要了解每个决定背后的原因。
与上述相关，很好地定义问题以减少歧义。您的工程师需要知道原因，但他们也需要知道会发生什么。你越能缩小问题的范围，他们就越没有理由保护自己免于过度设计解决方案。定义系统期望的一个好方法是使用SLI 和 SLO来使用服务目标。
工程师是任何公司中最具创造力的人物之一。如果您的团队信任您的标准，他们可能会出现日常想法或计划，这可能表明他们正在考虑未来的“假设”情景。当您有直觉可能是这种情况时， 请问：这如何帮助解决我们当前用户的问题？如果我们现在不这样做会怎样？ 这些答案将帮助您区分是否存在过度设计的情况。
最后，更偏向于创始人，优先招聘已经在产品公司有过一些经验的高级工程师。在面试中寻找战争疤痕。询问他们最痛苦的经历以及他们如何处理这些经历。坚持那些将用户和简单性置于简单技术解决方案之前的人。
详细点击标题
banq：过度这个词语，与好 坏词语一样非常主观化，业内也无法达成共识，因此定义模糊的情况下争论没有意义。其实这是一个复杂的社会技术系统，不要超过团队认知负荷，也不能不足，与智商、认知天花板多少有点关系。过度设计是一个伪命题，花费在伪命题上正确废话阅读，越浪费时间和脑力，不如打坐冥想。
黑客新闻讨论
我不认为你可以在事后判断它是否过度工程。除非你在房间里，或者可以访问一个精心记录的团队的书面规范，否则你不了解编写代码的条件上下文。
可能公司当时会押注于集成市场或大量合作伙伴关系，因此构建了一个强大的集成平台。然后，该公司在新平台上只编写了一两个集成后，就转向了另一个赌注。没有人在这里过度设计。一切都是按照规范建造的。但是三年后，新开发人员将在其中一个集成中发现一个错误，并感叹代码是如何过度设计的。
许多来自战壕的故事，包括这个线程中的许多故事都犯了这个错误。“科技债务”也是如此。如果你不在那里，你不知道。（身在庐山不识庐山真面貌）
我认为这里的教训是，产品市场契合度高时，一切都是设计不足；产品市场契合度差时，一切都过度设计。从统计上讲，与构建具有良好市场契合度的设计不足的产品相比，您更有可能构建出产品市场适应性较差的过度设计的产品。
某些东西可能曾经被精心设计过，而今天仍然被过度设计。C 和 C++ 中的头文件就是这种现象的一个例子。他们解决了 40、50 年前技术限制的一个非常现实的问题，无论是在计算机能力还是编译器技术方面，但是，由于这些问题不再存在，它们起到了过度设计的作用。
根据我的经验，您所描述的情况更多地会导致“草率”代码——它似乎令人费解、不明显。
过度设计的代码乍一看通常看起来很整洁，甚至可能令人印象深刻，尤其是对非技术利益相关者而言。然后当你真正深入研究它时，你会注意到一堆错误的抽象，这些抽象引入了间接层，而没有提供任何有价值的灵活性。
你花在它上面的时间越多，多次重构的代码库越有意义，过度设计的代码库越少。