什么时候变得过度杀伤力？

10

首先，我很抱歉，因为我不知道如何创建社区线程。所以有人帮我

作为开发人员，跨越许多平台，技术甚至在基础架构级别；我总是问自己，我什么时候做得太多？

自从我开始以来，这是一个永无止境的学习过程。我了解到的一（1）件事是，要求在很长一段时间内几乎都无效，因此，稍加预见可能会大有帮助。

但是平衡在哪里，又怎么知道何时失去时间却没有获得时间呢？

development-process scalability

— Theofanis Pantelides
source

1

我们是否在谈论诸如从现在开始就没有客户的第一天就为一百万用户扩展它的事情？还是更多的功能性事情，例如在没有任何建议可能会发生变化，甚至没有人暗示的情况下，使税收计算的方式“可配置”，从而使人们可以在这个假设的新世界中工作呢？

— 乔恩·霍普金斯

1

社区Wiki已被弃用。它从未真正按计划工作。不用担心

— David Thornley，2010年

当您谈论一百万用户时，您的词汇量不应过多。

— Theofanis Pantelides

12

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

与您的团队经常进行代码审查。
与您计划使用的体系结构，技术或模式进行讨论。（如果有，在每日站立会议中）

我与所有遇到的简历驱动的“建筑师”战斗。我希望圆顶存在！;）

我相信全世界都在浪费大量的钱，可用于改善我们（程序员）的生活。

— 社区
source

5

“我与所有遇到的简历驱动的“建筑师”战斗” ：)

— Gratzy

2

鉴于开发人员的水平不平等，我不一定（实际上）对此表示同意。在很多时候，我都会重构相似的项目以使用公共库，但是它并不总是像以前那样可读。

— Theofanis Pantelides

1

我想让每个团队成员充分了解他们正在处理的源代码非常关键。为了您项目的财富，也避免建筑师成为自己实现的奴隶。因此，如果知识差异太大，请先解决。

1

我喜欢你的第一句话；代码的清晰度很重要。但是频繁的代码审查？日常会议中的架构讨论...真的吗？“简历驱动的架构师”到底是什么意思？

— 罗伯特·哈维

1

频繁的代码检查意味着它们必须是自动的。您编写了一项功能，您的一位同事对其进行了审查，必须了解该特征才能对其进行验证。如果他质疑您，那么您将共同努力以使代码更好。您在站立时提到了架构方面的问题，但随后进行了讨论。阅读《谁需要建筑师》（martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf）。CV驱动意味着您将选择一项技术，因为您希望在您的CV上使用它

11

当过程超过结果时。

我们已经看到很多次了，如果开发人员将更多的精力放在过程而不是结果上（如质量，截止日期等），那么坏的事情就会开始。

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

— 总站
source

4

对我来说，我喜欢肯特·贝克（Kent Beck）在XP中提出的方法（不确定是他的想法还是别人的想法，但这是我第一次听说的地方）：

要解决今天的问题，而又不设法弄清楚明天的问题是什么，也要解决这些问题，就很难。

开发人员可以在解决方案上花费大量时间，以解决不存在的需求，永远不会发生的极端情况甚至是真正的问题，其中问题的影响远小于预防问题的成本。

现在是时候投入用户真正想要和使用的东西了，这些东西将给用户带来的好处，将大大超过即使在其中一件事情实际上发生的不太可能发生的情况下所带来的不便。

除了对用户而言这不是最佳结果之外，以这种方式对过度工程的开发人员的影响还往往在于难以支持和增强的复杂代码。

因此，对我而言，如果您知道或可以肯定地确定某事是必要条件或将导致问题，请解决该问题，否则请不要解决。

事实证明，比最初实施的需求范围更广时，您可能需要重新进行处理，但是总体而言，您在整个项目中投入的总精力仍然较少，因为在大多数情况下这种情况不会发生。

— 乔恩·霍普金斯
source

如何对所有模块进行模块化，然后在扩展时更换模块？还是那太矫kill了！？

— Theofanis Pantelides

1

@Theofanis Patelides-良好的结构化代码显然总是一个好主意，但与大多数事情一样，您当然可以将其过分理解。我认为，随着时间的流逝，随着时间的流逝，它会变得本能-您知道您之前所做的工作已经成功，并且浪费了时间。

— 乔恩·霍普金斯

1

您的问题是开放性的，因此我将其解释为“在项目的一部分上做得太多”：

对我来说，花太多时间去做并没有真正为客户带来收益的事情很容易。通常，诸如“很好，它可以工作，但并不完全像我想要的那样”这样的小事情，客户可能不在乎它是否以这种方式工作。

发生这种情况时，我应该停下来，花时间在更重要的事情上。最好还是将产品作为一个整体来工作，但是您可以使用这些较小的零件来完美地工作。

编写跟踪代码（来自Code Complete）可能是避免这种情况的一个好主意：您可以通过编写将整个代码（从GUI（或其附近）一直连接到后端，然后再返回）连接整个代码的代码来启动项目。这样一来，您总会拥有可行的东西，并且在整个事情运行之前，您不会花时间完善这些小事情。

但是，这仍然是纪律和优先级的问题。

— 加布林
source

我同意，但是我也发现自己花了很多时间来使用功能，然后将其传递给非技术性的最终用户，然后由于体积小而拒绝使用它！

— Theofanis Pantelides

1

当我回答“不，我会发脾气时，我后来没有这样做，这使我很伤心。”

IRL资源和时间限制通常在我不得不问这个问题之前就让我明白了。那时，您只关注最重要/可实现的部分，并希望获得最好的。

— 法案
source

1

对我来说，没有什么比从A计划偏离更刺激

— 蒂奥法尼斯Pantelides

1

确实是一个永无止境的学习过程！...而且我认为它会一直保持下去！平衡是当事情足够有效时，您还有时间要做一些除了编程之外的事情。我会同意gablin的“纪律性和优先级问题”，而吉姆·霍普金斯（Jim Hopkins）则认为这会在一段时间后变得本能。我知道完善小零件才是使我们感到高兴的因素，但最终却是使最终用户感到高兴的一切。因此，我要说的平衡点（或折衷方案）是首先使最终用户/客户/客户满意（应该是计划A），然后如果有时间进行完善，则使“小零件”更有效和/或其他您想要的东西。在某些时候，您必须说“足够” :)否则，是的，它将变得过大！

当然，最坏的情况是最终用户/客户/客户是您！:)