(^156) 97 Things Every Programmer Should Know
Step Back and
iORKED W WiTH PROGRAMMERS WHO, when asked to produce a count of
the lines of code in a module, pasted the files into a word processor and used
its “line count” feature. And they did it again next week. And the week after.
It was bad.
I worked on a project that had a cumbersome deployment process, involving
code signing and moving the result to a server, requiring many mouse clicks.
Someone automated it, and the script ran hundreds of times during final test-
ing, far more often than anticipated. It was good.
So, why do people do the same task over and over instead of stepping back and
taking the time to automate it?
Common misconception #1: Automation is only for testing
Sure, test automation is great, but why stop there? Repetitive tasks abound
in any project: version control, compiling, building JAR files, documenta-
tion generation, deployment, and reporting. For many of these tasks, the
script is mightier than the mouse. Executing tedious tasks becomes faster
and more reliable.
Common misconception #2: I have an IDE, so I don’t have to automate
Did you ever have a “But it (checks out/builds/passes tests) on my
machine?” argument with your teammates? Modern IDEs have thousands
of potential settings, and it is essentially impossible to ensure that all team
members have identical configurations. Build automation systems such as
Ant or Autotools give you control and repeatability.