每个程序员都曾犯过的经典错误


每个程序员都曾犯过的经典错误

文章插图
 
人非圣贤,孰能无过 。对于犯错,你不用太困扰,因为对开发者而言,犯错太正常不过,并且几乎每天都会发生 。软件开发很难,因此错误或多或少总会发生 。犯错可以接受 。事实上,及时反思和总结错误才能使我们进一步成长 。
下面,我会列举和解释一些常见的错误,希望你能从中汲取经验,以便成为一个优秀的开发者 。正如 Eleanor Roosevelt 曾经说过:从别人的错误中吸取教训吧 。在有生之年,你不可能把所有的错都犯一遍 。
1. 在错误的分支中提交代码我们首先提到这个问题是因为,当错误被及时发现并定位时,不会对我们造成重大影响 。虽然我们在修复这个问题的时候会浪费一些时间 。
在错误的分支中提交代码估计每个人都体验过一次 。如果你及时发现这个错误,则可以很轻松的解决问题,及时止损 。否则后续在不断进化的错误分支中修改错误会变得十分棘手——在错误的道路上走的越来越远 。
2. 追求开发速度,忽视代码质量在职业生涯中,大多数开发者采取过这种只追求需求响应速度而忽略代码质量的工作方式 。这种处理问题的方式存在严重缺陷,它会导致项目背上越来越多的技术债 。更重要的是,这种只求速度而忽视代码质量的方式还可能会破坏团队的士气 。
然而,在某些情况下,这种开发方式带来的影响并不重要,反而这可能是最优的解决方案 。比如对于代码生命周期短的开发,这么做没有什么问题 。
但是长远来看,当代码需要长期运行时,这种开发习惯造成的后果可能会“后患无穷” 。
3. 编写过于花哨的代码这种情况多发生在那些经验较少的开发人员身上,在他们的职业生涯中,他们想用这些花哨的代码打动其他开发者 。
不要在编写花里胡哨的代码上浪费太多时间 。而是要有目的的编写代码,并让这些代码按照预期工作 。这会给你节省大量时间,让你继续做其他有意义的工作,从而给用户带来更多价值 。
4. 低估工作量【每个程序员都曾犯过的经典错误】“我可以很轻松的完成这一特性,小菜一碟 。”
然而,事实证明这并没有你想象的那么容易 。你尝试的第一个解决方案未达到预期的效果 。解决该问题的另一种方法花费了更多时间 。
低估工作量是一个经常发生的典型错误 。尤其是当团队使用诸如 Scrum 之类的敏捷方法时,你会发现这种错误经常发生 。
确保你在预估工时时,除了考虑到开发时间,还要额外留一些时间做其他事情,比如测试 。
5. 认为你的代码不需要测试“这段代码太小了,不会对整体代码造成什么影响 。”
每个开发人员都贡献了少量代码,没有破坏任何主要内容 。但是你添加的两行代码却造成了意料之外的中断 。
大多数开发者不喜欢测试他们的代码,一些人不清楚测试意图,只是认为这是在浪费时间 。
你怎么知道你的代码可以完美运行而不会出错呢?
请让你的结论得到一些实际测试的支持 。全面的测试可以排除关键错误,从而确保代码按预期方式执行 。
6. 没有提交合理的文件我经常遇到没有合理地将文件提交到代码仓库的情况 。要么是提交的文件太多,要么提交的文件有遗漏 。
有时候一次提交的文件太多,这就丢失了通过 IDE 统计的文件在仓库中最终变更的次数 。这主要与开发人员的不良代码管理习惯有关 。一股脑的将所有文件一次性提交到代码仓库通常是不可取的 。
举一个常见例子,比如 yarn.lock 文件遗漏提交 。大多数情况下,这与缺乏相应的知识和理解有关 。部分开发者可能不知道某些文件存在的作用,因此害怕将其添加到代码仓库 。或者简单地认为这些文件只是本地开发环境的配置而已 。
尽管这取决于遗漏的是什么样的文件,但大多数情况下这种错误会把你搞得一团糟 。如果缺少 yarn.lock 文件,你可能会在项目中使用不同版本的依赖关系 。这很有可能导致一些 BUG 。
7. 重复造轮子大多数开发者使用某种框架来简化繁杂开发 。如果你正在学习某个框架,你可能会忽视其实框架已经给你提供好了所需要的一些 API 。
经常发生的一个错误就是开发者不知道自己正在使用的框架所提供的已有功能有哪些 。由于缺乏对框架的全面了解,自己可能会重新造一个轮子来实现框架中已有的功能 。
重复造轮子而没有使用框架中的已有功能,这非常浪费时间 。


推荐阅读