请修改这段程序，立刻！

     <p>本文是从 <a href="/misc/goto?guid=4958319132167192786" target="_blank">Fix That Code Immediately!</a> 这篇文章翻译而来。</p>    <hr />    <p>你们正在开发一个新项目，你在一个地方看到一段有问题的代码。错误的处理方式是，“啊，别人写的，我最好别碰它”，“我没有时间去改它——我有自己的事要做”，“如果我修改它，肯定会改出问题”。</p>    <p>问题是——有问题的代码会越积越多。即使是很小的一段程序，经过一段时间的累计，你很快就能看到它成为一个“由一些菜鸟写的、没人愿意去维护的 巨大的历史遗留项目”。有人曾说，超过6个月的项目全是“历史遗留”项目，因为里面都会积累大量的有问题的代码，或用另外一个词——技术债务。</p>    <p>这就是为什么你要马上修改它们的原因。当你看到一些有问题的代码，或一些不是好的写法的东西——改掉它。立即。否则，当你再次注意到它时就已经 太晚了，因为其它的代码就开始依赖它，新的代码会模仿这种编写风格(也许是拷贝/粘贴而来)，修改这些东西将会变成你的噩梦。让我们把上面错误的做法纠 正：</p>    <ul>     <li>“啊，别人写的代码，我最好别动它”——什么？你的项目团队的一员，你有“权力”去修改它。如果有人把代码写的很糟糕，他可能并没有意识到自己的代码很烂——所以，他们不会改正它。不要认为改正这些代码会冒犯他们。他们也许会没面子，但不是因为你。</li>     <li>“我没有时间去修改它——我有自己的事要做”——这<em>就是</em>你的事。你可以在你的缺陷跟踪里添加上一条任务，写上“重构X”，写上花费的时间。你也可以把它推迟到下一个sprint(如果是敏捷开发)。管理层坚持认为开发新东西比修改旧程序重要吗？告诉他们去读读<a href="/misc/goto?guid=4958319132952981129" target="_blank">《重构》</a>这本书或Spolsky的文章..或本文。(也许不管用，但不妨试一试)</li>     <li>“如果我修改它，肯定会改出问题”——也许。但是，等一下，你们有单元测试用例，不是吗？还有集成测试，确认测试。如果没有——先把这些补齐了。这样你就不用担心把程序改坏了。</li>    </ul>    <p>代码审查是避免这样的代码很重要的方法。如果提交的代码都经过了代码审查，未被察觉的有问题的代码会大幅度的减少。仍然会有，但会少的多。</p>    <p>对于这样的做法唯一的问题是——如何确定一段代码是有问题、需要改进的？这就需要经验了，需要你熟悉好的开发方法和模式。对这个问题我不能给出一个秘诀。但你需要在团队里有一群能明辨是非的程序员。如果没有——读一读<a href="/misc/goto?guid=4958319133733547684" target="_blank">《代码大全(Code Complete)》</a>(以及《<a href="/misc/goto?guid=4958319134525449121" target="_blank">Effective Java</a>》，如果你们使用的语言是Java。)</p>    <p>所以——请马上修改。这会省下你的时间，免去你的头疼，让你对这个项目更有自豪感，而不是“这烂项目是一些菜鸟写的，我只是做了一些辅助的工作。”你不能这样说——如果项目很烂，你难辞其咎。</p> 本文转载自: 外刊IT评论    <a href="/misc/goto?guid=4958183272158702965" rel="nofollow" target="_blank">http://www.aqee.net/</a>