Code Defactoring

Refactoring is the process of making code more readable and amenable to change. It stands to reason, then, that defactoring must be its opposite. This has been my task for today.

Earlier this week, my code failed a review (what a surprise). The problem was with a certain construct I had used to make up for the fact that ECMAScript does not support access control with keywords like “private” or “public” as other languages do, but does so in a different way. His view is that access control is subversive, and I should rewrite it using .prototype, so that all the members are public, but make it clear by commentary, documentation, and/or some naming convention, that “private” ones are only to be used by objects of this class. I might add, this is not some subversive bit of trickery that I have invented completely off the top of my head, but one found in our bible on these matters.

Of my code, he “assumes that it will be slower” than his proposed rewrite. Not a wholly unreasonable assumption, but based on nothing other than guesses. This is almost a textbook example of Premature Optimisation, it is not some piece of core functionality that will be called 1000 times a second, this is code that is likely to be executed somewhere between 0 and about 20 times on startup, depending on inputs. The only thing that keeps it from being real premature optimisation is that premature optimisation at least shaves the odd nanosecond off execution times.

Quite reasonably (or so I thought), in his review comments, my nemesis said that I should feel free to disagree, and make a case for what I had done, and it can be looked at again. I did exactly that, posting my reply about half an hour after his initial review, I even ensure that words ...

... middle of paper ...

... summon up the enthusiasm to put it up for review, knowing that it’s going to fail.

“We shouldn’t be doing anything that we feel might have a performance cost”

a) I don’t feel it will, and I have been proven right.

b) When did that edict arrive? Most of our code seems to have been written with the express purpose of being as slow as possible. Tweaks like this, even if his guesses turned out to be correct would have negligible effect due to the general stupidity of the architecture (a future post in itself)

I was also chastised for doing this profiling, as, again, when you have a lot to do, the best way to make progress is to pluck random guesses out from where the sun doesn’t shine, implement them, and declare them a success. Gathering data so that you can work out where to target your efforts or measure your success, is, apparently, a massive waste of time.