In order to :
- improve the quality of the code
- reduce the noise in the build
- improve the design of the framework
- reduce the learning curve for new developers
we have adopted the following practices in re-factoring the framework.
No Warnings
Code should not be submitted for acceptance into the trunk with warnings unless there is a good reason
- dependency on deprecated code that can not be fixed without a functional change that is unacceptable.
Java provides these for a reason.
No missing or incomplete JavaDocs
JavaDocs help in three major ways.
- They force the person writing them to think about the design and come up with a clear explanation of what the class or method is supposed to do.
- They allow a reviewer to more easily understand the reason for the class or method so it can be assessed for complexity, level and need.
- They give a person who needs to use the method an easy way to understand the functionality and use case that the class or method addresses
These are particularly important during a re-factoring when a lot of changes are being done quickly and everyone needs to be on the same page to avoid big problems.
Test-driven development