Own (and Refactor) the Build
Often teams that at highly disciplined about coding practices treat build scripts as a black art. Projects with highly refactored code have build scripts with duplication that are difficult to maintain. Duplication and errors in the build scripts cause problems of the same magnitude as those in poorly factored code.
One explanation for why disciplined, skilled, developers treat the build as something secondary to their work is that build scripts are often written in a different language. Another, related, rationale is that the build is not really "code." Yet, most software developers enjoy learning new languages, so the language difference does not ring true. Since the build is what creates executable artifacts for developers and end users to test and run, and since the code is useless without being built, it's inconsistent to say that the build is not code.
Much like code, where there is duplication in the build process is a place where things break when there are inconsistencies which can make it harder to change processes, and harder still to debug problems.
Build scripts written using the wrong idioms make it difficult for others to understand how to improve the build. Whether your project is built using Maven, ANT, Rake, Make, or some other tool, it is worth spending some time to understand the right way to make a change.
In earlier times, testing was something that was left the the "Quality Assurance" team. Now we realize that testing as we code is necessary to being able to deliver value predictably. In much the same way, the build process needs to be owned by the development team.
The build process is where everything comes together to create executable code that is tested by developers, built in an integration environment, and tested. "Bugs" can appear when an application is built with the wrong version of a dependency, or when a build time configuration is wrong. The build is too important to leave to someone else, and in fact, it is the person developing the code who knows how the build should work.
Thinking about the build can simplify your life in other ways too. A simple to execute build makes it easy to get a new developer started. Automating configuration in the build can enable you to get consistent results when multiple people are working on a project, avoiding a "works for me" conversation. Many build tools allow you to run reports on code quality, allowing you to detect potential problems early. By spending time understanding how to make the build yours, you can help yourself, and everyone else on your team focus on coding features, benefiting your stakeholders and making work more enjoyable.
Learn enough of your build process to know when to make changes and what the correct idioms are. Build scripts /are/ code and are too important to be left to someone else.
This work is licensed under a Creative Commons Attribution 3
Back to 97 Things Every Programmer Should Know home page