Project Approach

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 approximately 10 key re-factoring areas (5 easier, 5 more difficult)
• Ask the Community for volunteers to help re-factor in these selected areas
• Tick off each area as it is completed
• Use of JIRA for tracking work (e.g open a master issue for each area identified and include individual sub-tasks)

• Use of JIRA to organise sprints if required

Reasoning

• A short to-do list of is good number to highlight the key areas
• A  list will help focus the community on what needs to be done
• As one area is finished we can easily move to another
• Over time the initial re-factoring will make further re-factoring easier

Current List of 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.

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.