Access to add and change pages is restricted. See: https://cwiki.apache.org/confluence/display/OFBIZ/Wiki+access

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

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

 

 

  • No labels