“We allocated 20K hour for refactoring, but our code base is still not good” said the PM
“We will refactor some old code out” , said the lead developer.
When talking about refactoring, there always some conflict between developer community and business community. Developer community has never lack of new ideas to refactoring the codebase, business community has never lack of new business requirement to be implemented. There are always fights for priority between them.
It is my belief that code refactoring is not a development task by itself, rather a part of every development task. As it was stated on one of the poster I have seen “excellent is not a destination rather a journey”. I want to share with you on the code refactoring process employed in the projects I worked on previously. It is not the best by any measure, but at least it could be used to initial some discussion and finally establish our own process what works for us.
First of all, code refactoring by definition is “make the program do what it does now, but in different way (better way in term of readability, maintainability, extendibility and reusability)”. If the code is not doing what it should do according to its requirements (functional and non-functional alike), the ratification process for that is not “code refactoring”, instead, it is defect fixing.
Principle 1: code refactoring is not a development task by itself, rather a part of every development task
Principle 2: do not touch the code for just refactoring
Principle 3: every time we touch the code, we want to make it better than it was before, at least we do not want to make it worse
Principle 4: never dream to have a (commercial) codebase that is no room for improvement (no place for further refactoring)
With these principles in mind, we have the following process for refactoring:
1. Establish guidelines on Identifying candidates for refactoring
a. These guidelines should be a living document, from time to time, items been added in or removed out based on the technical and management considerations.
b. These guidelines should be a controlled list, own by the development lead. Major refactoring suggestions need to include migration process and should be approved by the project management team. The following are a few example of refactoring ideas should be considered as major refactoring suggestions “start to use WPF for thick client”, “start to use entity framework”, “upgrade to Visual Studio 2010” or “change from VB.Net to C#” these suggestions need to have some serious discussions before been put in action, because the implication of such changes normal are huge.
c. The following are a few of basic refactoring guideline:
i. “Do not repeat yourself” if you find you need to copy a block of code and paste them somewhere and then make some changes to it. It is an opportunity to abstract it to a method by itself, if you find this copy-paste is happening across different class, it is time to consider putting this functionality in to a base class.
ii. “no comment is needed” a piece of good program code does not need comment to explain what it is doing, when you need to add comments to explain what the code is doing, it is an opportunity to encapsulate it to a separate member (property or method). A point is absolutely true but often overlooked, is “code always up to date, comments may not be” so it is much reliable to read the code instead of comments
iii. “too complex to explain” when a piece of program code is too complex or too long to explain or remember, properly it is time to break it into a few smaller blocks
iv. “too difficult to test”, when a piece of coding block is too difficult to test, ( write automatic unit test case), properly it is time to break it into a few smaller blocks
2. Identify refactoring tool in Visual Studio
a. Refactoring should be easy, if it is not, we need to find additional tools, if you are using C#, IDE offered all kind of refactoring tools you need. If you are using VB.Net, you might need to get some additional tools, there are 2 most popular refactoring tool in the market (free and commercially available) ( Resharper and Refactor! for Visual Basic (aka CodeRushXpress)
b. Code RushXpress is free ( well, MS paid for the license) and Resharper is more sophisticated but costs money)
3. Engage refactoring effort in every development effort you are assigned to ( task and defect alike)
a. When it works, do not break it! The best way of “not to break it” is “not to touch it”! This is because any code change will not only require your effort as developer; it also requires efforts from the deployment team and testing team. It is always not safe to assume “my code change does not introduce new bug, hence does not require additional testing”.
b. Refactor it when you have to touch it, do not let the opportunity pass you by. Since you have to touch it, the deployment team has to deploy it and the testing team has to test it. Let’s take the opportunity to make the code base better. But not a lot, because you do not want to touch the code more than what you have to, the testing test team does not want to test the functionality more than they have to.
c. Less is more. There is a say about programming like “lazy programmer write better code”. I am not so sure about that in general. But for me, I want to write less code, so I do not need to write and maintain more code if I do not have to. This is also go along with “do not repeat yourself”
4. Start refactoring by writing unit test first
a. By definition, refactoring is “doing the same thing in different way”, if you have a test cases against existing code base before refactoring, these test cases should continue to pass after refactoring
b. When you have automatic unit test cases safe guard your code base, you are much more daring to engage in refactoring effort.
5. Include refactoring effort in estimation for development effort ( it should not be more than 10% to 20% ). If it is more than that, you are biting more than you can chow.
6. Be familiar with refactoring technic. There is a good book on refactoring technic written by Martin Fowler “Refactoring – Improving the design of existing code”. (The best book on the topic in my view). Another good book to read is “Professional Refactoring in Visual Basic” by Danijel Arsenovski ( available on Books24x7.com)
No comments:
Post a Comment