Refactoring is a disciplined effort to improve the design of the code without changing its functionality, done in small - even simplistic - steps, safeguarded by unit tests, which ensure that the system is functional after each step. Moreover, it is typically done in small increments over a longer period of time, not in one big whoosh.
This is not to be overly zealous about anything, just to clarify the terms :-) There is less chance of misunderstanding and communication problems when we understand the same words the same way.
Of course, if you have the time to do a lot of refactoring at once, all the better! But before you embark on such an effort, you absolutely need to build a good set of unit tests which cover - ideally - all the functionality in the code parts you are about to change.
Since you are talking about a "major requirement change", it is not clear whether what you call "refactoring" is actually implementing new functionality or only improving the design to prepare for the introduction of new functionality. I strongly recommend to keep the two phases separate: refactor first without changing the existing functionality, to make your design more open to extensions at the right places, which then allow you to incorporate the desired functional changes more easily.
The Refactoring book linked by @Eric is fundamental; I would add Refactoring to Patterns by Josh Kerievsky, which is about the practical application of refactorings.
I would also recommend abstracting the part of the code you intend to refactor and still provide the old implementation for everyone else while you can access the new code you're writing so you can still benefit from source control.
Using a distributed source control system would also let you commit without disrupting others work.
Use a version control system that allows for local branching, git for example. That way you can keep checking in at minor milestones as you're working through the refactoring process.
At the point where you are trying to achieve more than one thing with your uncommitted changes, you have officially veered from "refactoring" to "hacking".
Each change you make should have a purpose and be testable, in and of itself. Of course, with many systems this is a challenge, but somehow you need to verify that given a set of inputs, the outputs don't change with your refactored code.
I know this is language-agnostic but from a .net perspective I employ a good set of unit tests and use Resharper to help with the process. This tool is invaluable in my refactoring endeavours.
As you are finding out -- an ineffective or non-existent "design" means that subsequent changes are indeed destructive.
Upfront, when choosing a design, you have to try to predict and account for the likely changes you will be facing. Some designs accept changes better -- for example if you are designing to accommodate rapidly fluctuating requirements, then use an autogenerated datalayer, keep validations in a single place and keep the GUI easy to modify -- a kind of normalization in the app. If you are looking for speed scalability, etc, then you need to denormalize the code and place validations in multiple places, write heavy layers, etc.
And so, if you later find yourself trashing your app to make needed fixes, accept that the design didn't work out and learn from it.
When you are faced with an ineffective design AND this will cost you a lot of time to make predicted changes, then the case can be made to refactor the design, as described in previous replies. This can be done while making other changes, although ideally you would say to your boss "Hey, I am just going to rewrite this code for a few weeks and, no, I am not addressing those features you really wanted and oh-yeah I am going to write a bunch of test cases too, but please don't fire the QA guy because its not that kind of testing". And he would agree!
发布评论
评论（7）
您所描述的实际上不是重构。
重构是一项有纪律的工作，旨在在不改变其功能的情况下改进代码的设计，以小的甚至是简单的步骤完成，通过单元测试进行保护，从而确保 >系统在每个步骤后都可以正常运行。此外，它通常是在较长时间内以小增量完成的，而不是一次性完成。
这并不是对任何事情过于热心，只是为了澄清术语:-) 当我们以相同的方式理解相同的单词时，产生误解和沟通问题的机会就会减少。
当然，如果您有时间一次进行大量重构，那就更好了！但在开始这样的努力之前，您绝对需要构建一组良好的单元测试，理想情况下，它涵盖您将要更改的代码部分中的所有功能。
由于您谈论的是“重大需求变更”，因此尚不清楚您所谓的“重构”是否实际上是实现新功能，或者只是改进设计以准备引入新功能。我强烈建议将这两个阶段分开：首先在不更改现有功能的情况下进行重构，以使您的设计对适当位置的扩展更加开放，然后您可以更轻松地合并所需的功能更改。
@Eric 链接的《重构》一书是基础性的；我会添加 Josh Kerievsky 的重构模式，内容是重构的实际应用。
What you describe is in fact not refactoring.
Refactoring is a disciplined effort to improve the design of the code without changing its functionality, done in small - even simplistic - steps, safeguarded by unit tests, which ensure that the system is functional after each step. Moreover, it is typically done in small increments over a longer period of time, not in one big whoosh.
This is not to be overly zealous about anything, just to clarify the terms :-) There is less chance of misunderstanding and communication problems when we understand the same words the same way.
Of course, if you have the time to do a lot of refactoring at once, all the better! But before you embark on such an effort, you absolutely need to build a good set of unit tests which cover - ideally - all the functionality in the code parts you are about to change.
Since you are talking about a "major requirement change", it is not clear whether what you call "refactoring" is actually implementing new functionality or only improving the design to prepare for the introduction of new functionality. I strongly recommend to keep the two phases separate: refactor first without changing the existing functionality, to make your design more open to extensions at the right places, which then allow you to incorporate the desired functional changes more easily.
The Refactoring book linked by @Eric is fundamental; I would add Refactoring to Patterns by Josh Kerievsky, which is about the practical application of refactorings.
您需要一个好的单元测试套件来确保您不会破坏已经运行的功能。 Martin Fowler 还写了一本关于这个主题的好书：重构：改进现有代码的设计
还建议抽象您打算重构的代码部分，并仍然为其他人提供旧的实现，同时您可以访问您正在编写的新代码，这样您仍然可以从源代码控制中受益。
使用分布式源代码控制系统还可以让您在不影响其他人工作的情况下进行提交。
You need a good unittest suite to ensure you don't break what's already working. There's also a good book from Martin Fowler on this subject: Refactoring: Improving the Design of Existing Code
I would also recommend abstracting the part of the code you intend to refactor and still provide the old implementation for everyone else while you can access the new code you're writing so you can still benefit from source control.
Using a distributed source control system would also let you commit without disrupting others work.
使用允许本地分支的版本控制系统，例如 git。这样，您就可以在重构过程中不断检查次要里程碑。
Use a version control system that allows for local branching, git for example. That way you can keep checking in at minor milestones as you're working through the refactoring process.
我正在解决类似的问题，这就是我所做的...
关键是使每个重构步骤尽可能小和经常测试/提交。
I am working through a similar problem and here is what I do...
The key is to keep each refactoring step as small as possible and test/commit often.
当您试图通过未提交的更改来实现不止一件事时，您已经正式从“重构”转向“黑客”。
您所做的每项更改都应该有一个目的并且本身是可测试的。当然，对于许多系统来说，这是一个挑战，但您需要以某种方式验证给定一组输入，输出不会随着重构的代码而改变。
At the point where you are trying to achieve more than one thing with your uncommitted changes, you have officially veered from "refactoring" to "hacking".
Each change you make should have a purpose and be testable, in and of itself. Of course, with many systems this is a challenge, but somehow you need to verify that given a set of inputs, the outputs don't change with your refactored code.
我知道这与语言无关，但从 .net 的角度来看，我采用了一组很好的单元测试，并使用 Resharper 来帮助完成该过程。这个工具在我的重构工作中非常宝贵。
I know this is language-agnostic but from a .net perspective I employ a good set of unit tests and use Resharper to help with the process. This tool is invaluable in my refactoring endeavours.
正如您所发现的那样，无效或不存在的“设计”意味着后续的更改确实具有破坏性。
首先，在选择设计时，您必须尝试预测并考虑您将面临的可能变化。有些设计可以更好地接受更改——例如，如果您的设计是为了适应快速波动的需求，则使用自动生成的数据层，将验证保留在一个位置并保持 GUI 易于修改——这是应用程序中的一种标准化。如果您正在寻找速度可扩展性等，那么您需要对代码进行非规范化并在多个位置进行验证，编写重型层等。
因此，如果您后来发现自己正在破坏您的应用程序以进行必要的修复，请接受设计没有解决并从中学习。
当您面临无效的设计并且这将花费您大量的时间来进行预测的更改时，那么就可以重构设计，如之前的回复中所述。这可以在进行其他更改的同时完成，尽管理想情况下您会对老板说“嘿，我只是要重写这段代码几周，不，我不会解决您真正想要的那些功能，哦，是的，我我也将编写一堆测试用例，但请不要解雇 QA 人员，因为这不是那种测试”。他会同意的！
As you are finding out -- an ineffective or non-existent "design" means that subsequent changes are indeed destructive.
Upfront, when choosing a design, you have to try to predict and account for the likely changes you will be facing. Some designs accept changes better -- for example if you are designing to accommodate rapidly fluctuating requirements, then use an autogenerated datalayer, keep validations in a single place and keep the GUI easy to modify -- a kind of normalization in the app. If you are looking for speed scalability, etc, then you need to denormalize the code and place validations in multiple places, write heavy layers, etc.
And so, if you later find yourself trashing your app to make needed fixes, accept that the design didn't work out and learn from it.
When you are faced with an ineffective design AND this will cost you a lot of time to make predicted changes, then the case can be made to refactor the design, as described in previous replies. This can be done while making other changes, although ideally you would say to your boss "Hey, I am just going to rewrite this code for a few weeks and, no, I am not addressing those features you really wanted and oh-yeah I am going to write a bunch of test cases too, but please don't fire the QA guy because its not that kind of testing". And he would agree!