在成为优秀开发者的道路上，无法避免一定会犯一些错误，这篇文章例举了 15 个开发者的常见错误，希望能帮助我们在工作中识别出来、吸取教训并避免再犯同样的错误。原文：How to Avoid Common Developer Mistakes?^[1]

Photo by Christina@wocintechchat.com on Unsplash

人人都会犯错。也许你会在各种帖子或励志图片中看到这句话。作为开发人员/程序员是一项很有挑战的工作，所以也一定会犯错。我们都会犯错，犯错本身没有关系，错误会帮助我们成长。也许你很厉害，下面列表里的错误你都没有犯过，不过更大的可能是你也曾经犯过这个列表上的一些错误，我们希望能够从其他开发者所犯的错误中吸取教训，避免自己犯同样的错误。

让我们从开发者一生中所犯的 15 个最大的错误开始。

1. 追求速度，用丑陋的代码修复问题（Quick & Dirty Code Fixes）

不得不承认，这是我们作为开发者都犯过的错误。Quick and Dirty 解决方案的问题在于降低了代码库的质量，可能会引入不必要的技术债务。随着时间的推移，你会后悔快速却丑陋的补救措施。最终，你可能会发现自己不得不重构这些快速却丑陋的解决方案，而这会大大降低团队的士气。

2. 注释掉整块代码（Commenting Out Blocks of Code）

我们通常会看到包含多个函数的一大块代码被注释掉了，但却没有解释为什么代码块还保留在那里，或者代码是否还有用。有些人不想删除这段代码，因为他们认为其他人可能还需要它。总之，如果看到注释掉的代码块，那就把它删了吧，如果发现有人需要这段代码，可以从版本控制系统中将它恢复出来。

3. 缺乏实践（Lack of Practice）

众所周知，熟能生巧。想成为一个更好的开发者，就需要更多的练习。你可能犯的最大的错误之一就是没有学到任何新东西。例如，你需要从日常工作中抽出时间来学习一门新的编程语言。你必须对自己进行投资，保持与时俱进。

4. 只测试常规场景（Testing Only the Happy-Path Scenario）

在编写测试时，考虑异常场景比测试常规场景要更重要。想象一下事情不像预期那样发展的场景，情况会变得多糟糕？我们应该尽量测试这些场景。

5. 低估工作量（Underestimating the Workload）

作为软件开发人员，估计工作量是最具挑战性的任务之一。在 Scrum 需求梳理会议上听到“我可以很容易的在一个故事点中完成这个特性”的情况并不少见。最有可能的是，问题不会像看上去那么简单。在进行评估时，要确保估计的时间包括了测试等其他工作，而不仅仅开发工作。

Photo by Ales Krivec on Unsplash

6. 不提供任何信息的注释（Writing Obvious Comments）

这不是我们第一次听说这样的注释，这些注释不解释任何东西，只关注代码的功能（例如，当存在 foreach 循环时，像“循环遍历产品”这样的注释)。注释不需要关注代码正在做什么，而应该关注这段代码的原因。

7. 因缺乏足够的知识而重复造轮子（Reinventing the Wheel as a Lack of Knowledge）

当开发者不知道框架中已经内置了什么时，就会发生这种错误，他们实现了新功能，但几乎与框架中已有的功能一模一样。

8. 混乱的代码格式（Messy Code Formatting）

大多数缺乏经验的开发者都会犯这样的错误。如果代码格式不正确，代码就会变得难以阅读，并且会让其他开发者感到沮丧。通过安装格式化代码的 linter，可以修复混乱的代码。

9. 在代码中用 magic number（Having magic numbers in your code）

Magic number 是含义不明确或重复出现的数字，必须用命名常量替换。Magic number 不可读，不能为开发者提供上下文。此外，magic number 在程序中可能被多次使用，这样很容易出错。

10. 没有自动化测试（Not Writing Automated Tests）

当你开始编写自动化测试时，将不得不比编写手动测试投入更多的时间。最终，你会感谢自己花时间编写这些自动化测试。手工测试枯燥、耗时，而且更容易由于人为因素而产生错误。

11. 日志中没有记录任何相关信息（Not Logging Any Relevant Information）

有用的日志让开发者受益匪浅。日志可以帮助区分代码中错误发生的位置，并使调试更加容易，好的日志包含了当某个错误发生时用户正在做什么的上下文信息。

12. 过度设计（Over-Engineering）

大多数开发者实现某种设计模式只是因为好玩，即使我们发现可以应用某种设计模式，也不代表一定要在代码里实现，因为很有可能只是在代码库中增加了一点技术债而已。

13. 单个函数功能过多（An Overburdened Function）

不要让函数一次做很多事情。避免让函数获取、处理和输出数据，将这些职责划分为不同的功能。创建三个函数：一个用于获取，一个用于处理，一个用于输出数据。将功能集中于一个关注点可以使其更加健壮。

14. 差劲的提交信息（The Art of Writing Bad Commit Messages）

大多数人可能都犯过这个错误。“修复了一个 bug”或“正在进行中的工作”都不是很好的提交信息。提交信息非常重要，值得花上一些时间编写。一个好的提交信息需要解释“发生了什么变化”以及“为什么发生了变化”。包含提交信息的修订历史是一种很好的资源，可以在出现问题时快速定位出问题所在。

15. 只知编码，不知解决方案（Coding Without Knowing the Solution）

一上来就编码，你可能会觉得很兴奋，但你以后一定会后悔的。编码包括规划和组织代码。在开始编码之前，应该有一个计划，计划一下在路上可能会遇到的问题，以及能做些什么来解决它们。因此，你需要注意到在编写代码之前还有很多事情需要考虑。

结论

这次就到此为止吧！我们已经讨论了每个开发人员可能都会犯的经典错误，值得我们花点时间检查这些错误。

永远记住，在成为一个更好的开发者的道路上，犯错是很自然的，不断把手弄脏，不断犯错误，从错误中学习成长。

References:

[1] https://medium.com/quick-code/how-to-avoid-common-developer-mistakes-3c0538e47bca