Whenever I’m adding a new feature and I start poking around, the goal is always to get something working and turned around in a hurry. Unfortunately, a lot of my code does not start out with adaptablitiy and extensibility in mind, so this rarely happens. Instead of doing things right the first time, I’m usually doing things quick and dirty and hoping there’ll be time to clean things up once the dust settles. This is why my code blows, but it’s gonna be OK.
When you find yourself with a sprawling, smelly mess and you’ve got some time on your hands, get in there and start refactoring.
In the true spirit of this post, this is a work in progress. It’s an attempt to set guidelines to follow when writing code. By it’s very nature, it’s an opinionated approach. The ideas below should not be looked on as a hard and fast set of rules but more of a the gold standard to shoot for.
Keep in mind that this is just what works for me and what works right now. The whole rewarding challenge of this stuff is figuring out what works for you and your team. There’s more than one way to make an old fashioned. In fact, there’s plenty of good ways to do it, yet somebody’s always fooling around with the basic ingredients to come up with a new method. Most folks would agree that some ways are better than others. The guy out there making old fashioneds for a living? He’s seen all kinds of ways to do it. He’s probably tried some ways that didn’t work out so good. If this guy says there’s only 2-3 really good ways to do it, and he has a way of his own, I’d hear him out on his method when it comes time for me to catch a buzz and type-2 diabetes at the same time.
Figure it all out (again)
The first thing I do is read through that smelly mess, adding comments to the especially sloppy bodges along the way. A good candidate spot for a comment is any place where it takes more than a second or two to figure out what the hell is going on. Once you decipher the ancient glyphs, put your plain speak translation in a comment above the offending odor.
As I read through, I like to make notes outside of the program as well, like in a google doc or on real paper. If there’s zero documentation for the project so far, guess what, any scribblings I make here is at least a baby step in the direction of documentation, which is always a baby step in the right direction.
Cut it up
Start with large methods over 20 lines. Got any of those? What is that really doing? More than 1 (or 2) things? Then it’s probably doing too many things. It might be time to extract some stuff out to a new method. If we’re really gonna get crazy, it might be time to whip up a new class.
Testing
Grizzled industry vets and code gurus alike will tell you to follow Test-Driven Design principles when writing Object-Oriented code. They along with most folks smarter than me suggest you get yourself set up with some test suites, write fully mockable objects, mock those objects, write tests, run tests, fail tests, fix, run, pass, repeat. Proper testing is hard. What a bunch of suckers. I do dirt-style testing. It’s all about the instant gratification vs. the long-term gains.
I generally just try to follow the web app from request to response. When I’m not 100% positive what happens next, I like to sprinkle in some dumps() and exits(). After a few refreshes, I might just learn something. All the pros are doing that move. Those are for losers. When I don’t know what’s running when, well, that there is just plain sad. I wrote this bologna, right? “Oh, but it was inherited from somebody and I just maintain it….” blah, blah, blah, bullshit.
Make the software or code you touch a little bit better with every pass. Profound, I know, but it’s a lot easier said than done.