Own (and Refactor) the Build

From WikiContent

(Difference between revisions)
Jump to: navigation, search
Line 1: Line 1:
-
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.
+
Often teams that at highly disciplined about coding practices either neglect build scripts or treat them as a black art. Unmaintainable build scripts with duplication and errors 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.
+
One rationale 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 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 without 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 some decisions about the build process that could make the code (or the coding process) simpler.
-
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.
+
Build scripts written using the wrong idioms are difficult to maintain and, more important, 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. 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.
-
 
+
-
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.
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.
+
Understanding the build can simplify the entire development lifecycle and reduce costs. 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.
+
Learn enough of your build process to know when and how to make changes. Build scripts ''are'' code and are too important to be left to someone else, if for no other reason than because the application is not complete until it is built, and the job of programming is not complete until we have delivered working software.
By [[Steve Berczuk]]
By [[Steve Berczuk]]

Revision as of 22:50, 28 December 2008

Often teams that at highly disciplined about coding practices either neglect build scripts or treat them as a black art. 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 something secondary to their work is that build scripts are often written in a different 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 without 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 some decisions about the build process that could make the code (or the coding process) simpler.

Build scripts written using the wrong idioms are difficult to maintain and, more important, 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. 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.

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 the entire development lifecycle and reduce costs. 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 and how to make changes. Build scripts are code and are too important to be left to someone else, if for no other reason than because the application is not complete until it is built, and the job of programming is not complete until we have delivered working software.

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