问为了获得更高的生产力而犯傻？

EN

轶事时间：

我有两个开发人员为我工作，他们倾向于以这种方式进行过度工程。

对于其中之一，这基本上使他的生产力停滞，特别是在启动一个新项目时。尤其是在项目本质上相当简单的情况下。最终，我们需要的是一款现在能工作的软件。事情变得如此糟糕，我不得不放他走。

另一位易于过度工程的开发人员以极高的生产力弥补了这一问题。因此，尽管有所有无关的代码，他仍然比大多数人交付得更快。但是，现在他已经开始工作了，我经常发现自己对增加功能所需的额外工作感到恼火，因为您必须修改(完全不必要的)抽象层等等。

因此，我们的寓意是，过度工程会消耗掉更多的时间，而这些时间可以更好地花在做有用的事情上。不仅仅是你自己的时间，还有那些必须使用你的代码的人。

所以不要.

您希望您的代码尽可能简单(而不是更简单)。处理“可能”并不能使事情变得更简单，如果你猜错了，那么代码就会变得更加复杂，而不会给它带来真正的好处。

实心和亲吻/YAGNI原则是接近极性的对立面。有人会告诉您，如果不能将doSomething()作为调用它的类的工作的一个组成部分，那么它应该位于一个松散耦合和注入的不同类中。另一个会告诉您，如果这是使用doSomething的一个地方，甚至将其提取到一个方法中也可能是过度的。

这就是为什么优秀的程序员值得他们的黄金重量。“适当的”结构是一个逐案的基础，需要了解当前的代码库、程序的未来路径以及项目背后的业务需求。

我喜欢遵循这个简单的三步方法。

• 第一步，让它发挥作用。
• 第二步，把它弄干净。
• 在第三次传球时，把它做好。

基本上，这就是你如何和实心接吻的方式。当你第一次写一行代码的时候，你知道这是一次性的；它只需要工作，没有人在乎怎么做，所以不要太花哨了。第二次将游标放入这一行代码时，您已经证明了原来的假设；在重新查看这段代码时，您可能会将其扩展或从其他地方链接到它。现在，您应该清理一下它；为常用的提示提取方法，减少或消除复制/粘贴编码，添加一些注释等等。当您第三次回到这个代码时，它现在是程序执行路径的一个主要交集。现在，您应该将其作为您程序的核心部分，并在可行的情况下应用坚实的规则。

示例:您需要将一行简单的文本写入控制台。第一次发生这种情况时，Console.WriteLine()就很好了。然后，在新的需求还要求将同一行写入输出日志之后，您将返回到这段代码。在这个简单的例子中，可能没有太多重复的“复制/粘贴”代码(或者可能有)，但是您仍然可以进行一些基本的清理，可以提取一两个方法来避免将IO操作内联到更深层次的业务逻辑中。然后，当客户端希望将相同的文本输出到监视服务器的命名管道时，您将返回。现在，这个输出例程是个很大的问题，你用三种方式播放同样的文字。这是一个从复合模式中受益的算法的教科书示例；使用Write()方法开发一个简单的IWriter接口，实现该接口以创建ConsoleWriter、FileWriter和NamedPipeWriter类，再一次创建" MultiWriter“复合类，然后公开类上的IWriter依赖项，与三个实际编写者一起设置MultiWriter复合，并将其插入。现在，它非常可靠；从这一点开始，每当需求要求输出到任何新的地方时，您只需创建一个新的IWriter并将其插入到MultiWriter中，就不需要触及任何现有的工作代码。

只有A才能做的好代码比能做A、B、C、D的坏代码更糟糕。

1)有一个只做应该做的事情的代码.

如果我觉得这段代码可能在最近的将来变得更大，我会考虑添加抽象，将这个功能移到其他地方等等。

(

2)如果你计划你的代码做A，B，C和D，客户最终会向你要E.

您的代码应该做应该做的事情，现在不应该考虑将来的实现，因为您永远不会停止不断地更改代码，更重要的是，您将过度设计代码。您应该在认为代码需要它时立即重构它，因为它具有当前的特性，而不是为它还不打算做的事情做好准备，当然，除非您将它作为项目体系结构的一部分来计划。

我建议你读一本好书：务实的程序员。它会让你敞开心扉，教你该做什么，不该做什么。

此外，代码完成是一个非常好的资源，它包含了每个开发人员(不仅仅是程序员)应该阅读的有用信息。