2020 Google开发者大会重磅开幕 了解详情

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

2020 年 5 月 25 日

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


人非圣贤,孰能无过。对于犯错,你不用太困扰,因为对开发者而言,犯错太正常不过,并且几乎每天都会发生。软件开发很难,因此错误或多或少总会发生。犯错可以接受。事实上,及时反思和总结错误才能使我们进一步成长。


下面,我会列举和解释一些常见的错误,希望你能从中汲取经验,以便成为一个优秀的开发者。正如 Eleanor Roosevelt 曾经说过:从别人的错误中吸取教训吧。在有生之年,你不可能把所有的错都犯一遍。


1.在错误的分支中提交代码


我们首先提到这个问题是因为,当错误被及时发现并定位时,不会对我们造成重大影响。虽然我们在修复这个问题的时候会浪费一些时间。


在错误的分支中提交代码估计每个人都体验过一次。如果你及时发现这个错误,则可以很轻松的解决问题,及时止损。否则后续在不断进化的错误分支中修改错误会变得十分棘手——在错误的道路上走的越来越远。


2.追求开发速度,忽视代码质量


在职业生涯中,大多数开发者采取过这种只追求需求响应速度而忽略代码质量的工作方式。这种处理问题的方式存在严重缺陷,它会导致项目背上越来越多的技术债。更重要的是,这种只求速度而忽视代码质量的方式还可能会破坏团队的士气。


然而,在某些情况下,这种开发方式带来的影响并不重要,反而这可能是最优的解决方案。比如对于代码生命周期短的开发,这么做没有什么问题。


但是长远来看,当代码需要长期运行时,这种开发习惯造成的后果可能会“后患无穷”。


3.编写过于花哨的代码


这种情况多发生在那些经验较少的开发人员身上,在他们的职业生涯中,他们想用这些花哨的代码打动其他开发者。


不要在编写花里胡哨的代码上浪费太多时间。而是要有目的的编写代码,并让这些代码按照预期工作。这会给你节省大量时间,让你继续做其他有意义的工作,从而给用户带来更多价值。


4.低估工作量


“我可以很轻松的完成这一特性,小菜一碟。”


然而,事实证明这并没有你想象的那么容易。你尝试的第一个解决方案未达到预期的效果。解决该问题的另一种方法花费了更多时间。


低估工作量是一个经常发生的典型错误。尤其是当团队使用诸如 Scrum 之类的敏捷方法时,你会发现这种错误经常发生。


确保你在预估工时时,除了考虑到开发时间,还要额外留一些时间做其他事情,比如测试。


5.认为你的代码不需要测试


“这段代码太小了,不会对整体代码造成什么影响。”


每个开发人员都贡献了少量代码,没有破坏任何主要内容。但是你添加的两行代码却造成了意料之外的中断。


大多数开发者不喜欢测试他们的代码,一些人不清楚测试意图,只是认为这是在浪费时间。


你怎么知道你的代码可以完美运行而不会出错呢?


请让你的结论得到一些实际测试的支持。全面的测试可以排除关键错误,从而确保代码按预期方式执行。


6.没有提交合理的文件


我经常遇到没有合理地将文件提交到代码仓库的情况。要么是提交的文件太多,要么提交的文件有遗漏。


有时候一次提交的文件太多,这就丢失了通过 IDE 统计的文件在仓库中最终变更的次数。这主要与开发人员的不良代码管理习惯有关。一股脑的将所有文件一次性提交到代码仓库通常是不可取的。


举一个常见例子,比如 yarn.lock 文件遗漏提交。大多数情况下,这与缺乏相应的知识和理解有关。部分开发者可能不知道某些文件存在的作用,因此害怕将其添加到代码仓库。或者简单地认为这些文件只是本地开发环境的配置而已。


尽管这取决于遗漏的是什么样的文件,但大多数情况下这种错误会把你搞得一团糟。如果缺少 yarn.lock 文件,你可能会在项目中使用不同版本的依赖关系。这很有可能导致一些 BUG。


7.重复造轮子


大多数开发者使用某种框架来简化繁杂开发。如果你正在学习某个框架,你可能会忽视其实框架已经给你提供好了所需要的一些 API。


经常发生的一个错误就是开发者不知道自己正在使用的框架所提供的已有功能有哪些。由于缺乏对框架的全面了解,自己可能会重新造一个轮子来实现框架中已有的功能。


重复造轮子而没有使用框架中的已有功能,这非常浪费时间。


8.眼高手低,缺少训练


熟能生巧,每个人都知道这一点。所以为了拓展自己的技能,你需要更多的训练。作为一个开发者,学习新知识浅尝辄止,这是非常忌讳的。


如果你想学一个新技术或者一门新的编程语言,你可能只有在你的工作之余进行了。这是你自己必须进行的一项投资,以便自己跟上当前流行技术,不脱离时代。


如果你认为你可以做一些练习,我之前写了一篇文章,里面例举了很多有意思的项目,你感兴趣的话可以试一下。


9.乱用继承


继承本身没有什么问题。然而,我看到很多开发者常见的错误就是过度使用继承甚至滥用。如果你发现自己在项目中大量使用了继承,则项目极有可能“过度设计”。


过度设计可能导致代码被设计的过于通用,以至于忽视了最初设计的初衷。因此,代码会变得异常难用。


正如我所说的,继承并不总是不好的。但它不是你修复问题时的第一选择。


10.过于自信


许多开发者过于自信。当然,在一定程度上,拥有自信是一件很棒的事情。作为一名开发者,当你过度自信时,你很难获得从他人那里获得良好的反馈。


过于自信的开发者完全意识不到自己也会犯错误的事实,因此他们倾向于在不咨询他人的情况下做出决策。这不是最好的办法,因为在某些情况下出现一些问题,让你措手不及 – 比如你确实选择了一个非最优的方案,甚至其他开发者觉得自己被忽视和贬低了。


作为一个开发者,保持谦虚,清晰得意识到自己能力所及是非常难得的。


总结


既然我们已经过了一遍上面所述的每一个开发者可能会犯的错误,那么花一两分钟从中学习来避免自己犯错是非常明智的。


在你走向优秀的开发者的道路上,你必须记住,犯错是可以的。人非圣贤,孰能无过。知错能改,善莫大焉。


英文原文:


Classic Mistakes That Every Developer Has Made


2020 年 5 月 25 日 10:16 7118

评论 1 条评论

发布
用户头像
这个题图有那么一点吓人哦~
2020 年 06 月 01 日 15:33
回复
没有更多评论了
发现更多内容

我常用的在线工具清单

彭宏豪95

效率 效率工具 工具

交易上链——中心化数字资产交易所的完美解决之道

MaxHu

区块链 智能合约 数字货币 去中心化网络 数字资产

认识数据产品经理(三 成为数据产品经理)

马踏飞机747

大数据 数据中台 数据分析 产品经理 数据产品经理

原创 | 使用JUnit、AssertJ和Mockito编写单元测试和实践TDD (四)关于单元测试的常见错误观念和做法

编程道与术

编程 软件测试 TDD 单元测试 Java、

原创 | 使用JUnit、AssertJ和Mockito编写单元测试和实践TDD (五)第一个单元测试

编程道与术

编程 软件测试 TDD 单元测试 Java、

编程的门槛 - 抄作业的得与失

顿晓

编程门槛 编程思维 动手能力 抄作业

使用jdbcSstoragerHandler 处理mysql、oracle 、hive数据

杨飞

工作两年简历写成这样,谁要你呀!

小傅哥

面试 小傅哥 Java 面试 简历优化 找工作

智浪

Neil

后浪 智能时代 智浪

借助第一性原理开启中台建设

数字圣杯

数据中台 数字化转型

编写制度的几点实用建议

石君

制度 编写制度 安全管理

通过一个聊天应用学习 Deno

寇云

typescript 后端

基于XGB单机训练VS基于SPARK并行预测(XGBoost4j-spark无痛人流解决方案)

黄崇远@数据虫巢

机器学习 算法

业务信息化操作系统(BIOS)——中台的核心产出物

孤岛旭日

中台 操作系统 企业信息化

从波音747学项目管理

顾强

项目管理 读书感悟 沟通

前浪的经验:区块链软件,一定也要去中心化

Michael Yuan

比特币 区块链 智能合约 以太坊 加密货币

爱是恒久忍耐,又有恩慈

泰稳@极客邦科技

身心健康 心理

高效阅读,成就自我-《麦肯锡精英高效阅读法》读后感

顾强

读书笔记 读书 读书方式

《硅谷革命:成就苹果公司的疯狂往事》读后感

顾强

高仿瑞幸小程序 08 创建第一个云函数

曾伟@喵先森

小程序 微信小程序 前端 移动

一杯茶的时间,上手 React 框架开发

图雀社区

Reac

Dubbo集成Sentinel实现限流

Java收录阁

sentinel

21天养不成习惯,28天也不行。不要痴心妄想。

赵新龙

TGO鲲鹏会 习惯养成

Spring 中不同依赖注入方式的对比与剖析

Deecyn

spring

“字节”不断“跳动”,卡拉永远 OK?

无量靠谱

字节跳动 诺基亚 危机

回“疫”录(15):在家SOHO,是你想要的工作方式吗?

小天同学

疫情 回忆录 现实纪录 纪实 远程办公

有了容器为什么kubernetes还需要Pod?

架构师修行之路

Kubernetes 分布式 云原生 pod

算法工程师的发展路径

Lucien

你竞争我得利之零售变革

孙苏勇

行业分析

反对996,但是选择996是一个怎样的矛盾心态?

顾强

职场 加班

面向页面的移动端架构设计

稻子

flutter ios android 前端架构 架构模式

2020中国技术力量年度榜单盛典

2020中国技术力量年度榜单盛典

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