Sergey Nivens - Fotolia
I think we can all agree that unit tests aren't optional anymore, right?
Programmatically testing your codebase is a no-brainer. Unfortunately, I don't think the same can be said for code reviews. In my experience, many organizations are quick to encourage test-driven development while simultaneously foregoing a team-driven source code review process.
Sure, there might be some minor oversight from another developer on a team, but when you're moving fast and breaking stuff there's not a lot of time for a formal source code review process. A quick once-over of a pull request before merging a branch into its master is often about as thorough as things get. The thing is, code reviews aren't designed to identify bugs; their true purpose is to ensure that all code is clean, maintainable and standardized.
Clean code means something different to every developer -- which is why there are so many conflicting style guides for every language -- but I think it's an accepted fact that clean code is important. Every organization has its own standards, but regardless of specific style rules, it is important for all code within a project to be developer agnostic.
It's not all about line-to-line style, though. It's also about architecture and organization. The directory structure of a project should be consistent for increased readability. Any new code that doesn't follow established conventions decreases the likelihood of a new developer understanding it without an additional effort.
The same goes for code organization and structure. By establishing, and enforcing, rules around how things like classes and scripts should be laid out, you give any developers who are unfamiliar with a particular facet of codebase a leg up by reducing the number of things they have to wrap their head around.
We've all heard the phrase legacy code before. Legacy code is, more often than not, a fancy term for an original prototype that evolved into the official product. In my experience, legacy code is incredibly difficult to maintain due to the need for an early stage startup to move as quickly as possible. Code debt is nearly impossible to avoid at that stage, but once things stabilize it is important to follow a process for all new code in order to ensure future maintainability by going through a source code review process.
One of the biggest traps experienced developers can fall into is writing code that is too clever. Surely, clever solutions have their place in a project, but the trouble with being too clever is that these types of solutions can make maintainability difficult for more junior developers. Sometimes, the most maintainable solution is also the most boring one.
I should mention that documentation falls under the umbrella of a maintainable code. Good code is subject, while documentation is not. Good documentation addresses the how and the why of a block of code, rather than the what. A good rule of thumb is that, if you have to explain something about a piece of code when you hand it off to a new developer, you should write it in documentation.
I am a huge advocate for standards-based development. Unless a problem absolutely warrants a proprietary solution, you better will serve your team and the future of your project by following commonly accepted standards and utilizing open source solutions whenever reasonable. The problem with proprietary solutions isn't that they are less effective -- because that isn't necessarily true -- it's that they aren't standardized.
By encouraging standardized solutions to problems, you can ensure that all new developers have existing documentation and an active community to learn from. This reduces assimilation time and helps prevent knowledge silos within individual members of a team.
While these are three aspects of a codebase that should be maintained through a source code review process, it is important for these reviews to be a team effort. A lot of development teams are meeting-averse, so it can be hard to get everyone in one room to review a new code, but this process allows everyone to have a hand in guiding the evolution of both that product, and the rules of its codebase.
Not everyone will agree on when it is appropriate to use an open source solution over a proprietary one, or where to put a new type of service or library. By using code reviews as a collaborative process, you can get buy in from your team on all new rules and processes, as well as ensure that a codebase grows in an intelligent and organic way.
Ownership of a codebase spreads beyond an individual developer of a feature by giving everyone an opinion and a voice. This allows anyone to take the lead on that feature or fix it by distributing knowledge, and over time that team will internalize the guidelines that were established, which will not only reduce development time, but also increase reliability.
In the end, code reviews aren't just for junior developers, and they aren't for simply checking everyone's work. They exist to make us all better at our jobs. A source code review process is a collaborative system that development teams should use to not only improve the quality of a codebase as a whole, but also to disseminate information about that project, and provide a platform for an entire team to establish and maintain best practices.
How will using open source change developers' careers?
Cloud computing careers for Java developers
Learn how to refactor and reorganize preexisting test suites for future maintainability