1. Introduction
This page is explicitly not designed to be an introduction into any of the here mentioned technologies. Please do not extend it in that direction. It should be a concise checklist for best-practices. Introductions and tutorials will be found elsewhere.
Also get the RSS feed of our SE-best practices BLOG to stay in touch with new concepts and ideas.
2. Modeling, Conceptual Phase
For "Brainstorming" and creating concepts, we suggestFreemind as Mind-Mapping software. For UML modeling we suggest... For ER models we suggest...
3. Open Source Driven Development
All used libraries and tools should be under an Open Source license wherever possible! Proprietary tools may only be used after discussion with the supervisor.
Only non-invasive Open Source licenses should be used for libraries, i.e., no libraries under GPL-like licenses.
4. Software Patterns
Every developer should be comfortable with at least the following patterns, and of course, use them appropriately:
Delegation, Interface, Marker, Proxy, Immutable
Factory, Singleton, Object Pool
Proxy
Container, Dependency Injection, Facade, Decorator
Observer/Observable, Event Listener, Iterator, Visitor
Data Access Object, Lazy Load, Transfer Object, Model View Controler
These are the most important. If some should not be familiar, we recommend one of the many books describing Software Patterns.
5. Repository
For Sourcecode and project related documentation Subversion is used. Clients exist for all major platforms and integrated development environments.
It is important to update the own codebase every time before coding is done; as soon as a development step is done (latest after one day) a functioning new version has to be committed. (All tests should run successfully)
Changes in the own code, that potentially affect other developers have to be communicated!
6. Build Automation
For Build-Automation in Java projects useApache Maven 2.
Maven should be used according to the suggested best-practices. This means e.g., that default settings for directory structure and so on should be kept.
A project should do (at least) the following steps with a standard Maven call:
- Build the Project
- Create Distribution (tar.gz, zip...)
- Run Unit Tests
- Create Documentation
- Javadoc API Documentation
- User Documentation
- Results of Unit-Tests
7. Integrated Development Environement
In our group typically Eclipse is used for development. However, the developed software has to be independent from the used IDE and has only to rely on Apache Maven.
Hence it is recommended to generate the IDE project file (e.g., the one from Eclipse) using Maven.
8. Logging
For Logging use Apache log4j
The log-configuration has to be kept in a log.config file.
9. Documentation
9.1. General Comments
All documentation has to be kept in English! All documentation artefacts have to be done using Open-Source tools. E.g., UML diagrams, architecture overviews, reports and the like, i.e., do not use Microsoft office but Open Office, Argouml...
9.2. Application
Applications have to be documented according to the Javadoc standard. This includes documentation of all methods, all packages, all interfaces ...
9.3. Project Documentation, Userdoc, Installation...
Project Documentation has to be done according to Maven standards using the Maven System.
10. Testing
Development has to be done test-driven. This means:
Usage of unit tests using JUnit wherever it makes sense
- Tests should be written before implementation of a feature
For parts of the application that are not reasonably testable with JUnit other test-option have to be worked out (e.g., JMeter tests for Webapplications)
11. Container
Software should be developed writing componets according to best practices with the Spring-Framework.
12. Persistence
For persistence several options are feasible, depending on the complexity and type of the problems. Use one of the following:
12.1. Relational Database based
Apache iBatis O/R Mapper (SQL centric)
Hibernate: "full-blown" O/R Mapping (more effort, particularly for larger projects)
Use Spring support for the according technologies including declarative transaction management.
As relational database Apache Derby should be used.
12.2. XML
- SAX for "simple" streaming problems
dom4j when a DOM implementation incl. XPath support is needed
Castor when XML binding is appropriate
Use DTDs or better W3C Schemas, when a schema definition is required.
13. User Interface
13.1. Web-based Systems
Web-based systems have to be developed with Java Server Faces, using the Apache myFaces Framework and Spring.
As servlet engine Apache Tomcat should be used.
13.2. Web 2.0
If JSF with appropriate Ajax libraries appear not to be fitting for the solving the problem, i.e., for "richer" "Web 2.0" applications Open Laszlo is suggested.
13.3. "Fat Client"
For "fat clients" use either "plain" Swing, or write an Eclipse Rich Client using SWT.
14. Service Oriented Architecture
14.1. Webservices
For Webservices check out Apache Axis and particularly also XFire. Also Spring has support for Webservices.
14.2. Messaging
For messaging use JMS and the ActiveMQ library from Codehaus. In case, more integration features are needed, i.e., a Enterprise Service Bus is required use Mule (also from Codehaus).