是否似曾相识?每个开发人员都犯过的十五个错误

全文共 1713 字,预计学习时长 5 分钟

图源:Google

犯错是人之常情,也是促进我们成长的关键,不必惧怕犯错。请试着从他人的错误中学习借鉴,以免今后重蹈覆辙。

·        在长寿命的代码中使用快速粗糙的修复程序。快速粗糙的解决方案会破坏代码库的质量,很可能增加不必要的技术负担。长远来看,这样的方案会造成反噬。最后很可能需要重构。

·        缺乏实践。熟能生巧,要想成为一名开发人员需要更多的实操。最大错误是忘记时不时得学习新事物。如果想学习编程语言之类的新知识,大概率需要利用业余时间。

·        低估工作量。估测工作量是软件开发的一大难事。在Scrum疏理时经常有人说“这小功能一个故事点就能搞完”。但任务可能并不简单,预期方案也不起作用。所以在估测时记得计入测试时间,这点不仅适用于开发人员。

·        写显而易见的注释。我们都曾看过这样的注释:什么也没解释,只专注于代码的功能(例如,foreach循环的注释写着“产品遍历循环”)。当写注释时,不要只关注代码是做什么的,要关注此代码的创建原因。

·        注释掉代码块。代码块中多个功能被注释掉的情况比较常见。没有人知道代码块仍然存在的原因或是否有用。没有人删除是因为每个人都认为其他人可能需要它,大胆删除注释掉的代码块。如果代码仍然有用,可在版本控制中找到。

图源:unsplash

·        仅测试基本逻辑方案。在编写测试时不要只考虑基本逻辑,也要思考预期之外的情况,记得测试最坏的情况。

·        代码格式凌乱。这是经验不足的开发人员最常犯的错误。它使代码更难阅读,也会给其他需要阅读代码的开发人员带来困扰。通过安装格式化代码的linter可以修复凌乱的代码。

·        不记录任何相关信息。有用的日志可以为开发人员提供极大的帮助。日志消息可以帮助洞悉代码的问题所在,并节省大量调试时间。发生特定错误时,好的日志消息会提供有关用户正在执行的操作信息。

·        由于缺乏认知而重新开发wheel。当开发人员不知道框架中有哪些功能时,就会发生此错误。由于缺乏认知,开发人员实施的新方法会与框架中已有的几乎相同。

·        在没有解决方案的情况下开始编码。刚开始可能令人兴奋,但最终会反噬回来。计划和组织代码是编码的重要组成部分。不要不做计划就开始编码,编写代码之前,有很多事情要考虑。

·        不好的提交说明。很多人都有过这样的经历。“修复错误”或“ WIP”都不是很好的提交说明。好的提交说明很重要,应该多花一些时间将它写好。好的提交说明可提供内容更改和更改原因的有用信息。出现问题时,修订历史记录是快速找出病症所在的重要资源。

·        代码中包含魔数。魔数是特定值,它具有无法解释的含义,出现多次,可以并且应该以命名常量替换。魔数不可读,并且不为开发人员提供任何信息。最重要的是,魔数经常多次用于程序中的不同位置,很容易产生错误。

图源:unsplash

·        一个功能中要素太多。试着让功能做好一件事。不要让这个功能同时获取、处理和输出数据。将所有这些职责划分为不同的职能。一个用于获取,一个用于处理,另一个用于输出数据。功能专注于单项是使它更强大的关键。

·        不编写自动化测试。起初编写自动化测试会比手动测试花费更多时间。长远来看,多花时间编写这些自动化测试是值得的。手动测试所有内容无聊又耗时,并且人为因素更容易出错。

·        不必要的复杂化。大多开发人员都有过为了实施特定设计模型而实施的行为。仅仅因为有机会实施某种设计模式不意味着就应该这样做,这样做只会增加代码库的技术负担。

这些错误你犯过么?有则改之,无则加勉,这些坑要注意起来啦。

推荐阅读专题

留言点赞发个朋友圈

我们一起分享AI学习与发展的干货

编译组:岳馨妍、王雁楠

相关链接:

https://medium.com/better-programming/15-mistakes-every-developer-has-made-in-their-life-7b7ef03cc84c

如转载,请后台留言,遵守转载规范

推荐文章阅读

读芯术
我还没有学会写个人说明!
上一篇

shell脚本如何判断两个整数数大小,且判断输入的是不是一个整数

你也可能喜欢

评论已经被关闭。

插入图片