Most developers code, test until the code works, and then continue coding, happy that they’re so good and successful at their job. When working this way, the split between coding and testing is roughly 50/50 for more junior developers, and trending towards 75/25 for more seasoned pros. But when working this way, you lose the most valuable opportunity you have to better yourself and your work. Would you turn in a paper without proof reading it first? Of course not! When I work, I try to allocate 20% of the time I’m given for an assignment to planning and architecture, 60% for actually writing and testing code, and the final 20% to cleaning up the huge mess I made along the way, aka refactoring. That’s it kids, the word of the day is “re-fac-tor-ing.”
Refactoring means taking a chunk of already working code, and making it “better.” It’s vitally important that the code already works, otherwise you’re still developing. “Better” can mean lots of things, from more efficient to more readable, but when talking about refactoring, we’re mostly talking about more readable, which has trickle down effects making it more efficient. The important thing is that you take the time to read what you just wrote. Like taking notes in class, if you can’t even read what you wrote the day before, how is anyone else supposed to? Most of the time developers can read what they wrote, but not what anyone else wrote, which is the biggest problem that refactoring attempts to solve.
When refactoring, you should look for ways to simplify your code, making it more readable and maintainable. Here are a few questions to ask yourself:
Is this code still used?
If it’s not, don’t comment it out, delete it! Version control can always resurrect it if needed, and you’ll be removing one potential point of confusion for someone maintaining your code down the line.
Is my code documented?
At a minimum you should have inline comments that provide a narrative of what the code block below is doing. That’s usually enough for leaf classes that aren’t meant to be subclassed and are used sparingly. As code becomes more reused, eventually becoming a library, it should have more complete documentation, like ASDocs.
Do my package, class, function, constant, and variable names still make sense?
This is huge. Names should have an instantly understandable and useful meaning to the human who’s reading your code. Don’t be afraid to have names that are long, but look for ways to shorten the really, really long ones too. Use that vocabulary, smart guy! Flex Builder has a very nice feature called “Rename” that’s in the “Refactor” menu when you right click a name that is effective at making renaming a trivial task.
Is my code well formatted?
Telling developers where to put whitespace and line breaks is probably the most surefire way to make them secretly hate you. But you, as a developer, should take pride in your craft and make an effort in making your code at least consistent. If you write a function with 30 unbroken lines of code, it makes it difficult for someone else to scan what’s going on. Sprinkle some line breaks and inline comments in there to logically chunk it up, and you’ve instantly saved your company time and money in the future. By the way, Adobe publishes coding standards that their developers are supposed to follow when writing code for the Flex SDKs. Does every line of the latest SDK conform to those standards? No way! But you can see that the developers make an attempt to make their code readable.
And finally…
Is there a simpler way to do this? Is there a better algorithm? Is there a function or library for this already? Are my objects properly encapsulated and loosely coupled? The answers to these questions will get easier for you to answer in time, but the fact that you’re asking them of yourself has already put you on the right path.