- Learning to Program—The stages of programming
- Learning to Program – Some Terms You Should Understand
- Learning to Program – IPO Charts (Stage 1)
- Learn to Program- Flowcharting (Stage 2)
- Learning to Program – Flowcharting (Stage 2). — Decisions and Loops
- Learning to Program—Flowcharting (Stage 2) – Case Statements
- Learning to Program (Stage 2)—Flowcharting – Methods and Classes
- Learning to Program – Structure and Spaghetti Code
- Learning to Program – Pseudocode (Stage 3) an overview
- Learning to Program – Stage 3 Pseudocode commands and reserved words
- Learning to Program—Stage 3 Pseudocode examples Part 1
- Learning to Program – Stage 3 Psuedocode (Arrays)
- Learning to Program – Stage 3: Pseudocode—Methods
- Learning To Program—Stage 3.5 (UML Diagrams)
- Learning to Program – (Stage 4) Coding
- Learning To Program—Stage 5 Testing
- Learning to Program—Stage 6 (Documentation)
- Learning to Program – Stage 7 (Maintenance)
- Learning to Program—Random Thoughts with a Theme
- Learning to Program- Two Main Types of Errors
- Learning to Program – Integrated Development Environments (IDE’s)
- Learning to Program
Stage 7 is probably the strangest stage. Why do I say this? Because maintenance means a lot of things. If the program is decently coded and no bugs are found, then the maintenance stage basically means leaving it sit. However, if bugs are found, then you will be going back through Stages 5 and 6 to correct them. And if more (or new) features are requested, then you may have to go back through all of the stages to complete the task.
At some point, maintenance actually becomes a whole new concept with it’s 7 stages. Although most of the hard work will be done already, so it won’t be as involved as the original coding process. One thing that you can do to ensure the ease of maintenance is to plan for the future of the program when you are designing it.
The concept of looking three steps ahead applies in chess and coding. As you’re designing the program in the early stages, consider the other things that you would throw into the program (if you could). Design the code so you can incorporate them into the program—if someone requests it.
But don’t go overboard with this. You don’t need (or want) to create empty classes for these items. But you want to code the program in such a way that you can add classes (and interfaces to those classes) with minimal rewriting. As you are creating your classes, decide if any of them could be easily tweaked to add features. If so, then design them in such a way that you can add those features.
Even now, when the idea of code optimization isn’t the “in thing” (because of large amounts of memory and CPU power), you should code in such a way that future versions will not increase the footprint dramatically. I would suggest coding for optimization anyhow.
Coding for optimization is similar to how people coded in the 80’s and 90’s. There was very little memory available to them, and the CPU’s weren’t as powerful (or capable) as they are now. So, the programmer optimized the code in such a way that it accomplished a lot without requiring a lot to do it. In short, it means that if you can code something to use 1MB of memory, why would you code it in such a way that it uses 3MB?
Have a great day:)