全文共2135字 ， 预计学习时长7分钟


本文插图

图源：unsplash
贾科莫·卡萨诺瓦说：“不犯错的人一事无成 。 ”没有人能从不犯错 ， 尤其是在软件开发这一“艰难”的领域 。 有的错误严重些 ， 有的错误没有那么大的影响力 。 错误是始终存在的 。
无需为犯错而担忧 ， 事实上 ， 犯错使我们成长 。 以下一些错误是很典型的问题 ， 几乎每个人都经历过 ， 从中吸取经验 ， 在通往优秀开发人员的道路又进一步 。
假如你没有 ， 那么请从别人的错误中学习 。 人生中没有如此多的时间来一一经历所有的错误 。
1. 快速而凌乱
大多数开发人员在职业生涯中都曾用快速而凌乱的方案来解决问题 。 这种方法存在一些严重的缺陷 ， 从而导致更多的技术债务 。 最重要的是 ， 快速而凌乱的解决方案可能会破坏团队的士气 。
也许在某些事例中 ， 快速而凌乱可能无伤大雅 。 如在代码寿命短的某些情况下 ， 这实际上可能是正确的方法 。 但需要长期运行代码时 ， 修复快速又凌乱的工作会反咬你一口 。


本文插图

图源：unsplash
2. 编写过于花哨的代码
尤其对于没有足够经验的开发人员来说 ， 在其编码生涯中都有一段时期 ， 试图寻求其他开发人员的认可 。
不要花太多时间编写最完美的代码 。 按照既定目标编写代码并使其按预期工作 。 这样做会给自己留出很多额外的时间 ， 从而可以创造更多价值 。
3. 在错误的分支中提交代码
该错误列表从一个小错误开始——只要及时发现就不会产生重大影响 。 尽管开发人员可能会浪费大量时间来修复此错误 。
在错误的分支中提交代码 ， 这种事情开发员们做过不止一次 。 如果及时发现 ， 则可以轻松解决问题 。 当开始在错误的分支中提交代码时 ， 事情就变得棘手了 。
4. 低估工作量
“这很简单嘛 。 ”
事实证明事情并没有想象的那么容易 。 尝试的第一个解决方案并未达到预期的效果 。 而最后为了修复第一次未解决的问题采取的另一种方法会花费更多时间 。
低估工作量是一个经常发生的典型错误 。 尤其是当团队使用诸如Scrum之类的敏捷方法时 ， 这种错误常有发生 。


本文插图

图源：unsplash
确保自己不仅要计算开发人员的时间 ， 还需要一些时间来做其他事情 ， 比如测试 。
5. 没有提交正确的文件
笔者经常看到正确的文件没有提交到存储库 。 这里有两种情况：要么提交的文件过多 ， 要么提交的文件出现遗漏 。
有时提交了太多文件 。 笔者已经见过IDE文件最终存储在存储库中无数次了 。 这主要是因为开发人员工作马虎 。 盲目地将所有文件添加到提交中通常并无益处 。
缺少yarn.lock文件是文件在提交中出现遗漏的典型例子 。 在大多数情况下 ， 这与知识缺乏或理解不足有关 。 开发人员不知道文件的用途 ， 因此害怕将其添加到存储库中 。 或者他们可能认为该文件仅适用于其本地环境 。
尽管这种情况取决于丢失的文件 ， 但在大多数情况下 ， 此错误会导致文件破坏 。 如果缺少yarn.lock ， 开发人员将在所有环境中获得不同版本的依赖关系 。 这可能会导致一些令人困扰的错误 。
6. 由于缺乏相关知识而做无用功
大多数开发人员使用某种框架来简化生活 。 如果一个开发人员正在学习框架 ， 可能很难知道框架API中的所有可用内容 。

分页标题
本文插图

图源：unsplash
典型错误是开发人员不知道框架中已有的功能 。 由于缺乏相关知识 ， 开发人员实施了与框架中现有方法几乎相同的新方法 。
这导致时间被浪费在生产框架中已经存在的代码 。 缺乏经验还使开发人员无法充分挖掘框架潜力 。
7. 自认为不需要测试代码
“这段代码很简短 ， 不会影响到任何重要的事情 。 ”
每个开发人员都编写过简短的代码 ， 你以为它们不会破坏任何主要内容 ， 实则不然 ， 添加的两行代码成功打破了无法预料的内容 。
测试代码确实是个不招人喜欢的活儿 。 有些人没有理解测试代码的目的 ， 认为这是浪费时间 ， 常常不切实际 。
怎么才知道自己的代码能正常运行呢？请让一些真实的测试支持自己的话 。 全面的测试可以过滤出关键的错误 ， 从而确保代码按预期方式运行 。
8. 缺乏练习
大家都知道熟能生巧的道理 。 因此 ， 为扩展技能 ， 便需要更多的练习 。 不学习新事物是开发人员可能犯的最大错误之一 。
如果想学习一种新技术或编程语言 ， 开发人员可能不得不在日常工作之外进行学习 。 为了不落伍 ， 这是必须对自己进行的一项投资 。


本文插图

图源：unsplash
9. 过于自信
当然 ， 拥有信心是一件很棒的事情——但只在一定程度上 。 开发人员过于自信时 ， 就很难听得进去别人的意见了 。
过于自信的开发人员完全认识不到自己也会犯错误的事实 ， 因此他们往往在不咨询他人的情况下做出决策 。 这不是最好的做法 。 作为开发人员 ， 对自己能力作出判断 ， 意识到自己所了解的很少 ， 是非常重要的 。
10. 继承一切
继承本身并不是坏事 。 但是 ， 很多人是把以前的东西照单全收 ， 从而导致滥用 。 如果发现自己使用了很多前人的内容 ， 可能已经过度设计了 。
过度设计可能会导致代码的设计过于大众化 ， 以致于忽视了最初设计要执行的主要任务 。 代码因此变得难以使用 ， 而且从根本上来说 ， 这是不明智的 。
正如所言 ， 继承并不总是坏事 ， 只是并非修复问题的第一选择 。


本文插图

图源：unsplash
想要成为出色的开发人员 ， 犯错不是不被允许的 ， 毕竟 ， 人们一直以来做的 ， 就是不断犯错 ， 再不断吸取教训继续前行 。


本文插图

留言点赞关注
我们一起分享AI学习与发展的干货
【教科书级错误：每个开发人员都犯过的典型错误】如转载 ， 请后台留言 ， 遵守转载规范

来源：(精彩趣投稿)

【】网址：/a/2020/0516/1589614451.html

标题：教科书级错误：每个开发人员都犯过的典型错误