Java: Development Process
Software development can be looked at from two perspectives
- Process - How to organize and do the work of programming.
- Product - What is actually produced.
Process is how you go about writing programs.
Product is what is actually produced, ie, the source program.
Most programming books,
as well as these notes, are concerned primarily with the programming
elements that make up the product, eg,
the syntax of the switch statement
, how to use a loop, etc.
To be successful, you need to produce programs,
but you also have to master the software development process.
The bigger the problem, the more important good process is. In small programs you can use just about any development technique and you can succeed. As your programs become larger, you'll find that using the right process techniques becomes more and more important.
What are the best process practices?
- Understand the problem.
- Use iterative and incremental programming.
- Set aside blocks of time without interruption.
- Use debugging techniques (assert, println, breakpoints).
1. Understand the problem
2. Use Iterative and Incremental Programming
The iterative process is used by many top developers. It's very effective in producing programs not only faster, but with better quality.
- Start small - Start with a small working program. It doesn't have to do what you want, but it will get you started along the path of incremental development. See Start with a working program.
- Iterative development - After you have a small program, make a very small change toward your goal. Compile it and test it. When it works repeat the process with another small change. Also called Iterative Programming. See Iterative/Incremental Development.
3. Set aside blocks of time without interruption
Most ideas about good work habits apply to programming as well, but there is something different about programming than many activities -- you have to juggle a lot of stuff in your head at once. It takes a little while to wrap your mind around the programming issues, and if you get interupted, it all comes crashing down, and typically takes a while to restart.
See Paul Graham's Holding a Program in Ones Head.
Testing
There are several aspects to debugging.
- Does your program produce the correct results with good data? A surprising number of students believe their program works, when it actually fails. This is especially true when you can't easily calculate the correct result in your head. How are you going to test a program that computes the volume of sphere from the radius? You need to compare it against a known correct value.
- Test both normal values and also the extreme values.
- Happy Trails programming is to write programs and not worry about bad input data. This is OK in begging courses, but soon you will have to make sure the data is good with if statements, exceptions, etc.
- TDD - Test Driven Development
- Test coverage
- Testing tools
- Fail-fast
Debugging
Everyone writes programs with bugs in them. The goal is to catch them as soon as possible.
- Assert statements
- System.out.println
Strive for simplicity
- KISS. Keep it Simple Stupid. Simplicity is a great virtue in software. There's a huge amount of writing on the virtues of simplicity. [TODO: Put some links in here.] Joel Spolsky has another take on it at Simplicity.
- DRY princlple - Don't Repeat Yourself.
- YAGNI. You Aren't Going to Need It (or You Ain't Gonna Need It in slang)
is the principle of never adding a feature unless it's really needed.
Don't add a feature because it's easy, cool, or whatever.
There are hidden costs associated with everything you add.
- The Wikipedia article, You Ain't Gonna Need It lists this costs quite nicely.
- Some amusing little Gedanken conversations illustrate the YAGNI principle quite clearly at the XP site (originators of the phrase I believe). You Aren't Gonna Need It. The introduction is followed by many well-stated opinions on YAGNI - mostly positive, but with some dissent.
Have others read your code
The value of having someone other than the original programmer read code has been well demonstrated -- this second reader often notices problems or issues with the code, resulting in a much better program. This is hardly a surprising result, and it is used effectively in many areas of human endeavor.
Pair programming carries this to the extreme, where two programmers sit at one computer. The two are discussing the code, and one is writing doing the typing. The non-typist is reading the code and thinking about cases that aren't handled, etc. With a compatible pair of programmers, this can be extremely effective in producing good programs, more than paying for the cost of two programmers to write on piece of code. Of course, the wrong pair of programmers is not going to be effective. See Wikipedia's Pair Programming.
Use good coding practices
At the beginning level, simple things like good naming and indentation are very important. But there are many things involved in good coding. See Google Java Style Guide.
Refactoring = Making internal improvements
Refactor (rewrite) parts of a program wherever you can can see that internal improvements can be made. This is about internal issues, not about adding features, and refactorings are often about making the program simpler or easier to understand (simpler, easier to understand, faster, easier to modify, more portable, ...). Refactoring A better written program will be less likely to have bugs and will be easier to extend for the next iteration.
Renaming variables, methods, and classes is one of the easiest, most common, and most effective techniques for improving a program. It sounds too simple, but it's surprisingly effective.
Use good tools
The right tools can save you a lot of grief. It's not enough to just choose good tools; you must also learn to use the well.
- Use an IDE (Integrated Development Environment), eg IntelliJ IDEA or any of many other IDEs.. A Java IDE requires learning, and therefore may not be a good choice for beginning programmers. However, after you are comfortable developing simple Java programs with a text editor and the JDK, the advantages of an IDE for creating user interfaces and debugging can be significant. As with all tools, learn to use it well. Check the menus for options that might be useful.
Best Practices Resources
In any field the most effective techniques become enshrined as Best Practices. There are lots of good books (and lots that aren't good!). Here are some that I've found very good, and all of them are very readable, even enjoyable!
- Code Complete second edition by Steve McConnell, Microsoft Press, 2004. Don't be put off by this being a Microsoft book. It's full of wonderful coding and process advice that you can use after your first programming course.
- The Pragmatic Programmer by Andrew Hunt and David Thomas, Addison-Wesley, 2000. Filled with good product and process advice for the intermediate+ programmer.
- Rapid Development by Steve McConnell again, Microsoft Press, 1996. This is still great, tho it could use a little updating in view of some "agile" development methodologies like Extreme Programming. This is filled with facts that everyone who works on or manages a major software development should read.
Data-driven programming
See Table-Driven and Data Driven Programming for a (too) brief summary of data-driven (also known as table-driven programming.