|
Roan Says:
I've noticed lately that a lot of people are studying programming languages and computers without ever really learning how to write a program. Designing and writing software is the "art" part of programming and it's much harder to learn from books than the "science" part. One can learn by studying other people's programs (good and bad) and writing some of their own. It also helps to have a mentor to make suggestions and provide criticism (positive and negative). The very first step in writing a program is to understand exactly what the program should do and put that information in some form that is easy to refer to while writing the program. Now, this might seem glaringly obvious but many people just skip right past this step and write software without ever really knowing what the program should do. There are some techiques that work very well for defining what a program should do. Just to name a few, one can write a list of actions that the program should take, or one can describe the data that the program starts with and then produces. For a more complicated program, one can divide the program's requirements into separate parts and describe each part in detail plus the overall program. Sometimes pictures or drawings of displayed information or forms used to interact with the program can define the exact interaction between a user and the program. The next step in writing a program is to decide how the program will do the things that it is supposed to do. This is essential because you can't write software unless you have some idea how the software is going to work. In some cases there may be many alternatives, from a very brute-force, simple approach to a complicated elegant approach. To be successful one must have a thorough knowledge of some key prgramming techniques such as variables, arrays (tables), expressions (calculations), loops, conditional tests, user input and output, and file access. Which of those programming elements are chosen will have a large impact on how smoothly the program can be implemented. Part of this process is defining how information will be represented in the program. For some database programs, the data design can be the majority of the job, and the program may be nearly obvious from the database design. Next we get to program structure. For anything but the smallest programs, the structure (how the parts fit together) is an important part of the design. What are the major parts of the program and how much will they interact. What are the key data items and how will they actually be represented in the language. What will be the layout of the data and how will the data travel through the parts of the program. Implementation is the actual writing of the software (program). Many people jump right into this without bothering with the preceding steps. Before starting the implementation one should understand what the program should do, how it will do that, and what major software and data elements are required. The decisions here should be limited to how to use the language to implement the procedures that were decided on during the "how to do it" part of the program design. For example, you should already know if you need a loop to process information for each customer in a database, but you might have to decide what language statements will define the loop. Testing and debugging. Depending on the size of the program it may be better to write and test each part, or write the entire program before testing it. There are two places where problems can occur. The compiler may report errors in how the language was used. Once the compiler accepts the software, then the software may not work correctly. It's a long standing programming joke that you should be really worried if you get no compiler errors. That means the program is almost sure not to work right. It's even worse if the program also appears to work correctly. That means there are subtle problems that you haven't found yet. There are a lot of different testing approaches that you can use and they all have some benefit. - Test with a few different sets of correct information - Test with information near the limits of data (size, min/max values, etc.) - Test with incorrect or invalid information - Design specific tests for the internal decisions and data formats (white box testing) - Design tests without any assumptions about the program internals (black box testing) Very few programs are "perfect" if ever. One can almost always find some situation where a program doesn't work in a desirable way. The trick is to know when the program works well enough to satisfy the requirements with a little bit of thought to the likely errors and possible additions to the program. It helps to review software after it's finished and have colleagues look at it. You have to decide what criticism is correct and if you should do something about it now, or in the future. The second or third time that you write a program it will almost always be better. Why don't people write programs three times? Usually they don't have the time and the program is already good enough to use. When you start out writing software, you might want to consider always writing a program a second time after reviewing the first (working) version of it. Now a few comments about the real world. Unfortunately many managers view the design part of programming as "wasted time" and focus on how much "code" a programmer has typed in at the moment. In some cases I've had to actually start writing software knowing that what I was writing would be thrown away later when I had finished the design. Sometimes you have to dive in and start writing software for appearances sake. Be careful that you do that fully aware that you are probably writing worthless code. Sometimes that's necessary to perform "experiments" to decide which design approach works best. Try to resist the urge to use software that you just dove into and wrote because you will usually get much better software if you design the software first. You can often use the "throw away code" as a guide to show you what things worked and what could have been done better. When you're learning to write software, it's perfectly fine to "play" and write some short functions or programs to experiment and learn. Just be careful that you don't use that approach to designing and writing all programs. If you think about it you can even apply some of the good programming practices to your experiments. Just do it on a smaller scale, or with a bit less attention to detail. Programming really is an art. You may find that you are better at writing certain kinds of programs and not others. It may take you longer to write some kinds of software than others. The way that you think and approach a programming task may be totally different than someone else. Try to keep an open mind and learn from other people. If something seems completely foreign to you it might be worth looking at. You don't have to choose the design approaches used by other people, but it can help to know them along with the pros and cons. The more that you study well written software and practice designing and writing software, the better you will get. |