This page contains the current list of the tasks that need to be done as part of the Framework Re-Factor. The goal is the allow volunteers to select a task and provide a patch that will resolve each of the tasks listed. The list of tasks have three degrees of complexity (Difficult, Moderate and Easy) allowing contributors at any level to participate.

To pick up any of these tasks

1. Add your name to the "Who is working on it" column
2. Create a JIRA Issue for the task (e.g use the name or area as the title and copy the what needs to be done into the issue description)
3. Remember to use the trunk as the code source for your re-factor and patch

In order to improve the quality of what is being re-factored, please note that for each task the developer should also:

• Write unit tests for every line of code being re-factored.

REF	NAME OR AREA	WHAT NEEDS TO BE DONE	COMPLEXITY	STATUS	WHO IS WORKING ON IT?	JIRA MAST ISSUE LINK	COMMENTS
1	remove dead imports	Remove all unnecessary import statements in all java files	Easy	Fixed	Michael Brohl
2	Fix resource leaks in CommonServices.java	File1 and file2 should be fixed by closing them in byteBufferTest	Easy	Fixed	Michael Brohl
3	Remove deprecated dependencies in EmailServices	org.ofbiz.common.email.EmailServices.java depends on FoScreenRenderer and HtmlScreenRenderer. Both should be replaced by MacroScreenRenderer.	Moderate	Fixed	Deepak Dixit
4	Simplify getChildHRCategoryTree	The method getChildHRCategoryTree in org.ofbiz.humanres.HumanResEvents is too long and complicated. The business logic can be considerably reduced and simplified. The function should be broken down into multiple private functions to simplify the calls and to create the right level of abstraction	Moderate	Fixed	Kulwant Singh
5	Add Generics to PaidInOut	In ofbiz.pos.screen.PaidInOut.java the DefaultComboBoxModel is not parameterized. Need to put the right generics in place	Moderate	In Attic	Jacques Le Roux
6	CommonWorkers.java needs simplifying and cleaning up	Refactor CommonWorkers.java. Lots of code is repetitive and can be factored out into shared private methods. This includes things like: Exception handling Queries Building the return data structures	Moderate	In Progress	Martin Becker
7	Cleanup FindServices.java	Many problems exist in this file: Commented out code should be removed File is too big, need to be broken down Ugly business logic in most of the functions which can be simplified considerably Delegator code needs to be isolated and side effects kept down to a minimum	Moderate		Malin Nicolas
7b	Refactoring permission service	Homogenise the call to permission service by ModelService. Clean deprecated code	Moderate	In Progress	Malin Nicolas
8	Parameterize everything in DebugManagedDataSource	Generics need to be introduced to multiple places. Requires knowledge in commons-pool	Moderate	In Progress	Martin Becker
9	XML shared dependencies between accounting and HR	Many shared dependencies exist bi-directionally between accounting and HR including screens, entities and other items. All such XML should propagate down to the commonext component	Moderate		Pranay Pandey
10	Redesign EntitySaxReader	org.ofbiz.entity.util.EntitySaxReader requires refactoring to achieve the following goals Refactor EntitySaxReader to an interface Create an implementing class Remove all dependencies on Javolution Fix all dependencies in the framework to match the new signature of the interface Delete the javolution library from the framework	Difficult	In Progress	Martin Becker
11	Redesign org.ofbiz.entity.datasource	All objects under org.ofbiz.entity.datasource need to be redesigned into an interface model and implemented with concrete classes. Things like the GenericDao should be broken down to many pieces as it is massive, complex, and overly designed (Interface Segregation principle violated)	Difficult		Mridul Pathak Divesh Dutta
12	XML shared dependencies between accounting and order	Many shared dependencies exist bi-directionally between accounting and order including screens, entities and other items. All such XML should propagate down to the commonext component	Difficult		Pranay Pandey
13	Start.java	This has some problems which are being tackled in JIRA OFBIZ-6783	Difficult	Fixed	Taher Alkhateeb
14	Enforce noninstantiability to all Utility classes	Design flaw needs to be fixed on all Utility Classes, discusses over mailing list.	Moderate	Fixed	Rishi Solanki Arun Patidar		All
15	harmonise permission applications in widgets	Many permission definitions are hard coded in widgets (e.g. menu-items and screens), e.g. <condition> <if-has-permission permission="ACCOUNTING" action="_ADMIN"/> </condition> Many of these kind of 'default' permissions definitions could be harmonised by application of the ${activeApp} variable.	Moderate		Pierre Smits
16	Refactoring UI	Review and improve the UI for more flexibility and user friendly, see dedicate wiki page	Difficult		Many	UI Improvement

Still want to help but in other areas ?

If our current re-factor to do list 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.  Please take a look below for 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.