How to decide when to script something rather than do it manually?_问答_开发者

Sometimes I find myself needing to do something that could be automated or could be manual. E.g. I just ran a particular script 8 times, making a small change in between each run. I certainly could have written a script that would have automated this, but in this instance I decided it was quicker to just run it manually each time.

But sometimes I realize after I've put a bunch of time into doing something manually that I'd have been better off automating it in the first place.

Any suggestions for rules of thumb that would help me decide, before 开发者_运维知识库I start some repeated process, whether it's worth investing the time to write a script to automate it?

For clarification: the kinds of things I'm talking about are sysadmin-type stuff like moving files around, renaming things, etc. and DBA-type stuff such as running a SQL script to import certain data (this is what I was doing today). Note that I'm a developer, not a sysadmin or a DBA.

I'm a fan of the "Three Strikes and you Automate" rule, as described at that link.

Reasons I have for scripting include

When:

you do it the second time
it becomes more than one step
it's easy to get wrong
it's easy to forget how to do it manually

Don't just consider the time savings you may or may not see in automating process. Also take into account the likelihood that running a process manually may result in errors.

Done properly, an automated process should minimize the chance of error. This might cause you to automate even if it doesn't result in a net time savings.

Of course the flipside to this is if a process is running automatically, be sure to keep tabs on it to make sure it hasn't gone off track.

Besides the obvious, one reason for writing a script is because the act of writing a script is more fun than doing the task even once -- and you may learn something in the process.

For many geeks, doing something clever, fun and interesting outweighs any other benefit; so in this case, automating the task may well meet those criteria, even if takes takes longer than doing the tasks manually!

If there is one system administration truism, it is this: no simple sysadmin task is fun more than twice. If you find yourself doing a simple dull task more than twice, automate it.

-- http://www.ibm.com/developerworks/linux/library/l-punix.html

Automation reduces source for errors if it's always the same set of operations that you perform repeatedly.

When I started with one of my (asp.net) project a couple of years ago, I had a manual release process that covered 3 written pages. Step by step I migrated that work into a build batch file (with command-line options etc to select single operations or everything).

Once the script was done, it performed flawlessly and it saved me an hour of manual work for each run.

And sometimes, it's only the fun of writing a script ;)

This is a site for developers.

If you think that you might need to do the same thing again, then automate it right now. But don't forget laws like YAGNI (You Ain't Gonna Need It) and avoid spending too much time on the automation. Just get something that works for you now with a little bit of coaxing.

Next time around, refactor and improve it, but only a bit. Remember YAGNI.

Third time around, try and get it in a nice little package where you can give it some inputs, and it will run to completion do sensible things on error conditions and log the errors.

And hopefully, you aren't using shell scripting but a real scripting language like Python where you can tweak the code and improve it ever time you use it, until it becomes a full-blown automation framework able to run remotely and manage thousands of servers from one invocation.

My rule of thumb:

if it feels tedious, spend a moment thinking aobut how you might automate it, how much work that would be and how much work it could save you.
If it would be very easy to automate or would obviously save a lot of work, start automating right away
If you decided not to automate and doing it manually becomes painfully tedious, or if you decide to automate but run into difficulties, think again, longer this time.

My rule is easy: In the long run, will I save time doing it manually or writing the script.

If you need to perform a specific task a few times only and then never again, it's probably not worth writing the script. But if you will need to perform the task repeatedly with only minor changes, scripting it will save you time.

Good programmers tend to be lazy, in that they try to do things with the least expenditure of effort and time. So if it'll save total time effort, it may be worth it.

My rule is this: script it when it becomes something that you no longer want to have to think about. If you're still doing it mindfully, still learning something about the process, or still particularly interested in the results, don't script it. But if it's become something that you just HAVE to do to get something done, and doing it is a chore, script the hell out of it.