稳定的系统与更好的设计

如果适用,编写一个单元测试(或多个单元测试,以覆盖边缘情况)。这使您有信心重构并知道您没有破坏任何东西。

当然,如果代码是紧密耦合的(或意大利面!)那将是个问题。

如果它没坏,就别修了-包起来。尽可能多地隔离模块,而不更改其实现;当/如果出现实际需要时,应触摸(修复、改进)模块。

我的意见是,如果旧代码看起来不完美,就不要修复它,除非它的编写方式干扰了您当前的任务。

大部分代码写得不好。这是事实。如果你不是一个完美的团队,对质量价值有着完美的理解,并且在实现和保持这种质量水平的方法上达成一致,那么你的优化不会改变大局。你现在可以解决一些问题,但下一个家伙会把事情弄糟的。

我得出的结论是,在这个行业中,如果它没有坏掉,除非有一个该死的好理由,否则不要修复它。

如果您完全了解应用程序,或者有全面的单元测试以及在非生产环境中测试应用程序的时间,那么就开始吧。否则,就在必要的时候做。

这两个都是正确的,而且很难脱身。

如果你在遇到问题时不解决它们,并不是所有的问题都会得到解决。

如果你打破了与你目前工作的问题不100%相关的修复,那么人们会恨你。

另一方面,如果你修复了一些无辜的代码(或者更确切地说是看起来无辜的代码),它以意想不到的方式破坏,你就会发现一些有价值的东西:脆弱的代码。脆弱的代码通常是没人敢碰的。但是为了使你的产品更稳定,你必须去掉这些代码。这条路的第一步是找到它。

我不得不承认这样的修正会在团队中造成很多“不必要的”摩擦。当你触摸脆弱的代码时,人们会冲你大喊大叫,因为他们害怕。通常,这段代码会吹到你的客户脸上,所以你会从各种方向得到热量。

所以这真的取决于你想造成多大的痛苦,以及你愿意忍受什么。如果你在遇到它的时候修复了所有的问题,那么到今年年底代码将会更好。但到了最后,情况往往更糟。

我想第二个答案是“如果它没有坏掉,就不要修复它”,但是有一个相关的链接…

Things You Should Never Do, Part 1 - Joel Spolsky

本质上——有时不可理解的代码实际上是一个你没有机会理解的必要的错误修复。

一方面,改变已经或多或少起作用的代码可能会有破坏东西的风险,而且很容易成为一项非常耗时的任务。

另一方面,由于维护坏代码的负担,将坏代码单独放在一边以防破坏某些东西,可能会扼杀新的开发。

有时代码看起来很糟糕,因为它必须处理复杂的角情况,例如 Joel Spolsky points out ,重写它将通过不覆盖这些角情况来创建错误。有时代码看起来很糟糕,因为它确实很糟糕,重写它可以修复您甚至不知道存在的错误。您的代码库经验应该可以帮助您确定哪个代码是哪个代码。

在 Boy Scout Check-Ins Jeff Moser讨论了“总是让营地比你发现的更干净”的想法。总是让代码库比你发现的更干净,即使你不能解决所有问题;这些小小的改进随着时间的推移而累积。

正如所说的 this answer ,单元测试是一件好事。 Working Effectively with Legacy Code 作者是迈克尔·费瑟,是关于这个话题的一个很好的资源。

我个人倾向于花时间解决问题,而不是去完成所需的任务。不幸的是,要开始解决看似简单的问题,并解决一个巨大的混乱局面,这太容易了,你当时希望你没有。

我也和那些反过来的人一起工作,只要工作完成了,我就可以忍受坏的事情。

通常情况下,你可以花很长时间“找到正确的东西”,以便将来更容易地使用,你会发现代码在将来永远不会被重用。

我认为主要的事情是平衡你的团队的观点,定期与其他人讨论事情,最终满足你项目的要求,因为这是客户支付账单。

对你发现的任何问题都要有建设性的态度-不要仅仅为了这个而挖洞!随着时间的推移,团队代码评审有助于改进坏代码,因为坏代码编写者将开始了解如何生成好代码。

我建议用“todo”注释标记坏代码,然后在以后的时间/预算允许的情况下返回来修复它。至少你有一个潜在问题区域的标志,而不必(可能)浪费时间在不需要的修复上。