@ProX
2020-05-25T11:26:08.000000Z
字数 2691
阅读 273
本文介绍了开发者在职业生涯中可能会犯的一些经典错误，希望每位开发者可以从中汲取经验，Happy Coding！
人非圣贤，孰能无过。犯错这件事不应该让你感到太多困扰，因为对于每个开发人员而言犯错太正常不过了，而且几乎每天都会发生在我们身上。
软件开发非常困难，因此错误总是会发生。犯错不是完全不能被接受的。事实上，及时反思和总结错误才能使我们成长。
下面我会列举和解释常见错误清单，希望你可以从中汲取经验，以便成为一个优秀的开发者。正如Eleanor Roosevelt曾经说过：从别人的错误中吸取教训吧。在你的有生之年，不可能自己把所有的错都犯一遍。
One who makes no mistakes makes nothing at all
不犯错者一事无成。
— Giacomo Casanova
我们首先提到这个问题是因为，当错误被及时发现并定位的时候，不会对我们造成重大的影响。虽然我们在修复这个问题的时候会浪费一些时间。
在错误的分支中提交代码估计每个人都体验过一次。如果你及时发现这个错误，则可以很轻松的解决问题，及时止损。否则后续在不断进化的错误分支中修改错误会变得十分棘手。
大多数开发者在其职业生涯中采取过这种只追求需求响应速度而忽略代码质量的工作方式。这种处理问题的方式存在严重缺陷，从而导致项目积累越来越多的技术负债。更重要的是，这种只追求速度而忽视代码质量的这种方式还可能会破坏团队的士气。
然而，在某些情况下，这种开发方式带来的影响并不重要，反而这可能是最优的解决方案。比如对于代码寿命短的开发，这么做没有什么问题。
但是长远来看，当代码需要长期运行时，这种开发习惯造成的后果可能会好好给你上一课。
这种情况多发生在那些经验较少的开发人员身上，在他们的职业生涯中，他们想用这些花哨的代码打动其他开发者。
不要在编写花里胡哨的代码上浪费太多时间。而是要有目的的编写代码，并使这些代码按照预期工作。这会给你节省大量的时间，让你继续其他有意义的工作，从而给你的用户带来更多的价值。
“我可以很轻松的完成这一特性，小菜一碟。”
好吧，事实证明那并没有你想象的那么容易。你尝试的第一个解决方案未达到预期的效果。解决该问题的另一种方法花费了更多时间。
低估工作量是一个经常发生的典型错误。尤其是当团队使用诸如Scrum之类的敏捷方法时，你会发现这种错误经常发生。
确保你在预估工时时，除了考虑到开发时间，还要额外留一些时间做其他事情，比如测试。
“这段代码太小了，不会对整体代码造成什么影响。”
每个开发人员都贡献了少量的代码，没有破坏任何主要内容。但是你添加的两行代码成功造成了你意料之外的中断。
大多数开发者不喜欢测试他们的代码，一些人不清楚测试的意图，只是认为这是在浪费时间。
你怎么知道你的代码可以完美的运行而不会出错误呢？
请让你的结论得到一些实际测试的支持。全面的测试可以过滤出关键的错误，从而确保代码按预期的方式执行。
我经常遇到没有合理地将文件提交到代码仓库的情况。要么是提交的文件过于多了，要么提交的文件有些遗漏。
有时候一次提交的文件太多了。这样就丢失了通过IDE统计的文件在仓库中最终变更的次数。这主要与开发人员的不良代码管理习惯有关。一股脑的将所有文件一次提交到代码仓库通常是不可取的。
我再举一个常见的比如yarn.lock文件遗漏提交的例子。大多数情况下这与缺乏相应的知识和理解有关。部分开发者可能不知道某些文件存在的作用，因此害怕将其添加到代码仓库。或者简单地认为这些文件只是本地开发环境的配置而已。
尽管这取决于遗漏的是什么样的文件，但大多数情况下这种错误把你搞得一团糟。如果缺少yarn.lock文件，你可能会在你的项目中使用不同版本的依赖关系。这很有可能导致一些恶心的BUG。
大多数开发者使用某种框架来简化繁杂的开发。如果你正在学习某个框架，你可能会忽视其实框架已经给你提供好了你所需要的一些API。
经常发生的一个错误就是开发者不知道自己正在使用的框架所提供的已有功能有哪些。由于缺乏框架这方面的了解，自己可能会造重新一个轮子来实现框架中已有的功能。
重新造轮子而没有使用框架中已有的功能，非常的浪费时间。对框架的使用经验不足会使你无法充分利用框架已有的功能。
熟能生巧，每个人都知道这一点。所以为了拓展自己的技能，你需要更多的训练。作为一个开发者，学习新知识浅尝辄止，是非常忌讳的。
如果你想学一个新技术或者一门新的编程语言，你可能只有在你的工作之余进行了。这是你自己必须进行的一项投资，以便自己跟上当前流行技术，不脱离时代。
如果你认为你可以做一些练习，我之前写了一篇文章，里面例举了很多有意思的项目，你感兴趣的话可以试一下。
继承本身没有什么问题。然而，我看到很多开发者常见的错误就是过度使用继承甚至滥用。如果你发现自己在项目中大量使用了继承，则项目极有可能“过度设计”了。
过度设计可能导致代码被设计的过于通用，以至于忽视了最初设计的初衷。因此，代码不仅变得异常难用，而且本质上有点愚蠢。
正如我所说的，继承并不总是不好的。但它不是你修复问题时的第一选择。
许多开发者过于自信。当然，在一定程度上，拥有自信是一件很棒的事情。作为一名开发者，当你过度自信的时候，你很难获得从他人那里获得反馈的好处。
过于自信的开发者完全意识不到自己也会犯错误的事实，因此他们倾向于在不咨询他人的情况下做出决策。这不是最好的办法，因为在某些情况下出现一些问题，打你一个措手不及--比如你确实选择了一个非最优的方案，甚至其他开发者觉得自己被忽视和贬低了。
作为一个开发者，保持谦虚，清晰得意识到自己能力所及是非常难得的。
既然我们已经过了一遍上面所述的每一个开发者可能会犯的错误，那么花一两分钟从中学习来避免自己犯错是非常明智的。
在你走向优秀的开发者的道路上，你必须记住，犯错是可以的。人非圣贤，孰能无过。知错能改，善莫大焉。
感谢阅读，编码愉快！
Daan
Backend developer from The Netherlands. Crypto enthusiast.
https://levelup.gitconnected.com/classic-mistakes-that-every-developer-has-made-b0ed0bc5e087
InfoQ