The re-factor covers the whole OFBiz code base so we need a simple approach that makes it easy for people to pick up, re-factor and improve an area. This means that we probably wont be able to run it as a traditional linear project. Instead we will look to highlight areas of work where the community can help.
Main Approach
- Identify a list of 5 possible key re-factoring areas
- Ask the Community for volunteers to help re-factor in these 5 selected areas
- As one area is completed, we will top up the list of with another area so that the total will remain at 5
- Use of JIRA for tracking work (e.g open a master issue for each area identified and include individual sub-tasks)
Reasoning
- A short list of 5 is good number to highlight the key areas
- A list will help focus the community
- As one area is finished we can easily move to another
- Over time the initial re-factoring will make further re-factoring easier
Current Top 5 Re-factoring Focus Areas
The table below includes the list of the 5 areas we currently want to re-factor.
If you are interested in working (or are in the process of working) on any of these areas then please add your name in the column below.
AREA | REASON FOR RE-FACTOR | STATUS | WHO IS WORKING ON IT? | JIRA MASTER ISSUE LINK | COMMENTS | |
---|---|---|---|---|---|---|
1 | EntitySaxReader | EntitySaxReader implements javolution interfaces and looks hideous | ||||
2 | HtmlFormRenderer | HtmlFormRenderer is 3000 lines of code and the interfaces it implements are also huge | ||||
3 | XmlFormRenderer | XmlFormRenderer does not implement more than half of the methods | ||||
4 | Dependencies on Deprecated Classes / Constructors | Lots of dependencies on deprecated classes / constructors (e.g. HtmlScreenRenderer, FoScreenRenderer) | ||||
5 | Start.java | This has some problems which I'm trying to tackle in JIRA: OFBIZ-6783 | In Progress | Taher Alkhateeb | OFBIZ-6783 |
Other ways to help
If our top 5 areas seem a little too much for you to take on then you can help in other areas too, and a little bit of work quickly adds up. Below are some other ideas for helping remove clutter and help clean up the code base.
- - Obsolete / irrelevant comments: anything out of date
- - Commented out code: it belongs in the version control system
- - functions with too many arguments: anything beyond 3 arguments is probably too much unless there is a good reason for it.
- - functions that do too many things - multiple languages in the same text file
- - Big files / Big classes / Big anything really!
- - Duplication and cut-and-paste patterns
- - Mixed levels of abstraction: You can't declare high level stuff like starting the framework with details like flag parsing in the same place. Things should read like a story from high level down to the details. Main calls higher level functions which then call lower functions which executes detailed code.
- - Any concrete class not implementing an interface is probably a code smell, especially if too many dependencies point to it.
- - cluttered code, sandwiched in an ugly way
- - Pretty much all the Java warnings in the current code base
- - too much use of the "new" keyword instead of having a proper factory
- - writing to classes instead of interfaces - Confusing names for classes, functions, and variables. Things should be very clear and simple
- - Confusing test names - Lack of testing for any production code. Ideally, our tests should cover 100% of the code base.
- - inconsistent formatting conventions. Tabs instead of spaces, wrong number of spaces for indentation, and so on
- - Also, one of the worst things I usually encounter is hidden state. For example, you get hidden state in a Java class if the constructor declares a field that was not passed into the constructor. It makes the declaration hidden and the dependency obscure.