您在哪里划定完美主义的界限？[关闭]

编程时，完美主义可能是好事，也可能是坏事。

• 解决问题的时间和地点在哪里？
• 您什么时候决定解决方案过高，太笼统或太过未来？

如果问题不清楚，请发表评论。

KISS和YAGNI，尤其是YAGNI。

仅针对您知道很快需要的事物设计解决方案。不要为两年内可能需要的东西进行工程设计，因为很可能您将需要非常不同的事物，并且无论如何都必须对其进行重新设计。

当您开始谈论“在将来某个时候使用此设计，我们可以做X甚至Y”时，而不是在“此设计允许我们在下一个版本中满足客户要求Z”的那一刻，您将获得进入建筑天文学。

针对评论：

• 吻=保持简单，愚蠢=假装自己是白痴，必须了解设计
• YAGNI =您将不需要它=停止假装可以预测设计的未来

使用迭代方法，这个问题通常会消失。您的代码应该在第一天以及之后的几乎每一天运行。首先满足最低要求，并在有空的时候增加更多。切勿在无法长时间运行代码的地方进行重大更改。

如果完成解决方案所花费的额外时间比从完成更简单的解决方案到下一步自然进行升级/修改所带来的潜在负面影响更有价值，那么该解决方案就是多余的。

基本上，您现在要交易时间，以后要交易。如果您现在花更多的时间，那么您将在以后节省更多，这是您做错了。如果您真的要结束工程学，那么您现在花的时间不会影响您以后花费的时间（甚至增加）。

您会更好地解决这个问题，从而获得更多的经验。最好的方式（根据我的经验）是现在就做您需要的事情，但是如果以后的需求需要它的话，这种方式最容易扩展。弄清楚该怎么做是棘手的。

我曾经是非常完美主义者（花时间创建框架，而不是解决方案）。

但是真正帮助我提高生产速度的是学习和遵循BDD / TDD原则，包括原则上的外部原则（我发现很难学会采用）。

这确实教会我不要在测试之前编写任何代码。但是在进行验收测试之前，单元测试也不存在。验收测试来自真实的用户需求。

因此，所有代码行都源自真实的用户需求。

如果您原则上不熟悉外部环境，则表明您开始使用测试倍数来模拟较低层的行为，从而开始为应用程序中最外层（即几乎在所有情况下为GUI）编写测试。然后，您只需实施足够的测试即可通过。然后，顶层的这种实现指示了您需要为下一层等编写的测试，等等，直到您到达应用程序的底层。

我发现凭经验我会变得更好。

当我很小的时候，我总是追求最完美的解决方案，没有妥协。现在，我更擅长考虑预算和时间。

时间限制使这条线很清楚。

我的老板实际上是:)

我必须承认我正在进步，但是我仍然没有太多妥协的余地。值得庆幸的是，我让我的老板来控制我；）

我想提出的不是工程过度，而是另一个问题，因为工程过度非常容易发现。

我的主要问题是重构。问题是，即使我试图尽我所能编写代码，但大多数时候我还是不知道当时我所知道的东西（看到了更多代码，更多模式，新习语，新问题，新内容）解决方案）。因此，即使它可行，我现在也知道更好的方法：

• 可以提高可用性并减少获取错误的机会的方法
• 减少依赖关系，改善编译时间的方法

但是，它按原样工作，因此重构它不是优先事项，事实是它正在困扰我。我了解经济原因，也了解客户的期望（他们看不到代码，而是喜欢新功能和错误修复），但我希望我有时间继续努力。

现在，我只是遵循老板的命令，但是我必须承认，对于交付到生产环境中的代码并不是我现在想出的最好的代码，我感到不安。我猜是完美主义。

无论是在职业上还是个人上，我尝试适用于自己的标准是：

对胜利感到满意。

如果我的代码解决了本来要解决的问题，并且没有创建任何新问题*，那么很可能需要继续进行下去。当您学习将条形设置为需要设置的上限时，“足够好”就变得足够好。

完美就像光速：您永远不会到达那里，但是尝试所消耗的能量是无限的。

（*-请注意，“ Buggy”和“难以维护”都牢牢属于“新问题”的标题。因此，在测试代码，修剪掉多余的位并进行最新的注释/ API文档。）

凭着经验，我意识到，在任何特定情况下（语言，框架，平台，标准）至少要有几年的经验，完美主义才是不可能的。作为一个新手也将是各种特质的，你不会知道（逃逸，优先级，保留字，语法糖，超时，异步调用，无证功能和错误），所以我只是尝试了很好的解决方案，所有的同时尽可能地学习。重要的是，我总是尽量简化重构结果的方法-模块化体系结构，在需要的地方添加注释，并且没有巧妙的技巧。

与许多其他程序员一样，我有很多传统代码需要维护。重做所有内容的诱惑总是存在的，但是我基本上将其归结为一个原则：

我（或其他人）是否必须再次解决这个问题？

通常，这会将大量的意大利面条代码变成了更易于管理的意大利面条块代码。提取一些块，进行测试，现在看起来并不需要那么完美。