(^126) 97 Things Every Programmer Should Know
Own (and Refactor)
the Build
Steve Berczuk
iTT iS NO UNCOMMON for teams that are otherwise highly disciplined about
coding practices to neglect build scripts, either out of a belief that they are
merely an unimportant detail or from a fear that they are complex and need to
be tended to by the cult of release engineering. Unmaintainable build scripts
with duplication and errors cause problems of the same magnitude as those in
poorly factored code.
One rationale for why disciplined, skilled developers treat the build as some-
thing secondary to their work is that build scripts are often written in a differ-
ent language than source code. Another is that the build is not really “code.”
These justifications fly in the face of the reality that most software developers
enjoy learning new languages, and that the build is what creates executable
artifacts for developers and end users to test and run. The code is useless with-
out being built, and the build is what defines the component architecture of
the application. The build is an essential part of the development process, and
decisions about the build process can make the code and the coding simpler.
Build scripts written using the wrong idioms are difficult to maintain and,
more significantly, improve. It is worth spending some time to understand
the right way to make a change. Bugs can appear when an application is built
with the wrong version of a dependency or when a build-time configuration
is wrong.