Practical refactoring [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 answered with facts and citations by editing this post.

Closed 7 years ago.

Improve this question

I've read about refactoring and probably did it before I even knew about it, however I don't really know much about it is actually done and what it practically means.

• What, from your view, is refactoring?
• How and when do you do it?

---

What, from your view, is refactoring?

As a purely academic definition, refactoring is a material alteration in existing code that does not (in theory) affect behavior or output.

In terms of practical implications, it can be a variety of things. As a small sample:

• Moving repeated code blocks into dedicated functions
• Giving variables clearer or more specific names
• Altering class relationships to better reflect real-world relationships (or class redesign in general)
• Decoupling previously interdependent code

If it sounds like a lot of those examples should have been done up-front, that's intentional; a lot of refactoring is simply adapting code that you wrote into how you should have written it to begin with (though, to be fair, a lot of refactoring also doesn't fit this description).

How and when do you do it?

The "when" is both short and largely unhelpful: when you can and when you have to.

When you can, it's important to make sure that code you've written isn't going to cripple (or hobble) you in the future. If you took shortcuts up-front to ship a product on time, then you may get a chance during future periods to dedicate a little time to refactoring. The idea of having "down time", though, is obviously just a myth in the business world ;)

The times when refactoring is required is usually a judgment call that says "it will take less time for the team to refactor this code to what it needs to be for this change (or to fix this bug) than it would to write the new code in such a way that it fits with what's there". This is a situation that should be avoided like the plague; refactoring is more dangerous (in general) than new code, as you're changing what's already (hopefully) been tested. Doing this under what is, by definition, a "time crunch" is even more dangerous.

Like most maintenance coding, refactoring has little to no short-term benefits (after all, you aren't changing output). The benefits come, like proper up-front design, in the form of decreased future maintenance burdens and faster (and, hopefully, more reliable) changes.

On the upside, refactoring can be enjoyable (though it can also be maddening at times)

---

Refactoring is a process of looking at old code and tightening them up, while making sure it still works. There's a couple of ways to do refactoring:

1. Are there any repeated codes/operations that can be implemented in another function?
2. Is a class getting too bloated with many responsibilities?
3. Is there anyway to isolate changes in this class from impacting others?

Usually I do it as a part of a test-driven development. First, set up unit tests, and write a first-pass of the code with the idea to make it functional, but though it may be ugly. Next, tidy up the code, implement design patterns and such and use the unit tests to ensure that your changes do not break the code.

---

Refactoring, according to Wikipedia, is "the process of changing a computer program's source code without modifying its external functional behavior in order to improve some of the nonfunctional attributes of the software".

I tend to do it when the code starts to become either so difficult to maintain or so inefficient that it's worth the time and effort to rework the code. Refactoring can also happen when I'm about to start working on an updated version of a program that is going to add some new functionality. Sometimes changes are needed in the original version that don't have any effect on the outward appearance of the program in order to better support the additions in the new version.

---

Refactoring is changing the design of existing code while leaving the functionality the same.

The idea is that you change the design in order to make to new functionality easier to implement.

---

About when to do refactoring:

• When it is needed (somebody spotted issues that can be improved)
• ... and the project state (scheduling, team load) allows it
• ... and the risk that the changes will have side effects is manageable and acceptable
• ... and the effort spent on refactoring pays back in terms of maintainability, code reuse, or any other aspect of the project development.

---

What, from your view, is refactoring?

A variety of works on old codebase in order to improve its structure, optimize certain code metrics and in general make it more suited for demands of today.

How and when do you do it?

In the best case, this work is done regularly in the form of code reviews. This should be a preventive activity before it is too late. When it is too late, you do it when you see a part of code is on the verge of collapsing into total mess if you attempt to touch it to add new functionality. Also, when the structure of code is no longer a good match for new features to be added of just for the present understanding of the project needs and the directions of its future development.

---

Refactoring simply means to change the design of a program, or part of a program. In object-oriented programming, it often means that you re-think your class hierarchies.

The reason it is done is simply because you realise that an early design decision was the wrong one, and it would be better in the long run to make this large change, so that you have the correct design.

Some IDE's such as Visual Studio have tools for refactoring, like having the ability to select code and extract it out into a method, or to easily rename a variable. Without those, refactoring has to be done manually, as it is often done in languages such as C++, which are difficult to automatically refactor.

---

Refactoring is the process of creating maintainable code from unmaintainable code-hell.

I.e. if you have something like that in your code it's really, really time to refactor it:

function show_movies($num=10, $maxpages=10, $order_by="M.produced DESC", $rand=0)
{
  global $template, $off, $cat, $cat_long, $cat_field, $lang, $mid, $cat_long2, $sfm;
  global $sea, $seaquery, $lng, $sub, $aff, $spe, $da, $cat_not, $PHP_SELF, $HTTP_HOST;
  global $q, $_SESSION, $VC_LANG, $john;
  [... snip 356 lines of code that works with all those variables ...]
}

(Sadly this is code i have to work with and i have no time at all to refactor it... oh, and if anyone wonders, $john enables debug mode and comes from GET via register_globals... i hate my life)

Usually refactoring is done while you are still developing, related to "Build once to throw it away". You first develop working code, then you refactor it to create working and maintainable code.

In many cases the second step was forgotten by your predecessors and you have (barely) working code which is not maintainable. Usually it's summarized (often incorrectly) as legacy code, code that exists, noone ever wants to touch but drives the whole business. In that case you try to split the code into parts, write tests and make sure that the new code does exactly what the old code did, just better and cleaner.

---

Refactoring is all about making your code more maintainable.

Practically, the requirements of the software are changing continuously that leads to continuous changes in the software. Over a period of time, the software starts becoming complex. As correctly illustrated by Lehman in his excellent work on software evolution that "as a system evolves, its complexity increases unless work is done to maintain or reduce it". Hence, we have to reduce the complexity of the software periodically and that's why refactoring is required.