Tip 1: Design Everything Upfront

This goes against the grain of agile methodologies, but as students it will serve you well. Experienced developers will be able to deal with the technical complexities of software development, which is why agile methodologies focuses on the people aspect. It expects competent programmers. The way our groups were assigned, even if you are competent enough, the rest of your team isn’t.

Designing up front, helps reduce the amount of changes later on. Changes to your database schema can be costly later on in the project. Experts have tools and processes in place to cope with change in an agile team, whereas you don’t. Fix your ER (Entity Relationship) diagram early on and create your database schema.

Tip 2: Create your User Interface

It is part of your requirements so do it. I heard of some teams that want to do functionality first, and then tack on the interface once it is done. Don’t do that, unless you’re into torturing yourself. How are you doing to develop functionality when you don’t even know what the end result is? If you do, you will definitely need to rework everything once you realize that users are going to hate your system.

You may counter, saying that with a properly designed MVC (Model View Controller) application, you can design your UI independently of the rest of the application. But then again, you need the user interface before you can properly design it like that. While I was working on the UI, I fixed a lot of problems before they actually manifested.

Tip 3: Use Hibernate

I’ve written two articles that will help you get started, and the third one will be coming up next week. Without Hibernate, you will have to manage JDBC connections and SQL statements. At best, they’re a hassle, and you don’t want to know how bad they can be. They’re not that difficult, but if you don’t have to deal with them, why bother at all?

You may groan and say that the learning curve is steep for Hiberate, but if you take a step back and learn it as a team, it isn’t that bad. The effort spent learning it will pay off in the end. Remember, the best code, is no code. Hibernate replaces a lot of code that you will have to keep creating over and over again. Plus, you will have more bugs in your own code than if you were to use a framework to do the same thing.

Tip 4: Practice good Subversion

I’ve written an article on this as well, but I want to put across the message more clearly now that Subversion is a collaboration tool for groups. Your actions affect others; if you break the build, and other developers update and cannot continue working on the updated code, they will update less often. When they update less often, there’s no point in using Subversion.

Subversion is not yet another way to transfer files. You can use email and thumb drives for that. Subversion is a collaboration tool and if you still don’t know what the difference is, you’ve got to go back to the basics. To reiterate, commit early and often and make sure you don’t break the build.

On a side note, sometimes, you may have to break the build especially in the early stages of setting up the project. That’s fine so long as you fix it before real development begins.

Tip 5: Use Sitemesh

Sitemesh helps you with layouts. Chances are, you will have a layout that is consistent throughout your entire application. If you don’t, well, good luck. Head over to their website to download and follow these articles:

• http://today.java.net/pub/a/today/2004/03/11/sitemesh.html
• http://www.rkcole.com/articles/struts/crudTutorial/step4.html
• http://java-x.blogspot.com/2006/11/using-sitemesh-with-struts-20.html

Tip 6: Follow Naming Conventions

Have a convention for everything and follow it to the letter. In my team, I even have a convention for leaving commit logs in Subversion so you know how pedantic I can get.

Whereas the commit logs aren’t all that important, it is useful to follow conventions everywhere else in code. Servlets start with capital letters, JSPs with all low caps, words separated by an underscore. Choose variables names that describe its function and not expletives that best describe your mood. So on and so forth.

Remember that you are working with other people, and that they will have to read your code as well. By establishing such rules, developers on your team can more readily understand code that follows conventions by nature of their familiarity with the convention. Ultimately, this helps in reducing the number of bugs introduced.

Tip 7: Use NetBeans

You can switch to your favorite IDE (Integrated Development Environment) here, as long as it is integrated. No, notepad+tomcat+mysql is not integrated. Also, I’ve seen other students with problems with Intelli-J being too intelligent, and since most of us are using NetBeans, it will be easier to seek help should you need it.

NetBeans can help you do a lot of things that will save you a lot of time. Learn to use it well.

Tip 8: Use Indentation to your Advantage

It irks me no end when students simply type away without following the indentation rules. Usually, their response will be that the IDE didn’t indent to the position where it was supposed to, and thus they formulated a bright idea to just left indent everything. If the IDE didn’t indent correctly, it means you have a syntax error. Instead of generating bright ideas, go and fix the syntax error.

On a side note, NetBeans has a function that will help you format your codes nicely, which is what I use. However, while I am typing, I still make sure to follow proper indentation. Like naming conventions, you cannot be too strict on this.