I consider myself as a guy with OCD (obsessive compulsive disorder). Although, I am not in the prime of it, I still need somethings to be in an order. When I sleep, my mobile should be by me in a correct angle. My table should be aligned with the tile lines. I can go on and on if i talk about my ‘condition’. But, That is not what I am here to talk about.

I inherited this condition into my coding format as well. Although, I am not a developer who writes symmetrical nicer looking easily understandable commented codes( Psst, who does? ), I still can’t move on if I see a small space misplacement. If I see a code that repeats and feel like it can be inherited into a function that can be reused, I have to do that. And I did that. This happened for a while. But, The downside about this is we are not writing code to keep it on exhibitions. We write it to complete the projects which have tight timelines and deadlines. I frequently missed the deadlines and had to work for some more extra time to complete my task.

One day, On our weekly Leadership Wednesday, Our Visionary Aslam discussed with me about something called Red Green Refactoring concept from Test Driven Development (TDD) methodology. It was a great workflow and I follow that from that day. This is the excerpt of that workflow. That is, When you are trying to complete a task or fix a bug, You should always first go through the shortest way to fix it properly. Once you complete the task, move on to the most important task — refactoring or optimization. That will save you a lot of time and will help you complete your task within the allocated time period.

red_green_refactor

Even Though this is a simple technique, It is very hard to master for people like me who has some issues with their code looking messy. But, Mastering it will not only make your life easier, it will make you a better programmer as well.

But, If the project you’re working is a team project or if it is a project that will be reused, Please be careful with the workflow. You have to do the refactoring no matter what because, that will help keep the project cleaner and human readable. We are making this a caution because we experienced this as a team doing projects that changed hands from other companies. There were times we played where’s waldo with codes. So, Please be cautious about refactoring if you want to get a refactored clean code.