做“足够好”的软件的后果

Question

做“足够好”的软件会不会让你成为程序员？

以下是我对此的看法：

来自JoelOnSoftware的Joel Spolsky说，程序员感到无聊，因为他们“足够好”（即使他们没有那么优化，也能满足要求的软件）。我同意，因为人们喜欢做一直都是正确的事情。在光谱的一侧，我想走到：

1. 以尽可能多的方式应用我在大学时获得的数学和计算机科学知识，优化软件。
2. 所有可能的软件开发过程都说：从一个存储库中获取规范，生成代码，构建，测试，在一个自动构建步骤中完成手册部署。

另一方面，对我们人类的一个特点是我们喜欢变化。为了让我们保持吸引力（热爱编程），我们需要从一个项目或技术跳到另一个项目或技术，以便我们不会觉得无聊并且“有趣”。

如果作为程序员或人类为您做好“足够好”的软件，是否有任何好的或坏的副作用，我想您的意见？

Answer 1

我实际上认为足够好的程序员比蓝天可靠的一切都更完美。

那是因为，虽然我是一名程序员，但我也是一名商人，并且认识到程序不以满足程序员的需求，他们需要满足特定的业务需求。

我实际上在另一个问题上有一个问题，即关于检测一个非常棒的比赛/比赛和比赛的最佳方法（面试问题）。

我收到的最佳解决方案来自一位候选人，他使用if语句检查所有8种可能性。有一些提供了一个通用的解决方案，虽然可行，但完全没有必要，因为规格很明确，只适用于3x3电路板。

许多人认为我的限制性太强，“获胜”的解决方案是垃圾，但我认为编写完美的可扩展软件并不是程序员的工作。满足业务需求是他们的工作。

如果该业务需要允许他们自由地做更多必要的事情，那很好，但大多数软件和修复都是在时间和成本限制下提供的。程序员（或任何职业）不在真空中工作。

Answer 2

作为一名程序员，我想编写一款无缺陷的优秀软件。我对镀金并不特别感兴趣，这是添加“改进”软件的不必要功能的行为，尽管我们都在一定程度上这样做。从这个意义上说，我对“足够好”的软件感到满意，如果足够好你就意味着我已经完成了客​​户的要求，同时也很好地制作了它并确保了它的高质量。

让我烦恼的是当我采取捷径并编写糟糕的，未经测试的代码时。我讨厌编写有缺陷的代码，或者我没有将它重构为更好的设计，因为我已经过去了。当我让很多技术债务陷入困境时 - 忙于编写新功能而不是不断改进旧功能，因为我正在添加新功能 - 然后我知道最终我会有一些东西，而客户可能是很高兴，我不会。

幸运的是，在我的工作场所，管理层知道保持代码清洁的价值，而且我知道不要过分追求完美的难以捉摸的目标。没有代码是完美的，但“足够好”必须意味着代码是精心设计的。我已经了解并且仍在学习，对满足客户要求的代码感到满意，并且最好的功能是不需要实现的功能。幸运的是，我有足够的工作去做功能，因为它们不需要是一件好事。

Answer 3

根据我的经验，“足够好”总是包括黑客，邋,,糟糕的评论和意大利面条地狱，从而导致缺乏可扩展性，错误，懒散，并阻止其他人能够有效地建立你的工作。

Pax，虽然我认识到您对业务需求和实用主义的看法，但“按书”做事情 业务方面。 “现在已经足够了”和“只是让事情快速正常工作”总是会导致更多的工作时间来修复所有事情，或者直到重做它，而不是第一次做正确的事情。 “这本书”是出于某种原因而写的。

Answer 4

IMO“足够好”和糟糕的代码之间存在很大差异。对我来说，“足够好”就是满足要求（功能和非功能）。我认为人们认为“足够好”意味着采取捷径或不优化代码是危险的。如果非功能性需求需要优化代码，那么这就是我对“足够好”的定义的一部分。

Answer 5

问题的关键在于如何定义“好”。对于商务人士而言，“好”软件是解决业务需求的软件。在这种情况下，更多的是确保规范得到充分理解并得到适当的启发。业务人员可能不关心程序是否没有尽可能快或内存效率。

想想你使用的商业软件，它是否完美？我真的不认识任何人，包括我在微软的朋友，谁会认为Windows中的代码是“完美的”或任何接近它的代码。但不可否认的是，Windows（并且一直都是）“足够好”，每天都有数百万人使用它。

这个问题可以追溯到编程之前很久。我相信你已经听过“如果它没有破损，就不要修理它”或原版的法语“Le mieux est l'ennemi du bien”。可能是伏尔泰写过“好人是伟人的敌人”。

考虑一下，如果招聘经理决定停止聘请“优秀”程序员并坚持每个申请人在大学里有一个完美的4.0平均成绩，那么将会发生什么事情，我将永远不会找到一份程序员的工作; - ）

所以对我来说，这是一个尽你所能给出时间和预算限制的情况。有了更多的时间和更多的钱，我总能做得更好。

Answer 6

“足够好”是旁观者的眼睛。很多时候，“足够好”是不称职的人的避难所，他们写出的东西会产生满足工作要求的印象。我的“足够好”不太可能与他们的“足够好”相同。

最终，我们所做的每件事都必须涉及权衡。有些人会做出错误的权衡并提供糟糕的软件，有些人会做出错误的权衡并且无法实现。很少有人可以做出正确的权衡并提供真正足够好的软件。

Answer 7

我们必须考虑至少两个质量方面：

• 软件质量：软件是否符合预期目标/要求？我们提供有严重错误的构建吗？最终用户是否容易操作？
• 代码质量：维护代码有多难？实现新功能是否容易？

如果您正在构建一个产品化的软件，我认为假设它在这两个方面都不够好是很好的。每个小功能都很重要，如果用户找不到他们需要的产品或者产品不够稳定，他们会看一下竞争对手。您还希望尽快实施新功能，以便在市场中获得竞争优势。

如果您正在构建自定义业务软件，最终用户和决策者通常不是同一个人，那么情况会变得有趣，那么功能/质量/资金权衡将成为谈判过程的一部分。我们通常做的是对这三个方面施加“足够好”的约束：我们有一套满足的要求，一个维持的质量，通常没有足够的时间来保持两者。

在此过程中通常被遗忘的是第二点：代码质量或可维护性。我们程序员明白，早期或后期的蹩脚代码会报复并导致严重的错误或维护成本。决策者没有。问题是，您（您的公司，您的部门等）承担了责任和风险，如果出现问题，您将首先承担责任。

我的观点是：对于软件质量做客户告诉你的事情，他们最了解哪些功能对他们至关重要，软件可以有多少bug等。对于代码质量和可维护性：尽可能做到最好，学会做更多，并教别人做同样的事。这是我从中获得乐趣的地方。

Answer 8

取决于“足够好”的意思。我可以在设计层面看到一些风险，如果你做得足够好，你可能会发现维护和扩展你的应用程序很痛苦。

Answer 9

我认为编程是艺术。一种需要效率的艺术。高效的代码是否与漂亮的代码不兼容？我不信。事实上，我认为当你创造性地解决问题时，它可能意味着成倍增加。我不认为编程应该只是为每个新需求学习一个新的库，也不是关于bug跟踪和修复。我认为这应该是关于美。当然代码不能总是艺术，有时应该对遇到的问题务实。