[alert color=”yellow”]I’m starting this year off with open ears. Please take some time to provide feedback via this short survey. It’ll help me help you.[/alert]
When you build a product you inherit a set of expectations. Your team, investors, and, most of all, customers expect it to work well. Also, they expect regular updates that enhance the experience for years to come.
Imagine building a home. You invest a lot of money for a place that you wish to feel safe in, while growing a family, for a long time. How would you feel if it continued to produce issues after moving in? It sounds insane right? You may have no idea how your house is built, but you want your house built the right way. If you want to remodel a section of your home you don’t want to find structural issues.
The same principals apply to software development. If you’re working on a product that you expect to sell for years to come, then take the time to create a maintainable environment. You’ll appreciate it, and so will any developer who follows in your footsteps.
If you’re a beginner, it will pay dividends to establish the right habits. Breaking habits as you get a few years under your belt becomes challenging. That’s the disadvantage of getting old (ha). It also doesn’t help to have the behavior ingrained in your mind. The last thing you want to do is establish yourself as a Cowboy. A cowboy is the worst. They don’t care about quality, blame others, ignore the issues, and are unpleasant people to work with.
Get It Together
Here we’re going to cover 9 things you can begin doing today to improve the quality of your code. I need to mention. If you’re building a prototype that you do not expect to move into production, then use your best judgment on the tips. Of course it doesn’t make sense to build a suite of unit tests, but much of the other tips should just happen out of your habits.
Follow a style
The codebase you’re working on needs to have a consistent style. If you’re part of a team then get together to establish a set of guidelines to work from. Simplify the effort by using existing styles in the community. Here are a few general points to keep in mind:
- Use informative names for variables, functions, and classes. There is no reason to be clever or sly by naming things with a small handful of characters.
- Don’t cram all your code within a couple of source files. Break your code into pieces where it makes sense.
- At the same time, don’t create functions that do 20 different things. Keep functions focused on a particular… function.
- Remain consistent with whitespace, naming, commenting, and the other rules you establish.
Find developers to code review your work
Would you rank yourself among the most elite problem solvers in the world? Probably not. So what you should do is find a fellow developer who makes you feel inadequate. Review code together to help fix potential long-term issues and learn things you never thought of.
What if you’re a freelancer with no fellow developers to lean on? You’re in a tough situation. Lean on developers within your own network if you’re not under an NDA. Consider heading over to a code meet up.
Review other people’s [great] code
Seeing how other people manage their project is a great way to learn, especially as a beginner. Don’t just run out to review any code you find. Hunt for the motivated programmers to lean on. If your work environment enables this, perfect! If not, find great open source projects to review.
When you go through the process of writing code you learn so much. By the time you’ve made a first pass you’ll often feel like pieces could be much better. Don’t just forget about those areas, make a note “// TODO: Consider refactoring this area”. When time allows it you should circle back and refactor those areas.
Write unit tests that cover your model, then move to your interface
Writing tests have the added benefit of helping you uncover code design issues. If you find that it’s difficult to test what you’ve written then that gives you a clue. It can often feel overwhelming to think about testing. Start with testing your model code. You can determine at a later date if you want to write a comprehensive interface suite. You want the confidence that your core logic is sound, so begin writing tests. The last thing you, or your team, wants to experience is unpredictability.
Avoid duplicating code
It should be obvious, but I see experienced developers make this mistake. If you have a lot of shared code, don’t be lazy, move it into a shared library.
Avoid commenting for the sake of it
Document the codebase where situations become complex. It’ll make your life easier as you return to the area months later. Your colleagues will also appreciate understanding what was going on through your head at the time.
You don’t need to comment every single function that exists within your codebase. Your function names should reveal the obvious goal.
Communicate with your team developers to set expectations
Avoid going rogue and just dictating the lay of the land. You don’t want to alienate your colleagues. Get your team together to discuss topics related to code quality. Work together to find a consistent style to work from and avoid getting into some kind of war among each other.
Don’t be a cowboy, maintain an expectation of excellence
Have you ever worked with someone who didn’t care about their job, but managed to keep the thing? You were effectively powerless. It was their way or the highway. They pretend to listen to your opinions, but just run off to do things their own way. Have a serious reality check. Don’t be that guy. If you have the power you need to maintain a level of excellence among your culture. Don’t lose sight of what makes up your team.
Expect excellence by creating coding standards and applying those standards consistently. Now, this doesn’t mean that you don’t allow yourself an inch of creative freedom. Establish a structure that is a fine balance of excellence and respect.
Here we’ve discussed a few ways to help raise the quality of your codebase. Remember, begin good habits as early as possible. You’ll appreciate it and your colleagues definitely will.
It feels like we’re entering an environment where people are worrying far less about code quality. I don’t know if that’s because people don’t feel like their product will stick around long or if it’s extreme laziness. Be a leader and motivate action. Make the best of what you’re doing.
Expect excellence. Create a maintainable environment. Pay attention to writing maintainable code for the sake of your future self and colleagues.
Did I miss something? Tell me about it!