你怎么处理恶劣的代码？

Question

当你被分配到那些令人厌恶和过时的代码时,你会怎么做？这几乎是不可理解的？

例如:硬件接口代码,混合逻辑,AND用户界面代码,ALL在同一个功能中？

我们一直看到不好的代码,但你实际上对它做了什么？

• 你试着重构它吗？
• 如果不是的话,试着把它做成OO吗？
• 或者您是否尝试了解它,进行必要的更改并继续前进？

Answer 1

取决于我的几个因素:

1. 我将来会维护这段代码,还是一次性修复？
2. 这个系统完全更换需要多长时间？
3. 我现在有多忙？

理想情况下,我会重构我必须维护的所有不良代码,但实际情况是,当天只有这么多小时.

Answer 2

通常情况下,"它取决于".

我倾向于问自己以下一些问题:

• 是否有现有代码的单元测试？
• 重构代码是否可以为我的项目带来风险？
• 作者是否仍然可以澄清我可能对代码提出的任何问题？
• 我的雇主会考虑将现有的,有效的代码所花费的时间用于我的时间吗？

等等...

但假设我有能力这样做,重构是优先的,因为现在修复代码的前期成本可能会节省我在维护和开发时间后的大量时间和精力.

还有其他一些好处,包括你保持代码库越干净和维护得越好,其他开发人员就越有可能保持这种方式.实用程序员称之为破窗理论.

Answer 3

开发人员有一种直觉,认为代码总是很丑陋,因为其他劣质开发人员.有时,代码很难看,因为问题空间很难看.丑陋不仅仅是丑陋 - 它有时是机构记忆.代码中的每一行丑陋都可能代表一个错误修复.所以在你全力以赴之前要仔细考虑.

基本上,我会说你不应该触摸这样的代码,除非你真的需要.如果您可以解决一个真正的错误,那么重构是合理的,如果您可以确定您保持相同数量的功能.但是为了重构而重构(例如,"使代码OO")是我通常将其归类为经典新手错误.

Answer 4

" 有效地使用遗留代码 "一书讨论了您可以执行的选项.通常,规则不是在必须(修复错误或添加功能)之前更改代码.本书描述了如何在无法添加测试时进行更改以及如何向复杂代码添加测试(这允许进行更多实质性更改).