A tale about refactoring code and a young boy that learned his lesson the hard way…
Once upon a time, there was a joyful jr developer full of dreams and excitement about his first deploy to production.
It was Friday in the afternoon and he was closing his last task of the week. He moved the story to done and when he was about to close the IDE he saw a hidden class inside a folder from some old legacy code with the legend:
// DO NOT TOUCH. This works and it´s necessary.
“This comment is not right!” thought the young Matt..heous, yes, Mattheous was his name, nothing to do with me.
“I think I can make this better,” said to himself as he finished his coffee and prepared his fast fingers to type the best clean code ever seen by humankind.
He started simple, partitioning a 150 lines method into a couple of them, removed unnecessary ifs, added a couple of validations, and created an object to revamp a nasty long signature. That was when he remembered
he has seen that awful list of parameters somewhere else in his codebase, “Right! Said the enthusiastic dev as he recalled where he has seen the ugly code. It was on the main external interface VB dll that was used to expose data to consumers.
This will be a great abstraction he thought, and run to apply it on the dll too.
Satisfied with his piece of art and proud of his great refactor the young Mattheous compiled everything and went ahead to deploy before leaving for the night.
This is not a happy ending story as you can imagine since the refactors made by the young dev broke several interfaces with external consumers and when all the systems broke down on Saturday everyone was running to get this fixed. The version had to be rollbacked and the beautiful piece
of art refactor the Mattheous did that Friday night had to be torn down. The more experienced dev of the team went ahead and recovered the good old ugly code that to this day stills reads the text:
// DO NOT TOUCH. This works and it´s necessary…
I hope you liked this kind of a weird format, I know it´s not the usual way to convey dev concepts but I thought I would give it a shot.
Jokes and storytelling aside, lessons for you about refactoring code:
- Never refactor just because you think is a good idea.
- Think ahead when you want to tackle a big refactor.
- Scope refactors to avoid ending up modifying half of your system and dependencies.
- Never mix new features with refactors in the same task (if something fails you won’t be sure which is the root cause).