我在软件工程师生涯中犯下的七大错误

本文最初发布于 Medium 网站,经原作者授权由 InfoQ 中文站翻译并分享。

大家很少会看到人们(包括我自己!)公开谈论他们犯过的错误。但我觉得我们最好时不时反思一下自己过去犯过哪些错误,这样我们就不会在未来重蹈覆辙了。

我成为专业程序员已经有大约五年时间了。和其他人一样,我在这条职业道路上也犯过不少错误。一般来说,我不会在犯错的当时就意识到自己做错了什么事情;我往往是在接触了正确的做事方式之后才知道自己之前的路走岔了。希望在阅读这篇文章后,你会从中得到一些有用的东西,这样以后就不要再像我一样犯错——并付出那么多代价了。

一、没有使用合适的 ORM

数据访问层代码总是会一团乱麻、无聊和令人生厌。我还记得我第一次做一个简单的内部簿记应用程序时的场面;那时我看到仅仅是为了完成基本的管道就要编写那么多代码,为此震惊不已。所以我开始放弃 ADO.NET,并手工编写一个自制的,带有特别定制的特定表模式的 ORM 来满足我的需求。

几个月后,那个应用程序的业务需求发生了一些变化,这导致表模式也发生了变化,于是我不得不去修改我的 ORM。修改过程非常痛苦,以至于我将它全部扔掉了,换成了一个强类型的数据集适配器。

有一段时间,这东西确实奏效了。但我还是希望自己一开始就能使用合适的 ORM(例如 NHibernate)来完成这项工作。至少当我的用户数量不断增长时,我就用不着再担心改变数据库供应商的事情了。

二、没有足够快地学习泛型

我的职业生涯一开始的时候,我是.Net 1.1 版的程序员。.Net 1.1 的问题在于它没有泛型支持。于是乎,我们无法拥有强类型列表,只能凑合着用平淡无奇的 ArrayList。但使用 Arraylist 时,你的代码中会到处都是 casting 和 boxing,所以代码无论是阅读还是编写起来都很痛苦。于是我们使用了 CodeSmith 来生成一个强类型集合列表。但是随着代码库的增长,那些自制的列表本身就变成了一个个怪物。因为我可以很容易地修改代码,所以我会经常介入并改变一个方法的行为以适应我的需求,这又导致了后来的诸多混乱和错误。

我本来应该切换到.Net 2.0,并在它可用时立即开始使用泛型才对,而不是去创建越来越多根本无法维护的自定义集合列表。

三、重新发明轮子

新手程序员总是喜欢重新发明轮子:“现有的实现对我来说还不够好,所以我必须从头开始重写整个东西。”我自己也曾经想过编写自己的 UI 控件,因为 Windows Forms UI 控件对我来说太简单了。

众所周知,市面上有很多优秀的.Net UI 控件工具可供使用;当然,我的 GUI 工具并不像那些商业工具那么好用。那时我太天真了。

四、太多的文档

代码文档是很好的东西,因为它用简单的人类语言解释了你的代码具体在做什么事情,对吧?

这个观点是错误的。

文档往往是陈旧、过时或完全错误的东西。我曾花了很多时间来给我的代码编写文档(还是 XML 文档,还记得吗?),结果只是发现每当我更改代码时都需要更新文档才行。更新代码是必要的,但更新 XML 文档就不是那回事了:这是一种负担,它只会浪费你的时间,而且毫无意义。到最后,我在更改 XML 文档时失去了耐心,转而去做其他更有意义的事情。

五、没有自动构建

应用程序部署和打包工作相对来说比编写代码更容易一些,所以我把这两件事情放在了很低的优先级上。很快,我就收到了所有人的抱怨,他们都说构建无法正常工作。“缺少先决条件,如何解决这个问题?”“dll 没有更新,你能给我发个补丁吗?”“为什么图标都跑掉了?”电话像雪崩一样打到了我的办公桌上。

那一天结束的时候,我已经筋疲力尽了。这不是因为编程太累人,而是因为那些令人麻木的重新部署和重新打包的过程。我本可以通过编写自动化脚本来真正“节约”一些时间,但是我浪费在修复每个错误和支持其他人上的时间比我可以“节约”的时间要多很多倍。你的软件应该支持一键构建;需要的操作再多一点都是浪费时间。

六、过分依赖视觉检查和调试

做出一个表格并显示你的输出是非常容易的事情。而且 Visual Studio 是如此强大,以至于人们可以轻松地一步步检查代码并即时检查代码中的值。但是,如果你沉迷在调试器里面,它就会带来害处。想象一下,如果你的方法只在应用程序启动并运行 45 分钟后才会被调用,你是否要等待 45 分钟才能到达这个点上,然后才开始调试呢?

更好的办法是将应用程序分解为一些可以独立调用的子模块。通过这种方式,你可以只关注那些产生错误输出的输入,并从那里开始对其进行测试。

七、没有单元测试

我曾认为我的应用程序是如此稀松平常,以至于通过手工测试就能轻松覆盖。我以为单元测试是为了一些大而复杂的事情准备的,而不是我做的那种小型应用程序。这样做的结果是我的应用程序变成了一个怪物(没有关注点分离、难以重构和完全无法维护的代码库)。

曾经有一段时间,我害怕对我的代码进行哪怕是最轻微的修改,因为任何更改都可能会,也可能不会导致破坏性更改。有几次,一个神秘的问题突然冒出来,追究其根本原因却发现是我几个月前引入的一个重大更改。应付这种遗留代码不仅无聊和累人,而且精神上也给人带来很大压力。

但是有了单元测试后,你的开发生活就会得到显著的改善。我希望我能从第一天开始就学习单元测试的艺术,从第一天开始就勤加练习单元测试。可惜学校并不教单元测试。

原文链接:

https://betterprogramming.pub/7-big-mistakes-i-have-made-in-my-career-as-a-software-engineer-f14ef540be10

本文文字及图片出自 InfoQ

本文文字及图片出自

余下全文(1/3)
分享这篇文章:

请关注我们:

共有 8 条讨论

  1. admin  这篇文章, 并对这篇文章的反应是'+(41020*44643)+'
  2. admin  这篇文章
  3. admin  这篇文章
  4. admin  这篇文章
  5. admin  这篇文章
  6. admin  这篇文章
  7. admin  这篇文章
  8. admin  这篇文章

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注