Skip to main content

Lucoles LTDA

Full Stack Developer, Acquia Certified Drupal 10 and Drupal 7, ITIL, PSM

reflections on code refactoring

Image
Alice and the Hatter sitting down at a messy tea table, coding on their laptops while surrounded by sheets of paper and smart devices with code in them. coffee is served on the tea cups. in the background, Cheshire the cat can be seen smiling.

they say, "when in Rome, do as the Romans do". but how do you fix crazy code without coming across as a smartass?

well, the short answer is, you don't. the long answer is "yooouuu dooon't".

but seriously, before fixing what ain't broken, you must ask yourself:

  1. is there something to be gained by doing this?
  2. how much effort are we talking about here?
  3. are people going to be on board with this?

first off, it's easy to say "of course everyone will benefit from indentation with double spaces instead of tabs!" but that might not be everyone's cup of tea.

(aren't you really just proposing everyone write code like you do?)

sure enough, you could say "that's the coding standard for our company/framework/community" but… sometimes it's not that easy.

I mean, sure, find-and-replace is easy, but someone, somewhere, is going to have to review your merge request… and they might respectfully disagree over what constitutes a priority.

(and bear in mind I threw around a very basic example.)

in this case, maybe outlining a code refactor would get you further ahead. but naturally you'll want to weigh the pros and cons, and state your case before the Queen of Hearts — I mean: prepare a decent presentation for your team.

perhaps your refactor could dramatically increase performance? now there's a card you'll want to play.

even still, your PO or Team Leader's head might be on the line — which is why you should work with them to establish priorities: maybe when it's time to upgrade to a newer version, your changes (sorry, improvements) could be accommodated?

therefore it's important to sit down with your team and lay the cards on the table, before a smiling cat pops up to say: "if you don't know where you are going, any road will get you there".

I know, I know: programmers (or developers (or software engineers)) are not exactly what you would call people, err, persons. but you'd be surprised at how far a little bit of emotional intelligence might take you.

on the right path, that is.

and who knows? maybe your team could take you on a journey through the Looking Glass! that's bound to uncover some Wonders.

if you've read this far, thank you! tell me: what do you do to improve the projects you're working on? and what positive changes have your teammates inspired you to undertake?


Originally published at https://linkedin.com on November 26, 2024.