Code Refactoring - A Cautionary Tale

[Mark Edwards3]

One of my junior developers came to me a couple of weeks back after inheriting some code from a previous team at one of our current clients.

He had a - not unreasonable - question about the code he was about to release.  His update set had a couple of red-flags raised by the tooling we use to validate the code, specifically around the use of synchronous AJAX calls being made into the instance.  The question he posed was whether he should try to fix the flagged items or leave them since it was code he'd inherited and hadn't necessarily worked on himself.

Now, I'm firmly of the belief that if you're the one releasing code, then you're the one responsible for it (since your name is going to be the one slapped all over the update set) plus, you owe it to yourself to fully understand what's in the package you're pushing out, so my answer to him was an emphatic 'Yes'.

This led into a short session spent with them to refactor several script items to try to remove the obvious performance bottlenecks and poor practices we found.

In fact, this prompted me to do a full write-up of this as an example in good practice and getting the best performance out of your client-server interactions as possible.  The full write-up is posted on my blog over at https://www.tesm.com/resources-blog-code-refactoring-a-cautionary-tale/ if you'd like to read more.

I'd appreciate any thoughts and feedback from the community.