What is the recommended strategy of complete refactoring of a live product? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be开发者_如何学C answered with facts and citations by editing this post.

Closed 5 years ago.

Improve this question

Consider that you have "System_A" which is a web application. And System_A has simply 3 layers: UI, BusinessLayer and Data-Layer.

And now you want to make a widespread refactoring of System_A (the UI and BusinessLayer only) while it is working as a live product.

What should be the safest strategy of refactoring System_A and release the refactored product after a good testing -let's call it "RF_SystemA"- in a way that it can be reversed to System_A even in case of an unexpected bug (without forcing the users to change their URLs)?

---

First of all, you should have enough unit tests to cover the critical parts of the code. (If the UI and business logic is not separated well, making the logic difficult to test, you may need to lean more on functional/integration tests until you separate the layers enough to make the business logic unit testable.)

You should also have test/staging server(s) apart from the production one(s), where testers and users can verify that the new code is working well.

Then you can make small changes in the code, step by step, verifying after each step that all unit tests still pass.

After major milestones, you deploy the refactored app to the test/staging servers and run larger scale integration/functional/performance/whatever else you have tests.

If after all tests, you are happy and confident that the code still works as expected, you may deploy it in production.

Should a bug pop up after all this, you can easily return to the latest safe version in production. (And after that, you can start investigating how the bug slipped through and how to avoid this happening again...)

---

I haven't much to do with Web-Development, but just an idea:

You could write/generate a redirect-Layer first like so:

Let's say you had three functions in System_A like this:

System_A.Call1(...)
System_A.Call2(...)
System_A.Call3(...)

Then you could rename the calls like this...

System_A.Call1(...) -> Old_System_A.Call1(...)
System_A.Call1(...) -> Old_System_A.Call2(...)
System_A.Call1(...) -> Old_System_A.Call3(...)

...and create a temporary redirect system like this:

System_A:Call1(...) { Old_System_A.Call1(...); }
System_A:Call2(...) { Old_System_A.Call2(...); }
System_A:Call3(...) { Old_System_A.Call3(...); }

This system could go live immediatly.

Then you could create your Refactoring classes bit by bit, test them and just change the redirection calls. After refactoring is complete, you remove the redirection calls and just use the reafactored system.

The granularity of your redirection should correspond to the granularity of your refactoring. So if you refactor individual functions and the function signatures stay the same, you can use the approach as stated above. If you completely redesign whole parts of your system, you could redirect the whole parts.

Example for web: You have index.php which mainly calls 3 functions: header(), body() and footer().

You could either redirect the calls to header, body and footer (if the signatures stay the same), or you could redirect the whole thing and call only one function from your index.php like "currentIndexPhp()";

currentIndexPhp() would then initially call header, body and footer.

If you organize your folders and files accordingly, you should be able to control the refactoring quite nicely.