31.3.1. Development process and other important procedures

31.3.1. Development process and other important procedures
Prev	31.3. Coding rules and guidelines	Next

This section describes the development process we try to use in the BASE project. It is not carved in stone and deviations may occur. For every new feature or enhancement the procure below should be followed. If you encounter any problems, arrange a group meeting. Someone else may have the solution! The text is biased towards adding new items to BASE, but it should be possible to use the general outline even for other types of features.

1. Group meeting

The group should have a short meeting and discuss the new or changed feature. Problem areas should be identified, not solved!
The person who is going to make the analysis, design and development is responsible for taking notes. They should be kept until the analysis and design phase has been finished.
A follow-up meeting should be held at the end of the analysis phase.
A single meeting may of course discuss more than one feature.

2. Analysis and design

Create an diagram of the classes including their properties, links and associations. Use the already existing diagrams and code as a template. The diagram should have information about cache and proxy settings.
Write a short document about the diagram, especially things that are not obvious and explain any deviations from the recommendations in the coding guidelines.
Identify things that may affect backwards compatibility. For more information about such things read Section 29.1, “The Public API of BASE” and Section 31.3.3, “API changes and backwards compatibility”.
Identify what parts of the documentation that needs to changed or added to describe the new feature. This includes, but is not limited to:
- User and administrator documentation, how to use the feature, screenshots, etc.
- Plug-in and core developer documentation, code examples, database schema changes, etc.
If there are any problems with the existing code, these should be solved at this stage. Write some prototype code for testing if necessary.
Group meeting to verify that the specified solution is ok, and to make sure everybody has enough knowledge of the solution.

3. Create the classes for the data layer

If step 2 is properly done, this should not take long.
Follow the coding guidelines in Section 31.3.4, “Data-layer rules”.
At the end of this step, go back and have a lock at the diagram/documentation from the analysis and design phase and make sure everything is still correct.

4. Create the corresponding classes in the core layer

For simple cases this is also easy. Other cases may require more effort.
If needed, go back to the analysis and design phase and do some more investigations. Make sure the documentation is updated if there are changes.

5. Create test code

Build on and use the existing test as much as possible.

6. Write code to update existing installations

	Important
	If the database schema is changed or if there for some reason is need to update existing data in the database, the `Install.SCHEMA_VERSION` counter must be increased. Add code to the `net.sf.basedb.core.Update` class to increase the schema version and modify data in existing installations.

7. Write new and update existing user documentation

Most likely, users and plug-in developers wants to know about the feature.

	Important
	Do not forget to update the Appendix K, API changes that may affect backwards compatibility document if you have introduced any incomaptible changes.