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

8 条评论 | | 2021-08-06

本文最初发布于 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 分钟才能到达这个点上，然后才开始调试呢？

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