in reply to Re: Keeping, and advancing in, your job
in thread Keeping, and advancing in, your job
The bad side of this is that cleaning out the global variables will never fix the problem you're facing at the moment.
The good side of this is that you'll discover and repair dozens of potential problems, and actual problems that people have learned to live with or assumed were intentional (albeit stupid) design decisions.
The so-so side of this is that once you've made everything properly strict-safe, you'll realize that your new version really isn't substantially better than the original. The mindset that produced that many stricture violations is unlikely to have done a great job with the other parts of the system. But you will have a good understanding of what those problems truly are, much better than the initial knee-jerk reaction of disgust that you started out with. And that will enable you to start intelligently refactoring pieces without breaking the overall script (or needing to introduce so many adapters and bandaids that your "improved" version won't be.)
At the risk of offending the fanatical refactoring devotees, I will also assert that even if you manage to refactor the crap out of the code, it's never going to be pretty. It is possible to turn a chicken into a horse by changing one piece at a time, but any sane programmer will start by throwing out the gizzard. As a result, he'll end up with a two meter tall winged herbivore that sleeps standing on one foot and outruns a greyhound -- but dies of starvation. Doing it right requires designing pretty much the whole horse in advance, and if you're going to do that, it'd be less work to just build the damn horse.
But if you do, you won't have time to feed the chicken.
|
|---|