c167s-steps

Steps in Writing a Script

A script is a kind of computer program. There is a lot of information and many classes where you can study how to develop a program in a systematic way. This is technically not a programming class, but it may be useful to review the programming process. When I develop a script to solve a problem, I like to follow a step-by-step, iterative approach. There are many tools that can be used. One of my favorites is something called pseudocode. Here is a short overview of flowcharts and pseudocode, and here is a comparison of flowcharts and pseudocode. I have written a slightly expanded version of version of the process with my comments below. (If you are already comfortable with program development, then feel free to skip to the end of this section. If you have a favorite summary that you would like to share, please post it or its URL to the class bulletin board).

You can think of the programming process as having five steps:

define the problem
design a solution
write the script
test it
decide if you are done. If you are not satisfied, then go back to a previous step. This will usually be step 3 or step 2. Sometimes you may end up going back to step 1 as well.

In order to define the problem, it is helpful if you know what the input is and what the output needs to be. Then your job is just to figure out how to produce the desired output from the given input. As you grow in experience and responsibility, usually you are given problems to work on with less clearly defined inputs and outputs. In that case you will need to talk with your users (whether they are your boss, coworkers, or customers) to clarify the problem definition so that it is clear enough so that you can try to solve it.

The second step is to design a solution. This too is an iterative process. Here are the steps I usually follow:

divide the problem into pieces.
then break each piece into smaller pieces.
do this repeatedly until each piece is small enough so that you can see how to translate it into a few Unix scripting commands.
then review all the pieces and see if they will work together. if not, then go through the process again.

Often I develop an initial solution using something called pseudocode. These is when you write out the steps you would use to solve a problem in English-like statements. You worry about the logic of the steps, not command syntax. (This is the kind of thing you might write on the back of an envelope or on a napkin at a restaurant when an insight into the problem comes to you.) Of course it has been often said that solving a problem is 1% inspiration and 99% perspiration. The bulk of the work is usually in the implementation and testing of your design.

The third step is to write the script. This is where you translate each piece of your design into corresponding Unix commands. If you write scripts frequently, then you will want to develop a library of functions that you can use repeatedly to help you solve problems more quickly.

The fourth step is to test the script. There are various kinds of tests:

This includes syntax-checking where you make sure you have written legal commands.
It includes input-checking, like those sanity checks we talked about earlier. How many checks to do often depends on the nature of the script. Is it a system-critical script ? Is it a production script or an ad hoc one ? Is it going to be used by many users or just by you ? Answering these questions can help you decide how thoroughly you need to check inputs and that each step of your program operates correctly.
It includes debugging your code. You need to think of ways to test your script to make sure it changes the inputs into the desired outputs correctly. This is where you make sure each section of your code works properly. You may want to use some debugging techniques to help you get the difficult parts of your code working correctly.
It includes testing for portability. If you are going to run your script on different versions of Unix, then eventually you will need to test it on each of those platforms. This where you can use techniques to increase the portability.your scripts.

The fifth step is to decide if you are done. After a test you compare the output you get with the output you want. If it matches, then you are done. If not, then you analyze the differences and decide which step you need to go back to in order to fix it.

For simple problems, we might take most of these steps automatically. I find it helpful to remember them for large or complex projects or whenever I get stuck.