July 18, 2013 Posted by Victor in Frameworks & Tools, PHP best practice

Refactoring code?

Refactoring is a law of nature for any Agile project as changing requirements are a fundamental assumption of Scrum (and other Agile processes).
For example for Scrum teams, in the early Sprints (iteration), there will not be time to build the entire robust infrastructure that the final product will require. However, the full product will almost certainly require a larger, more powerful, more robust infrastructure.

Actually seems like there is a short limit of ways to change the infrastructure:
-> rewriting the code on every Sprint
-> evolving the code it

I guess dor most of you writing it over again would be an inefficient approuch. Therefore we must evolve it. Software evolution is refactoring.
We must evolve the infrastructure.

Again, why are we doing this?

Keep in mind that the programmer usually does not have all the necessary information at the begginign of the project to be able to design big part of the infrastructure in the begining of the project. This is why the program is designed as it is written, not before.

Without rapid, early coding, amny projects can spend months in the design phase only to be discovered to be unrealistic, overbudget, or overschedule once coding starts. Without refactoring, a project usually devolve into unusable, unmaintainable spaghetti code.

Refactoring doesn't change the observable behavior of the software; it improves its internal structure. For example, if a programmer wants to add new functionality to a program, he may decide to refactor the program first to simplify the addition of new functionality in order to prevent software entropy.

Refactoring will help improve the:
-> Maintainability. Make it easy to read and logical. It will be easier to correct bugs and improve the code.
-> Extensibility. Write oject oriented, design driven programming will provide the flexibility needed for any future upgrade and extension

How can this be done?
Idially we sould create first the tests (unit testing anyone?), a very good cost-effective technioque.
After that we have a good array of options, probably you should understand which is best for your particular case.
1. Abstractisation:
Representing the data in similar form to its semantics regardless of implementation details to improve code sharing.
Using DRY "don't repeat yourself" principle to avoid code duplication.

2. Fragmentation or Componentization:
Breaking the code in logical pieces, components, libraries, methods...
Unload classes and methods creating new ones when we have too many methods inside (overweight) and the purpose becomes unclear.

3. Organisation:
Improving the maintainability by improving the code structure and organisation:
-> moving methods and fields
-> renaming methods and fields
-> create super and subclasses

In the end, keep in mind that this are the key characteristics that we usually strive when refactoring (and I will repet myself):
Clarity of the code
Elimination of the redundant (combine, move and eliminate)
Modularity and Scalability sould be done without adding complexity to the logic and the code
Simplicity: if the code was written using the XP process, it should already be almost as simple as possible...complexity should not be added unless absolutely necessary to improve readability or modularity.

If I get your attantention, probably would be good to check this: http://sourcemaking.com/refactoring

Click to share thisClick to share this