Own (and Refactor) the Build

From WikiContent

Revision as of 22:54, 27 December 2008 by Sberczuk (Talk | contribs)
Jump to: navigation, search

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.

It's curious why disciplined, skilled, developers treat the build as something secondary to their work. One rationale is that build scripts are often written in a different language than source code. Another, is that the build is not really "code." These reasons have their flaws.

Most software developers enjoy learning new languages, so the language difference does not ring true. 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. And since the build is part of the development process, there are some decisions about the build process that could make the code (or the coding process) simpler.

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. 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.

One valid rationale for treating build scripts as second class entities is that tools don't support working with build scripts as well as they do "real" code. While this may be true (less so as tools improve), the build is still essential to delivering software applications.

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.

Understanding 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.

By Steve Berczuk

This work is licensed under a Creative Commons Attribution 3

Back to 97 Things Every Programmer Should Know home page

Personal tools