如此多的方法来编码一件事，决定什么是最好的？

Question

您是否曾经遇到过编码问题的情况，然后发现自己想知道自己是否采用了最佳方法？所以你最后以另一种方式编码，然后再次发现自己是否可以做得更好。你如何确定何时停止并继续下一个问题以避免进入圈内？

Answer 1

做最简单的事情。

Answer 2

定义“最佳”。

如果是这样的话：

1. 可读
2. 表现良好
3. 维护
4. 尊重项目的时间表

然后这是编码它的“最佳”方式。

Answer 3

如果它有效，足够快，可读性和可维护性，那么现在是时候继续前进，否则你永远不会完成你的项目（或保住你的工作。）我们都可以永远花费重构代码。

Answer 4

尝试测试驱动开发。提前写好测试。当实现代码通过测试时，您就完成了。即使您对实现不满意，也可以返回并编写另一个实现，然后您将进行测试以确保其正常工作。此时，您可以分析各种解决方案。

Answer 5

如果没有损坏，请不要修理它。您不需要不断重写代码。一旦你按照规范（包括性能要求）工作，就必须权衡重写它的成本，并可能引入新的bug，而不考虑单独使用它的成本。只要确保当你决定完成时，就会有详细记录。

Answer 6

当前的实施是否有效（足够好）？如果是这样的话，那么就把它放到床上并继续处理其他事情 我发现每当我学习一种新的做事方式时，我很想重写大量旧代码来使用这种技术，这将浪费时间。使用您为新项目学到的东西，让旧项目保持平静。

Answer 7

当其他人可以立即阅读时，因为我已经a）评论得很好，并且b）使用“正常”操作来实现我的目标。

我经常想在“工作”时立即离开。但“可读”在“工作”之后更为重要。

Answer 8

正确编码内容的唯一方法只能基于您的要求。您必须确保不会过度设计代码。

只需确保您的代码是可测试的，并根据“更改原因”将复杂性保持在最低水平。如果您主要以电子商务网站为例，您可能希望拥有可扩展的定价解决方案。但是，您不希望系统的其他部分与定价一样具有可扩展性，原因很简单，因为它们几乎没有理由进行更改。税收制度就是一个很好的例子。您可以构建它，以便它只以有效的方式处理美国，如果业务发生变化以便与其他国家打交道，则可以重构代码。

过早编码未使用的东西是编写垃圾的可靠方法，不会被使用。

Answer 9

我真的很想问自己，我刚创建的解决方案是否真的是最佳解决方案。我怀疑这个问题有一个明确的答案。

解决方案的决策应该仅仅基于约束（可用时间，设计，可维护性），因此您可能只需要问自己，手头的解决方案是否满足您的约束条件。

但永远不要停止问自己，因为它是制造更好解决方案的驱动力。

Answer 10

我一直在问自己。但是，一遍又一遍地重新实施同样的事情是没有目的的。如果你认为你做错了，但它有效，接受你的失败并继续前进。你已经学到了一些未来的东西。下一次，下一个项目，你会做得更好（总是，因为你几乎不会以一种可能称之为完美的方式）。再次触摸（坏）代码的唯一原因是

• 其他人试图使用您的代码，但失败了，因为它太可怕了。是时候接管他的工作了（你应该知道代码，你已经编写了代码）并在此过程中尝试修复它，使其更加明显，添加更好的文档，更好的变量/函数/方法命名（“说出名字”），更多评论，等等。

• 它可以工作，但它太慢或占用太多内存。时间来分析它！ CPU时间花在哪里？为什么要使用这么多内存？找到最薄弱的地方并修复它们。

• 事实证明它并没有真正起作用，它在某些条件下或在某些情况下失败，再次是修复代码的时间。

但是，请记住以下说法（改为适合程序员）：“程序员再也不会犯同样的错误，他们总能找到新的！”。我多久说过一次，下次我会做得更好，有时候我有机会（例如需要添加新功能，代码使用起来太可怕了，重写它以便从头开始按照这些新功能工作结果比改变旧的更快了，当然，我从来没有犯同样的错误两次;但是下次再次编写同一段代码时，你会遇到新的问题（虽然更加聪明），旧的问题甚至都没有（因此它有很多其他问题）。达到你可以真正说“我不能做得更好，这是可以做到的最好”的点是我还在等待的经历。我想知道地球上是否存在任何无法在简单性，性能或灵活性方面进一步优化的代码。

大多数程序员不喜欢听到的事实也是“有时候好就足够了”。代码可能不完美，可能有其缺陷。你可能能做得更好......但是编程并不是能够创造最好的代码的竞争，而是让事情变得有效（通常是为了客户），当我告诉我的老板时“嘿，我可以改进这个代码只使用了一半的CPU时间，四分之一的内存并且它将非常灵活，添加新功能将是一个小时而不是几周的问题“，他可能会说”没有客户抱怨它太慢了没有客户曾经抱怨说它使用了太多内存。它现在的工作方式正是我们希望它的工作方式，那么为什么我们要为所有客户所希望的工作添加新功能？“他有一点意见。如果没有产品被允许进入市场，除非你认为它100％无瑕疵，我想大多数商店的货架都会很空。

Answer 11

当然，你不是在问Perl，但我认为这适用于大多数情况下的大多数语言，即使它不是一个明确的设计意图：

  

Perl旨在为您提供多种功能   做任何事情的方法，所以考虑一下   选择最可读的。

     

- perl手册页中的Larry Wall

Answer 12

听起来版本控制如此重要的另一个原因。无论您何时需要改进，都可以根据需要重构和改进代码，但要不断检查并对每个更改进行评论。日志，加上同伴的压力，应该可以帮助你理解你没有明显理由的强迫症，以及你以有意义的方式改进代码库的地方。

Answer 13

最佳：

在今天，明天，下周和明年实现规范，无论您是否在这些时间范围内维护它。

Answer 14

最好！=完美。对于凡人的编码员来说，完美的代码可能是不可能的。编写好的代码以便将来维护。你第一次不会完美。