Should every target have a secret?

Should every target have a secret(image taken from electricinca’s photostream)

There’s a question that I wanted to ask you, dear reader. Consider the following code snippet:

<project name="my_great_web_app">
<!-- snip -->
<target name="backend-zip-static">
<zip zipfile="${build}/backend-static.zip">
<fileset dir="${backend.static.dir}"/>
</zip> </target> </project>

Some of my erstwhile ThoughtWorks colleagues used to use the motto “Every class should have a secret”. Recently I discovered that this evolved from work on Information Hiding by David Parnas:

In computer science, the principle of information hiding is the hiding of design decisions in a computer program that are most likely to change, thus protecting other parts of the program from change if the design decision is changed. The protection involves providing a stable interface which shields the remainder of the program from the implementation (the details that are most likely to change).

(from http://en.wikipedia.org/wiki/Information_hiding)

So OO developers believe that classes should contain secrets, should targets in your build have secrets? Does that mean that you shouldn’t expose (in the name of the target) how a target does what it does? In this example, how about backend-static-archive as a target name instead of backend-zip-static ?

The example above came from a real project. We changed the way we deployed the app, and had to painstakingly rename the target and its references across a hierarchy of build files. There was definately more than one issue with the build at that project: we shouldn’t have had such a large collection of build files. Them’s the breaks.

Should you ever expose the process that you apply inside a target? Or should the name of the target just describe the output? What do you think?

3 thoughts on “Should every target have a secret?

  1. Jeffrey Fredrick says:

    Great post Julian!I’m usually trying to convince people that “tests are code” and need to be treated with as much care when it comes to design, refactoring, maintainability, etc.Couldn’t agree more that “builds are code” is just as true.

  2. Eric Lefevre says:

    Yes, I think you are making an excellent point.That said, I’d balanced it with the fact that you sometimes need ‘technical targets’ for which you would need technically explicit names, just like private methods.Of course, the limitation is that you cannot easily hide those technical targets from the reader/user of your Ant targets.I know you are not a bug fan of Maven, but that seems to be something they got mostly right.

  3. Julian says:

    Eric, I know what you mean. I’m not against Maven but I never thought that it was appropriate for any of my projects. Once of these days I’ll have to have a proper look. I think it’s still the only build solution that will easily trigger a CruiseControl build when dependencies change.

Comments are closed.

%d bloggers like this: