本文最初发布于 Medium 网站，经原作者授权由 InfoQ 中文站翻译并分享。
大家很少会看到人们（包括我自己！）公开谈论他们犯过的错误。但我觉得我们最好时不时反思一下自己过去犯过哪些错误，这样我们就不会在未来重蹈覆辙了。
我成为专业程序员已经有大约五年时间了。和其他人一样，我在这条职业道路上也犯过不少错误。一般来说，我不会在犯错的当时就意识到自己做错了什么事情；我往往是在接触了正确的做事方式之后才知道自己之前的路走岔了。希望在阅读这篇文章后，你会从中得到一些有用的东西，这样以后就不要再像我一样犯错——并付出那么多代价了。
1没有使用合适的 ORM
数据访问层代码总是会一团乱麻、无聊和令人生厌。我还记得我第一次做一个简单的内部簿记应用程序时的场面；那时我看到仅仅是为了完成基本的管道就要编写那么多代码，为此震惊不已。所以我开始放弃 ADO.NET，并手工编写一个自制的，带有特别定制的特定表模式的 ORM 来满足我的需求。
几个月后，那个应用程序的业务需求发生了一些变化，这导致表模式也发生了变化，于是我不得不去修改我的 ORM。修改过程非常痛苦，以至于我将它全部扔掉了，换成了一个强类型的数据集适配器。
有一段时间，这东西确实奏效了。但我还是希望自己一开始就能使用合适的 ORM（例如 NHibernate）来完成这项工作。至少当我的用户数量不断增长时，我就用不着再担心改变数据库供应商的事情了。
2没有足够快地学习泛型
我的职业生涯一开始的时候，我是.Net 1.1 版的程序员。.Net 1.1 的问题在于它没有泛型支持。于是乎，我们无法拥有强类型列表，只能凑合着用平淡无奇的 ArrayList。但使用 Arraylist 时，你的代码中会到处都是 casting 和 boxing，所以代码无论是阅读还是编写起来都很痛苦。于是我们使用了 CodeSmith 来生成一个强类型集合列表。但是随着代码库的增长，那些自制的列表本身就变成了一个个怪物。因为我可以很容易地修改代码，所以我会经常介入并改变一个方法的行为以适应我的需求，这又导致了后来的诸多混乱和错误。
我本来应该切换到.Net 2.0，并在它可用时立即开始使用泛型才对，而不是去创建越来越多根本无法维护的自定义集合列表。
3重新发明轮子
新手程序员总是喜欢重新发明轮子：“现有的实现对我来说还不够好，所以我必须从头开始重写整个东西。”我自己也曾经想过编写自己的 UI 控件，因为 Windows Forms UI 控件对我来说太简单了。
众所周知，市面上有很多优秀的.Net UI 控件工具可供使用；当然，我的 GUI 工具并不像那些商业工具那么好用。那时我太天真了。
4太多的文档
代码文档是很好的东西，因为它用简单的人类语言解释了你的代码具体在做什么事情，对吧？
这个观点是错误的。
文档往往是陈旧、过时或完全错误的东西。我曾花了很多时间来给我的代码编写文档（还是 XML 文档，还记得吗？），结果只是发现每当我更改代码时都需要更新文档才行。更新代码是必要的，但更新 XML 文档就不是那回事了：这是一种负担，它只会浪费你的时间，而且毫无意义。到最后，我在更改 XML 文档时失去了耐心，转而去做其他更有意义的事情。
5没有自动构建
应用程序部署和打包工作相对来说比编写代码更容易一些，所以我把这两件事情放在了很低的优先级上。很快，我就收到了所有人的抱怨，他们都说构建无法正常工作。“缺少先决条件，如何解决这个问题？”“dll 没有更新，你能给我发个补丁吗？”“为什么图标都跑掉了？”电话像雪崩一样打到了我的办公桌上。
那一天结束的时候，我已经筋疲力尽了。这不是因为编程太累人，而是因为那些令人麻木的重新部署和重新打包的过程。我本可以通过编写自动化脚本来真正“节约”一些时间，但是我浪费在修复每个错误和支持其他人上的时间比我可以“节约”的时间要多很多倍。你的软件应该支持一键构建；需要的操作再多一点都是浪费时间。
6过分依赖视觉检查和调试
做出一个表格并显示你的输出是非常容易的事情。而且 Visual Studio 是如此强大，以至于人们可以轻松地一步步检查代码并即时检查代码中的值。但是，如果你沉迷在调试器里面，它就会带来害处。想象一下，如果你的方法只在应用程序启动并运行 45 分钟后才会被调用，你是否要等待 45 分钟才能到达这个点上，然后才开始调试呢？
更好的办法是将应用程序分解为一些可以独立调用的子模块。通过这种方式，你可以只关注那些产生错误输出的输入，并从那里开始对其进行测试。
7没有单元测试
我曾认为我的应用程序是如此稀松平常，以至于通过手工测试就能轻松覆盖。我以为单元测试是为了一些大而复杂的事情准备的，而不是我做的那种小型应用程序。这样做的结果是我的应用程序变成了一个怪物（没有关注点分离、难以重构和完全无法维护的代码库）。
曾经有一段时间，我害怕对我的代码进行哪怕是最轻微的修改，因为任何更改都可能会，也可能不会导致破坏性更改。有几次，一个神秘的问题突然冒出来，追究其根本原因却发现是我几个月前引入的一个重大更改。应付这种遗留代码不仅无聊和累人，而且精神上也给人带来很大压力。
但是有了单元测试后，你的开发生活就会得到显著的改善。我希望我能从第一天开始就学习单元测试的艺术，从第一天开始就勤加练习单元测试。可惜学校并不教单元测试。
附送一张软件测试工程师成长图谱
最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!
在我的QQ技术交流群里（技术交流和资源共享，广告勿扰）
可以自助拿走，群号：310357728?群里的免费资料都是笔者十多年测试生涯的精华。还有同行大神一起交流技术哦
如果对你有一点点帮助，各位的「点赞」就是小编创作的最大动力，我们下篇文章见！
?