What is 3Q’s Method of Code Refactoring

THE FIRST Q: QUICK WINS

The first stage is to catch low hanging fruits, like identifying and removing dead code, removing duplicate code, and reduce method length. At this stage the following measures would be helpful:

  • Cyclomatic complexity: should be 10 or below
  • Average method length: 15 or below
  • Code duplication for 3 (or greater) lines of code
  • Overall code size: should be monitored and set targets for reducing it

THE SECOND Q: DIVIDE & CONQUER

The next stage is to start thinking of pulling apart components, whether business (or functional) components or utility components. This re-organization of code is essential to break the complexity of code and will open a large list of refactoring opportunities. At this stage, we will add the following two measures:

  • Instability: to measure correct use of design layers
  • Efferent and afferent coupling between component interfaces and the outer world

THE THIRD Q: BUILD QUALITY IN

The last stage is to start writing unit tests to test component interfaces. This is necessary so that to baseline the code quality and start doing more profound refactorings. At this stage, we will add the following measure:

  • Unit tests code coverage
Advertisements

What is Code Refactoring ?

Refactoring : A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.

Code refactoring is the process of restructuring existing computer code – changing the factoring – without changing its external behavior. Refactoring improves nonfunctional attributes of the software. Advantages include improved code readability and reduced complexity to improve source code maintainability, and create a more expressive internal architecture or object model to improve extensibility. Typically, refactoring applies a series of standardised basic micro-refactorings, each of which is (usually) a tiny change in a computer program’s source code that either preserves the behaviour of the software, or at least does not modify its conformance to functional requirements.

I’ve been asked, “Is refactoring just cleaning up code?” In a way the answer is yes, but I think refactoring goes further because it provides a technique for cleaning up code in a more efficient and controlled manner. Since I’ve been using refactoring, I’ve noticed that I clean code far more effectively than I did before. This is because I know which refactorings to use, I know how to use them in a manner that minimizes bugs, and I test at every possible opportunity.

Like refactoring, performance optimization does not usually change the behavior of a component (other than its speed); it only alters the internal structure. However, the purpose is different. Performance optimization often makes code harder to understand, but you need to do it to get the performance you need. Most of the the time refactoring improves performance in terms of speed as well, however at times its inverse could happen ie by extracting too many classes and introducing too many variable could have an impact of performance as well.

I want to reiterate that refactoring does not change the observable behavior of the software. The software still carries out the same function that it did before.

One thing at a time with TWO HATS ( Refactoring Vs Adding feature )

When you add function, you shouldn’t be changing existing code; you are just adding new capabilities. You can measure your progress by adding tests and getting the tests to work. When you refactor, you make a point of not adding function; you only restructure the code. You don’t add any tests (unless you find a case you missed earlier); you only restructure the code. You don’t add any tests (unless you find a case you missed earlier); you only change tests when you absolutely need to in order to cope with a change in an interface.

As you develop software, you probably find yourself swapping hats frequently. You start by trying to add a new function, and you realize this would be much easier if the code were structured differently. So you swap hats and refactor for a while. Once the code is better structured, you swap hats and add the new function. Once you get the new function working, you realize you coded it in a way that’s awkward to understand, so you swap hats again and refactor. All this might take only ten minutes, but during this time you should always be aware of which hat you’re wearing.

NOTE :

Please note that testing the while refactoring is very import. Always make small changes, test them commit them and make other changes. Do not thing to make all changes in a singe go and later on test entire application at the end. Multiple small cycles of refactor– test – refactor –test and smile Smile  is better then big refactoring – final testing – crying Sad smile