Software development now seems to be a process of iterations. after every iterations, we introduce more smell codes. However, it's difficult to determine when it's approriate to refactor our code.
This always be a indecisive battle and not be the right answer for all types of projects.
Refactor too early and you could over-abstract your design and slow down your team. You’ll also make sub-optimal design decisions because of the limited information you have.
On the other hand, if you wait too long to refactor, you can end up with a big ball of mud. The refactoring may have grown to be a Herculean effort, and all the while your team has been suffering from decreased productivity as they tiptoe around challenging code.
Questions:
When we want to refactor some code, we should ask ourselves some questions before going up to any refactoring. These all affect to your refactoring decision:
How large is scope your project has? (project timeline? team size? how long is an iteration?)
How rush are your current in-dev features? Are we in new and complex peices of functionality?
Is your release now stable? Small changes may lead to subsequent issues and other bugs not related to current features. And customer will complain about quality or development process.
Should we refactor when everything is working ok?
Is your customer aware of it and willing to pay for that?
How much time and effort will refactoring costs?
How much valuable will refactoring get?
Is there any slow down impact to current feature development or team?
When we need to refactor:
After some release works quite stable.
After getting new improvement ideas (more readable, new code style, new architect, ...)
An aware issue that occurs multiple times.
We are have out-of-date or deprecated libraries/functions.
There are security patches or hot fixes from in-used frameworks or libraries.
We prepare codebase to apply any new libraries or features.
Motivation to learn something new and better.
Who will take responsibility for refactoring:
Refactoring tasks should be aware and approved from all team members.
Pair programming and do peer review for all refactored code
How we do refactoring (in our case):
Before doing this, read some books on refactoring progress or code quality (Clean Code, Working Effectively with Legacy Code, ...) to get ideas, use cases, pros and cons.
List out all things we want to refactor
Document all issues you have met as lesson learnt so everyone don't run into it later.
if it quick, small and safe, count it into current working feature
if it's moderately complex and I don’t want to be distracted from the current features, throw it into task list as part of new features/user stories.
Whereas, refactoring to bring structural uniformity across the system, must be done with agreement between engineers and product managers.
Apply code tools to help us more consistent and reduce effort for refactoring: code formatter, code linter, ...
refactor something that no one "needs". Avoid refactor code when many components depend on it, no matter how bad it is. It's risky.
remove unused modules, dependencies, redundancy code. we have source control and can easily get back to it anytime if need.
Get deep dive into data structures, algorithms and rules:
SOLID, DRY, KISS, LESS
Design patterns
Software architectures
improving readability (variable/function naming, organize code into more sensitive components)
have test as much as posible on old program to keep the old behaviors are correct and later changes don't accidently change the program behaviors.
Conclusion:
Refactor early, refactor often.
Refactoring should be started early in a project's development, and should be repeated often.
Hey audiences or other teams, please give us feedbacks and suggestions!!! We appreciate that. <3
tieubao
commented
5 years ago
Brief
Questions:
When we want to refactor some code, we should ask ourselves some questions before going up to any refactoring. These all affect to your refactoring decision:
When we need to refactor:
Who will take responsibility for refactoring:
How we do refactoring (in our case):
Conclusion:
Hey audiences or other teams, please give us feedbacks and suggestions!!! We appreciate that. <3