- π International
-
Questions
Refactoring process
Code bloaters consist of long methods, large classes, primitive obsession, long parameter list, and data clumps. While refactoring to remove code bloaters, should all of these be done at once, or should tasks be broken down into logically related units and done one at a time?
For e.g. - I am reviewing a class and I see two problems (large classes, and primitive obsession). Should I rectify both the problems at once, or should I deal with large classes first and once the changes are confirmed, move over to dealing with primitive obsession? Thanks in advance.
ΠΡΠ²Π΅Ρ
Hi, Prachi!
You should always try to do just one change at time. Yes, sometimes you could cut a corner and do several small refactorings at once. But each time you do it, you're risking making an error, since your focus is spread through all the places you changed.
Here's a metaphor. Imagine a surgery operation, where a surgeon is going to cut a person's appendix. But in the process, surgeon discovers a cancer tumor and thinks "hey, I'll gonna cut this stuff as well while I'm here". And then patient dies and nobody knows whether it was because appendix or cancer.
Hope this helps!
Hi Alexander,
Thanks for the brilliant answer. The metaphor drives the point home!
Π‘Π΅ΡΠ²ΠΈΡ ΠΏΠΎΠ΄Π΄Π΅ΡΠΆΠΊΠΈ ΠΊΠ»ΠΈΠ΅Π½ΡΠΎΠ² ΡΠ°Π±ΠΎΡΠ°Π΅Ρ Π½Π° ΠΏΠ»Π°ΡΡΠΎΡΠΌΠ΅ UserEcho
Hi, Prachi!
You should always try to do just one change at time. Yes, sometimes you could cut a corner and do several small refactorings at once. But each time you do it, you're risking making an error, since your focus is spread through all the places you changed.
Here's a metaphor. Imagine a surgery operation, where a surgeon is going to cut a person's appendix. But in the process, surgeon discovers a cancer tumor and thinks "hey, I'll gonna cut this stuff as well while I'm here". And then patient dies and nobody knows whether it was because appendix or cancer.
Hope this helps!