Java: Development Process
Software development can be looked at from two perspectives
- Process - Techniques for doing the work of programming.
- product - The actual programming language elements.
Process is how you go about writing programs. Product is about the programming structures themselves (types, statements, classes, ...). Most programming books, as well as these notes, are concerned primarily with the product, eg, how to use a loop in a specific programming language. To be successful, you need to know how to use the programming language, but you also have to master the software development process.
There are basic program development techniques which make program development much easier, and which are used by professional programmers for maximum effectiveness.
Iterative and Incremental Programming
"The longest journey starts with a single step" - Chairman Mao
The following is advocated by many top developers. It's really 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 - Starting with 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.
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.
- 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 Java Coding Standards.
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, DrJava, NetBeans, Eclipse, or JBuilder (see 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.
- Code Coverage Tools [Needs more]
- See http://homepage.mac.com/hey.you/lessons.html, Tony Obermeit on Code Coverage Lessons.
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.
- Here's a nice blog entry I ran across.
Here are a few things I have learned about programming computers, in no particular order. I didn't invent any of them, and I don't always follow them. But since nobody seems to know very much about making good software, it makes sense to try to distill a little wisdom when possible.