技术债务严重到我辞职了

当我得到第一份全职开发工作时，我以为一切都会很棒。我以为我会学到各种各样的东西，了解一个真正的开发团队是如何运作的，并且能够构建一些很酷的功能来帮助我们的用户。

天哪，我错了。

你看，我的第一份工作就是一堆技术债。团队给我发工单，希望我能快速了解他们的日常工作。

我会收到一张要求修复错误的票据，然后向同事寻求帮助，为我指明正确的方向。

通常发生的情况是，同事会询问另外几个人，然后我们会发现，如果不破坏其他人的需求，代码可能无法轻易更改，我们只能关闭票证而不能真正解决问题。

我记忆犹新的一个例子是，有一张工单要求做一点小改动。我的同事说：“等等，有人还在用 X 功能吗？我们用我们正在开发的新代码，四行代码就能改写这个功能。”

我心想：“太棒了！我们可以重构这段旧代码，清理掉 400 多行代码脚本，用 4 行代码替换掉它。也许他们在这方面取得了进展！”

没有。

与他聊了几分钟后，结论是，实际上更换 400 条线路风险太大，因为有可能造成破坏。

我非常失望。

不用说，我在那份工作没干多久。巨额的技术债务让我感觉自己作为一名初级开发人员根本无法做出任何贡献。要想在那里取得成功，你必须拥有多年的知识积累才能真正有所成就，即使你想清理一些东西，也会因为害怕破坏某些东西而被打消。

这段经历从此一直萦绕在我的心头。

我从来不想编写无法轻易更改的代码。

技术债务会悄悄地累积起来。你需要勤奋地检查并定期清理代码。

编写代码就像写一篇文章。

你一开始会有一个大致的方向，然后慢慢地开始付诸实践。随着你不断前进，具体细节会越来越清晰。

在学校里，我们被教导永远不要使用初稿。我们应该先写一遍，读一读我们的作品，然后再写第二稿，更好地强调我们的观点。

重构就是这样的。它能帮助你的代码达到第一次无法达到的清晰度。

如果你有很多技术债务，好消息！你不必像我一样辞职。

这项工作之所以如此困难，部分原因在于他们从未正确地重构过代码……或者说，据我所知，他们根本没有重构过。需求存在于人们的头脑中，而不是代码中，也不在测试中。

重构代码是我今天所从事的最有趣的工作之一。

我喜欢编写代码来添加功能，然后重构它，以便它更干净、更简单，并且通常可以比我的原始草稿做更多的事情。

然而，重构说起来容易做起来难。需要花时间学习不同的模式，这些模式可以帮助清理代码，并使未来的开发更容易。

Ben Orenstein 的“重构 Rails”课程是个不错的入门课程。它包含许多实用的重构技巧，你每天都会用到。

只要你牢记这些技巧，它们就能在你每天编写代码时为你提供帮助。这就是重构的伟大之处。