Framework Re-Factor: List of Areas that Need Work

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Framework Re-Factor: List of Areas that Need Work

Sharan-F
Hi All

A few weeks ago we talked about getting things moving on some framework re-factoring.

http://ofbiz.135035.n4.nabble.com/Framework-Cleanup-Options-Tidy-Up-amp-Refactor-tt4676797.html#a4676841

One of the things I thought would be useful is to have a list of areas that people could work on.  It could  also help to focus people on specific tasks and help collaboration so I've setup a wiki page with some background about what we'd like to do and why.

https://cwiki.apache.org/confluence/display/OFBIZ/Framework+Re-factor

The overall goal is to make it easier for us to maintain and improve our code. Ideally re-factoring occurs naturally over time. In our case I think we need to actively do some maintenance to kick start that process.


You will see that I've taken Taher's original suggestions and selected some to include in a 'top 5' list of areas that need some work done.

     1. EntitySaxReader  (If we can change this from a class implementation to an interface implementation then we can get rid of Javalution. This has been hanging around for a while and would be really, really good to tidy up)

     2. HtmlFormRenderer (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 (Taher has been working on this so this is currently in progress under https://issues.apache.org/jira/browse/OFBIZ-6783)


If you would like to work on an area but are not sure what the problems are then Taher has said that he is willing to help point out what needs to be done.

I hope that people will take a look and select an area to begin working on. We need as much help as we can get. I think that if we can get the work started then we can gain the momentum to continue.

Thanks
Sharan
Reply | Threaded
Open this post in threaded view
|

RE: Framework Re-Factor: List of Areas that Need Work

taher
Hi Sharan,

Thank you for taking the lead, much appreciated! I urge anyone in the
community who is interested to pitch in. We need everyone's help as the code
base really needs a _lot_ of cleanup work.

I would like to stress that not all refactoring is hard, and you don't need
to turn everything into a big object framework. Little help here and there
would go a long way. For those interested, I've compiled below some common
"Code Smells" which you can quickly identify and fix in the framework:

- Obsolete / irrelevant comments: anything out of date
- Commented out code: that sucks, 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.

Please consider helping out!

Regards,

Taher Alkhateeb

-----Original Message-----
From: Sharan-F [mailto:[hidden email]]
Sent: 01 March 2016 20:09
To: [hidden email]
Subject: Framework Re-Factor: List of Areas that Need Work

Hi All

A few weeks ago we talked about getting things moving on some framework
re-factoring.

http://ofbiz.135035.n4.nabble.com/Framework-Cleanup-Options-Tidy-Up-amp-Refa
ctor-tt4676797.html#a4676841

One of the things I thought would be useful is to have a list of areas that
people could work on.  It could  also help to focus people on specific tasks
and help collaboration so I've setup a wiki page with some background about
what we'd like to do and why.

https://cwiki.apache.org/confluence/display/OFBIZ/Framework+Re-factor

The overall goal is to make it easier for us to maintain and improve our
code. Ideally re-factoring occurs naturally over time. In our case I think
we need to actively do some maintenance to kick start that process.


You will see that I've taken Taher's original suggestions and selected some
to include in a 'top 5' list of areas that need some work done.

     1. EntitySaxReader  (If we can change this from a class implementation
to an interface implementation then we can get rid of Javalution. This has
been hanging around for a while and would be really, really good to tidy up)

     2. HtmlFormRenderer (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 (Taher has been working on this so this is currently in
progress under https://issues.apache.org/jira/browse/OFBIZ-6783)


If you would like to work on an area but are not sure what the problems are
then Taher has said that he is willing to help point out what needs to be
done.

I hope that people will take a look and select an area to begin working on.
We need as much help as we can get. I think that if we can get the work
started then we can gain the momentum to continue.

Thanks
Sharan




--
View this message in context:
http://ofbiz.135035.n4.nabble.com/Framework-Re-Factor-List-of-Areas-that-Nee
d-Work-tp4677565.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Reply | Threaded
Open this post in threaded view
|

Re: Framework Re-Factor: List of Areas that Need Work

Ron Wheeler
Great summary of the problems.

Does it make sense to tackle this by package or is there some other way
to divide up the work into chunks that someone or some group could take on?

If so, can you put together a list of packages that need to be tackled
and perhaps create a JIRA issue for each package so that volunteers
could have a starting place?
I think that your description below would be a good description of the
issue.

If there are packages that are more important to fix - code that has a
higher frequency of modifications, code that is more fragile, etc.,
identifying those might give some guidance to people who want to work.
That may also give a priority for the  creation of JIRA issues so that
we tackle the important things first.

Ron


On 02/03/2016 5:37 AM, Taher Alkhateeb wrote:

> Hi Sharan,
>
> Thank you for taking the lead, much appreciated! I urge anyone in the
> community who is interested to pitch in. We need everyone's help as the code
> base really needs a _lot_ of cleanup work.
>
> I would like to stress that not all refactoring is hard, and you don't need
> to turn everything into a big object framework. Little help here and there
> would go a long way. For those interested, I've compiled below some common
> "Code Smells" which you can quickly identify and fix in the framework:
>
> - Obsolete / irrelevant comments: anything out of date
> - Commented out code: that sucks, 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.
>
> Please consider helping out!
>
> Regards,
>
> Taher Alkhateeb
>
> -----Original Message-----
> From: Sharan-F [mailto:[hidden email]]
> Sent: 01 March 2016 20:09
> To: [hidden email]
> Subject: Framework Re-Factor: List of Areas that Need Work
>
> Hi All
>
> A few weeks ago we talked about getting things moving on some framework
> re-factoring.
>
> http://ofbiz.135035.n4.nabble.com/Framework-Cleanup-Options-Tidy-Up-amp-Refa
> ctor-tt4676797.html#a4676841
>
> One of the things I thought would be useful is to have a list of areas that
> people could work on.  It could  also help to focus people on specific tasks
> and help collaboration so I've setup a wiki page with some background about
> what we'd like to do and why.
>
> https://cwiki.apache.org/confluence/display/OFBIZ/Framework+Re-factor
>
> The overall goal is to make it easier for us to maintain and improve our
> code. Ideally re-factoring occurs naturally over time. In our case I think
> we need to actively do some maintenance to kick start that process.
>
>
> You will see that I've taken Taher's original suggestions and selected some
> to include in a 'top 5' list of areas that need some work done.
>
>       1. EntitySaxReader  (If we can change this from a class implementation
> to an interface implementation then we can get rid of Javalution. This has
> been hanging around for a while and would be really, really good to tidy up)
>
>       2. HtmlFormRenderer (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 (Taher has been working on this so this is currently in
> progress under https://issues.apache.org/jira/browse/OFBIZ-6783)
>
>
> If you would like to work on an area but are not sure what the problems are
> then Taher has said that he is willing to help point out what needs to be
> done.
>
> I hope that people will take a look and select an area to begin working on.
> We need as much help as we can get. I think that if we can get the work
> started then we can gain the momentum to continue.
>
> Thanks
> Sharan
>
>
>
>
> --
> View this message in context:
> http://ofbiz.135035.n4.nabble.com/Framework-Re-Factor-List-of-Areas-that-Nee
> d-Work-tp4677565.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>
>


--
Ron Wheeler
President
Artifact Software Inc
email: [hidden email]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

Reply | Threaded
Open this post in threaded view
|

Re: Framework Re-Factor: List of Areas that Need Work

taher
Hi Ron and everyone,

I don't think we need to worry too much about how to "break it down". It
doesn't really need breaking down. All that you need is to choose an area
you'd like to work on, and hack away at it. Sharan already provided a few
items in the beginning of this thread, pick one and go at it.

In terms of priority for things to work on, I would keep it very simple:
Start with the framework, move up to the applications and finally to the
specialpurpose components. It's really that simple. If you want to be more
specific, I would say perhaps start working on base, common, entity,
service, start, widget and webapps. Jacques is already working on the
security component I think, and I'm doing what I can on "Start".

Now mind you, the reason why I don't prefer to spend too much effort in
"identifying what to do" is because as I started working on the code base I
realized that there is decay and wrinkles everywhere. The framework needs a
full body lift and fat removal from years and years of dumping code on it.

I think that a refactoring exercise can be either big or small and I kind
of distinguish between the two as follows:
- Big refactor: You introduce design changes and refactor everything to the
new design and then fix everything that breaks due to dependency.
- Small refactor: you really just enhance a small portion of the code and
remove some of the code smells that I mentioned in the previous email.

So that's it, pick an area, Issue a JIRA, perhaps ask for people to help
you out in the mailing list. I for one would love to pitch in, because
collaboration together brings new ideas and is more powerful than working
solo.

Cheers,

Taher Alkhateeb

On Wed, Mar 2, 2016 at 4:44 PM, Ron Wheeler <[hidden email]>
wrote:

> Great summary of the problems.
>
> Does it make sense to tackle this by package or is there some other way to
> divide up the work into chunks that someone or some group could take on?
>
> If so, can you put together a list of packages that need to be tackled and
> perhaps create a JIRA issue for each package so that volunteers could have
> a starting place?
> I think that your description below would be a good description of the
> issue.
>
> If there are packages that are more important to fix - code that has a
> higher frequency of modifications, code that is more fragile, etc.,
> identifying those might give some guidance to people who want to work.
> That may also give a priority for the  creation of JIRA issues so that we
> tackle the important things first.
>
> Ron
>
>
> On 02/03/2016 5:37 AM, Taher Alkhateeb wrote:
>
>> Hi Sharan,
>>
>> Thank you for taking the lead, much appreciated! I urge anyone in the
>> community who is interested to pitch in. We need everyone's help as the
>> code
>> base really needs a _lot_ of cleanup work.
>>
>> I would like to stress that not all refactoring is hard, and you don't
>> need
>> to turn everything into a big object framework. Little help here and there
>> would go a long way. For those interested, I've compiled below some common
>> "Code Smells" which you can quickly identify and fix in the framework:
>>
>> - Obsolete / irrelevant comments: anything out of date
>> - Commented out code: that sucks, 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.
>>
>> Please consider helping out!
>>
>> Regards,
>>
>> Taher Alkhateeb
>>
>> -----Original Message-----
>> From: Sharan-F [mailto:[hidden email]]
>> Sent: 01 March 2016 20:09
>> To: [hidden email]
>> Subject: Framework Re-Factor: List of Areas that Need Work
>>
>> Hi All
>>
>> A few weeks ago we talked about getting things moving on some framework
>> re-factoring.
>>
>>
>> http://ofbiz.135035.n4.nabble.com/Framework-Cleanup-Options-Tidy-Up-amp-Refa
>> ctor-tt4676797.html#a4676841
>>
>> One of the things I thought would be useful is to have a list of areas
>> that
>> people could work on.  It could  also help to focus people on specific
>> tasks
>> and help collaboration so I've setup a wiki page with some background
>> about
>> what we'd like to do and why.
>>
>> https://cwiki.apache.org/confluence/display/OFBIZ/Framework+Re-factor
>>
>> The overall goal is to make it easier for us to maintain and improve our
>> code. Ideally re-factoring occurs naturally over time. In our case I think
>> we need to actively do some maintenance to kick start that process.
>>
>>
>> You will see that I've taken Taher's original suggestions and selected
>> some
>> to include in a 'top 5' list of areas that need some work done.
>>
>>       1. EntitySaxReader  (If we can change this from a class
>> implementation
>> to an interface implementation then we can get rid of Javalution. This has
>> been hanging around for a while and would be really, really good to tidy
>> up)
>>
>>       2. HtmlFormRenderer (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 (Taher has been working on this so this is currently
>> in
>> progress under https://issues.apache.org/jira/browse/OFBIZ-6783)
>>
>>
>> If you would like to work on an area but are not sure what the problems
>> are
>> then Taher has said that he is willing to help point out what needs to be
>> done.
>>
>> I hope that people will take a look and select an area to begin working
>> on.
>> We need as much help as we can get. I think that if we can get the work
>> started then we can gain the momentum to continue.
>>
>> Thanks
>> Sharan
>>
>>
>>
>>
>> --
>> View this message in context:
>>
>> http://ofbiz.135035.n4.nabble.com/Framework-Re-Factor-List-of-Areas-that-Nee
>> d-Work-tp4677565.html
>> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>>
>>
>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: [hidden email]
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Framework Re-Factor: List of Areas that Need Work

kulwantbughipura
This post was updated on .
Hello,

I am not expert java. I am just intermediate user of java.
It's now 4 months since i have been working in ofbiz and liked the framework, so wanted to contribute in it.

Thanks.
Reply | Threaded
Open this post in threaded view
|

Re: Framework Re-Factor: List of Areas that Need Work

Sharan-F
Hi Kulwant

Thanks for your offer of help.  

I've had a quick chat with Taher and we think that it would be a good idea to setup a group call (e.g. via Skype) and invite everyone that has expressed an interest in helping out. The main aim is to get people together and talk through briefly where and how to get started.  

I will to post another message about organising the call so please respond that thread with details of your timezone.

Thanks
Sharan
Reply | Threaded
Open this post in threaded view
|

Re: Framework Re-Factor: List of Areas that Need Work

kulwantbughipura
Hello,

My timezone details are (UTC+05:30) Chennai, Kolkata, Mumbai, New Delhi.

Thanks.