问什么时候会变得过分呢？

EN

当普通开发人员通过阅读代码无法理解您所做的事情时，您做的工作太多了。

• 与团队一起进行频繁的代码评审。
• 与您计划使用的体系结构、技术或模式进行讨论。(如果你有，可以参加日常的起立会议)

我对抗所有的简历驱动的“建筑师”，我遇到。我希望穹顶存在！)

我相信这个世界在浪费一大笔钱，我们可以用这些钱来改善我们(程序员)的生活。

当进程超过结果时，

.

太多次了，我们已经看到，如果开发人员更多地关注于过程而不是结果(比如质量、确定最后期限等)。坏事开始了。

这就是为什么应该永远不要忘记，代码评审、设计模式等的目的是使代码更好，但它们本身并不是目标。

对我来说，我喜欢Kent Beck在XP中提出的方法(不确定这是“他的”想法还是其他人的想法，但这是我第一次听到的)：

很难解决今天的问题，而不想弄清楚明天的问题是什么，而且也要解决它们。

开发人员可以花费大量的时间来解决根本不存在的需求、永远不会发生的边缘情况，甚至是真正的问题，这些问题的影响要比防止问题的成本要小得多。

这是时间，可以投入到用户真正想要和使用的东西，这些东西将给他们带来巨大的好处，甚至会带来的不便，即使是不太可能的情况下，这些事情中的一个实际发生。

除了对用户来说这种非最优的结果之外，以这种方式对开发人员造成的影响往往是复杂的代码，这些代码更难支持，更难增强。

所以对我来说，如果你知道，或者相当肯定，某件事是一种要求，或者会导致一个问题，那就解决它，如果不是，那就不要。

当发现有一个比最初实现的更广泛的需求时，您可能不得不返回并重新工作它，但是一般来说，您在整个项目中投入的总精力仍然较低，因为在大多数情况下，这种情况不会发生。