Framework Re-factor

Based on the feedback raised in on the mailing list discussion. http://ofbiz.135035.n4.nabble.com/Framework-Cleanup-Options-Tidy-Up-amp-Refactor-tt4676797.html#none . We would like to start some refactoring work to tidy and clean up areas of the framework.

What is the overall goal and what do we want to achieve?

Our overall goal is to tidy up the existing code to make it easier for us to maintain and improve.

What is re-factoring?

Refactoring is the cleaning, tidying or improving the existing code yet keeping the same functionality.

Why do we want to do this re-factoring?

Refactoring is something that tends to happen naturally over time as code evolves. We have identified some key areas that could really benefit from an refactoring effort so would like to promote these areas for active clean up and refactor.

The key benefits of any refactor is cleaner, neater and simpler code.

What sort of issues have been identified that the re-factoring could help with?

Looking at some of the OFBiz code we have identified some of the following:

• Some of the classes have been extended from external libraries into the Core APs
• Some of the files are too long
• Different levels of abstractions are mixed together
• Poor test coverage, lack of Test Driven Development
• Implicit (hidden) dependencies

It looks like a lot of work - is it worth it?

Yes, it will be a lot of work . There are a lot of areas that could do with re-factoring but if we can engage the community to help then this workload can be shared.

Yes, we do believe that it is worth the effort. The main benefit will be a cleaner, tidier code base that will allow us a lot the flexibility to grow and interface to a range of technologies easily. 

Want to help

Check out the Planning and Project Approach for details about the current activity.

Add your coordinates to the Current Team.

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.

Not sure where to start? Need more information?

 If you'd like to help out but are not sure where to start then please contact our development mailing list or leave a comment on this page.