You may need to keep on refactoring the legacy code to fix bugs, to add new features or enhancements.
For these changes normally we would have a defect or new requirement created in QualityCenter/VersionOne or whatever the tool you use for tracking the tasks. We burn the hours spent on these tasks against the respective defect-id or requirement-id.
Then assume you identify some piece of code which is written in horrible way and thought of refactoring that logic. Generally we will create a defect-id explaining the need for refactoring and refactor, test, commit, done.
In some organizations, as per process every commit to the source code should be associated with some defect-id or requirement-id.
What if your manager said
As per our process, every commit should be associated with a defect/requirement.I guess you can understand what that manager's reply implies :-).
We can create a defect for code refactoring that you are suggesting. Every code change should go through all the QA/UAT cycles. But the business will prioritize the defects/features for the next release as per release plan. So I can't assure you whether this will go in next release or not.
But I felt like from the manager's perspective it is valid point. His target might be to deliver the planned bug-fixes/features for the next release.
So guys, I am curious to know how is code refactoring is happening in your organizations?
It varies between one organization to other. most of start-up or product development company like to improve code quality but process oriented service based company may not be very supportive as you said.
ReplyDeleteThanks
Javin
How HashMap in Java works internally
We perform refactoring mostly when its required for an enhancent or bug fix, and associate it with that id. Sometimes we have larger, more independent refactoring jobs that get their own id and in that case theyre schedules into the release plan
ReplyDeleteDepends on the size of the refactor. Small stuff just gets done, catch the boss in the hallway and say "code X is pretty crappy, I am going to fix it". Bigger refactors get a bug ID so QA knows they need to give a solid once over. Probably would be best to have a bug ID always so QA knows something has changed in an area.
ReplyDeleteRefactoring generally improves things but there are times when it really messes up some odd program logic that you did not know to test against as you were doing the refactoring.