你怎么重构？

我想知道其他开发人员如何开始重构.你的第一步是什么？如果你重构不属于你的代码,这个过程(重构)会有什么不同？你在重构时写测试吗？

不要重构任何尚未进行单元测试的非平凡事项

写单元测试,然后重构

重构小块并经常重新运行测试

当代码是DRY ^* clean 时停止重构

^* DRY =不要重复自己

你的第一步是什么？

第一步是运行单元测试以确保它们都通过.实际上,如果在修改代码之前已经破坏了,那么您可以浪费大量时间来查找哪些更改破坏了测试.

如果您重构不属于您的代码,此过程有何不同？

在重构我没写过的代码(或者我很久以前编写过的代码)时,我肯定会做更小的步骤.我也可以在继续之前验证测试覆盖率,以避免依赖于总是通过的单元测试......但是没有测试我正在研究的区域.

你在重构时写测试吗？

我通常不这样做,但我可能会在以下情况下添加新测试(列表并非详尽无遗):

一个新测试的想法闪现在我的脑海里("如果......会发生什么？" - 写一个测试来了解)

在测试覆盖范围内发现洞

它还取决于正在执行的重构.在提取函数时,我可以创建一个新的测试,如果它可以像以前那样以不同的方式调用.

以下是一些一般性建议:

第一件事是在处理代码时保持一个代码气味清单.这样可以让人们摆脱记住代码中所见内容的负担.也,

当单元测试没有完全通过时,黄金法则永远不会重构.

在代码稳定之前重构,在添加你知道的东西之前会受到未来重构的影响,在集成之前,最重要的是在完成之前.

在没有单元测试的情况下,您必须将要重构的代码部分置于测试之下.如果通常情况下单元测试太难以进行改造,那么您可以按照Michael Feathers在"有效使用遗留代码"中的建议创建特性测试.简而言之,它们是端到端测试,允许您确定代码的当前行为(不会假设它始终完美运行).

不要害怕做婴儿步骤.不要同时做两件事.如果你注意到需要重构的东西,请记下来,不要立即修复它,即使它看起来很容易.

在测试通过时经常检查.这样你就可以在不丢失以前所做的事情的情况下恢复糟糕的重构.

请记住,重构不会给您的客户增加价值(这可以讨论),但客户不会向您支付重构费用.一个经验法则是重构之前进行更改或向代码添加新功能.