Framework Cleanup Options - Tidy Up & Refactor?
Locked
 
|
Hi Everyone
A few months ago we started looking at a proposed framework re-write sub project with Adrian as our mentor. https://cwiki.apache.org/confluence/display/OFBIZ/Potential+Framework+Project+for+the+Foundation+Sub+Component With Adrian gone it makes it hard for us to continue so have decided to abandon this effort. We don't want to give up on having a better framework and know that another option is to tidy up our existing framework. (So yes – this means refactoring, and yes it will be a lot of work) In general we do sometimes tidy up or refactor as we go along and some work has already started with movement of entity definitions into a separate datamodel component. If we really do want to tidy up our framework then we will need as many people from the community as possible to help out. Now here comes the big question – is the community interested in really doing this and are there people out there willing to help out? Thanks Sharan |
|
Hi Sharan and Everyone,
When we lost Adrian in the beginning of the rewrite project I really felt lost. His feedback made things simple and I miss having him around for mentoring and feedback. I think deferring the rewrite project is a good idea for now. I shifted my energy into just playing with the code and dabbling here and there and I got surprised by the many problems that exist pretty much everywhere. This would be things like: - Extending classes from external libraries into the core APIs - Writing to implementations instead of interfaces - Files too long - Different levels of abstractions mixed together - Poor test coverage, lack of TDD - Implicit (hidden) dependencies (I dislike this the most) I think the above issues indicate that we really do need less energy on new features, and much more on refactoring. We should refactor everything including core API interfaces. Some examples of work we can do: - EntitySaxReader implements javolution interfaces and looks hideous - HtmlFormRenderer is 3000 lines of code and the interfaces it implements are also huge - XmlFormRenderer does not implement more than half of the methods - Lots of dependencies on deprecated classes / constructors (e.g. HtmlScreenRenderer, FoScreenRenderer) - Start.java has some problems which I'm trying to tackle in JIRA: OFBIZ-6783 - Lots of non-parameterized and non type checked declarations. - Implementations with no interfaces (e.g. TemporalExpression, GroupModel, Cache, etc ...) The list goes on and on. Every one of the SOLID principles for Bob Martin is violated in many places and most of the code smells in his book also exist. I started a thread a while back suggesting that I would like to start refactoring without too many JIRAs because it would slow us down. However, the feedback from the community I got is that JIRA creation is preferred. This, however, would slow down progress especially if I'm just making minor one-line changes. We need an efficient way to make continuous daily improvements to the code base. Also, we need to document our design philosophy for others to consider when writing code. I don't mean just formatting conventions but also things like writing to interfaces, TDD, design rules specific to OFBiz, and so on. To summarize: - We have a LOT of refactoring work, it's everywhere - We need a more efficient workflow for continuous daily refactoring, the current workflow is too bureaucratic - We need help from everyone - We need to expand the coding guidelines to introduce some design concepts, not just formatting. Those are my very long 2 cents. Taher Alkhateeb On Wed, Feb 3, 2016 at 8:19 PM, Sharan-F <[hidden email]> wrote: > Hi Everyone > > A few months ago we started looking at a proposed framework re-write sub > project with Adrian as our mentor. > > https://cwiki.apache.org/confluence/display/OFBIZ/Potential+Framework+Project+for+the+Foundation+Sub+Component > > With Adrian gone it makes it hard for us to continue so have decided to > abandon this effort. > > We don't want to give up on having a better framework and know that another > option is to tidy up our existing framework. (So yes – this means > refactoring, and yes it will be a lot of work) > > In general we do sometimes tidy up or refactor as we go along and some work > has already started with movement of entity definitions into a separate > datamodel component. If we really do want to tidy up our framework then we > will need as many people from the community as possible to help out. > > Now here comes the big question – is the community interested in really > doing this and are there people out there willing to help out? > > Thanks > Sharan > > > > > > > > > > -- > View this message in context: > http://ofbiz.135035.n4.nabble.com/Framework-Cleanup-Options-Tidy-Up-Refactor-tp4676797.html > Sent from the OFBiz - Dev mailing list archive at Nabble.com. > |
Re: Framework Cleanup Options - Tidy Up & Refactor?
|
|
Le 04/02/2016 07:19, Taher Alkhateeb a écrit :
> Hi Sharan and Everyone, > > When we lost Adrian in the beginning of the rewrite project I really felt > lost. His feedback made things simple and I miss having him around for > mentoring and feedback. I think deferring the rewrite project is a good > idea for now. I agree and in line > > I shifted my energy into just playing with the code and dabbling here and > there and I got surprised by the many problems that exist pretty much > everywhere. This would be things like: > > - Extending classes from external libraries into the core APIs > - Writing to implementations instead of interfaces > - Files too long > - Different levels of abstractions mixed together > - Poor test coverage, lack of TDD > - Implicit (hidden) dependencies (I dislike this the most) > > I think the above issues indicate that we really do need less energy on new > features, and much more on refactoring. We should refactor everything > including core API interfaces. Some examples of work we can do: > > - EntitySaxReader implements javolution interfaces and looks hideous > - HtmlFormRenderer is 3000 lines of code and the interfaces it implements > are also huge > - XmlFormRenderer does not implement more than half of the methods > - Lots of dependencies on deprecated classes / constructors (e.g. > HtmlScreenRenderer, FoScreenRenderer) > - Start.java has some problems which I'm trying to tackle in JIRA: > OFBIZ-6783 > - Lots of non-parameterized and non type checked declarations. > - Implementations with no interfaces (e.g. TemporalExpression, GroupModel, > Cache, etc ...) slim, clean, increase solidity (ahhhh nice speech) > > The list goes on and on. Every one of the SOLID principles for Bob Martin > is violated in many places and most of the code smells in his book also > exist. > > I started a thread a while back suggesting that I would like to start > refactoring without too many JIRAs because it would slow us down. However, > the feedback from the community I got is that JIRA creation is preferred. > This, however, would slow down progress especially if I'm just making minor > one-line changes. We need an efficient way to make continuous daily > improvements to the code base. commit > > Also, we need to document our design philosophy for others to consider when > writing code. I don't mean just formatting conventions but also things like > writing to interfaces, TDD, design rules specific to OFBiz, and so on. > > To summarize: > - We have a LOT of refactoring work, it's everywhere Open a master issue with macro sub-task, linked to wiki for each conception detail > - We need a more efficient workflow for continuous daily refactoring, the > current workflow is too bureaucratic it's not a pb, we will not close a jira at each commit but only when the improvement is completed after 10 - 20 or more commit > - We need help from everyone Nereide's commiter are available ! :) (enfin je crois Gil, Julien ?) we just need some code orientation to realize because we aren't high technical developer. > - We need to expand the coding guidelines to introduce some design > concepts, not just formatting. Adrian started with the thread safe design, feel free to load your mind on the wiki :) Nicolas > Those are my very long 2 cents. > > Taher Alkhateeb > > On Wed, Feb 3, 2016 at 8:19 PM, Sharan-F <[hidden email]> wrote: > >> Hi Everyone >> >> A few months ago we started looking at a proposed framework re-write sub >> project with Adrian as our mentor. >> >> https://cwiki.apache.org/confluence/display/OFBIZ/Potential+Framework+Project+for+the+Foundation+Sub+Component >> >> With Adrian gone it makes it hard for us to continue so have decided to >> abandon this effort. >> >> We don't want to give up on having a better framework and know that another >> option is to tidy up our existing framework. (So yes – this means >> refactoring, and yes it will be a lot of work) >> >> In general we do sometimes tidy up or refactor as we go along and some work >> has already started with movement of entity definitions into a separate >> datamodel component. If we really do want to tidy up our framework then we >> will need as many people from the community as possible to help out. >> >> Now here comes the big question – is the community interested in really >> doing this and are there people out there willing to help out? >> >> Thanks >> Sharan >> >> >> >> >> >> >> >> >> >> -- >> View this message in context: >> http://ofbiz.135035.n4.nabble.com/Framework-Cleanup-Options-Tidy-Up-Refactor-tp4676797.html >> Sent from the OFBiz - Dev mailing list archive at Nabble.com. >> |
Re: Framework Cleanup Options - Tidy Up & Refactor?
|
|
+1
I'm ready to help you Taher but as Nicolas's said we need some code orientation :) Julien. <http://www.centre-tic.com/> Le 04/02/2016 09:45, Nicolas Malin a écrit : > Le 04/02/2016 07:19, Taher Alkhateeb a écrit : >> Hi Sharan and Everyone, >> >> When we lost Adrian in the beginning of the rewrite project I really >> felt >> lost. His feedback made things simple and I miss having him around for >> mentoring and feedback. I think deferring the rewrite project is a good >> idea for now. > I agree and in line >> >> I shifted my energy into just playing with the code and dabbling here >> and >> there and I got surprised by the many problems that exist pretty much >> everywhere. This would be things like: >> >> - Extending classes from external libraries into the core APIs >> - Writing to implementations instead of interfaces >> - Files too long >> - Different levels of abstractions mixed together >> - Poor test coverage, lack of TDD >> - Implicit (hidden) dependencies (I dislike this the most) >> >> I think the above issues indicate that we really do need less energy >> on new >> features, and much more on refactoring. We should refactor everything >> including core API interfaces. Some examples of work we can do: >> >> - EntitySaxReader implements javolution interfaces and looks hideous >> - HtmlFormRenderer is 3000 lines of code and the interfaces it >> implements >> are also huge >> - XmlFormRenderer does not implement more than half of the methods >> - Lots of dependencies on deprecated classes / constructors (e.g. >> HtmlScreenRenderer, FoScreenRenderer) >> - Start.java has some problems which I'm trying to tackle in JIRA: >> OFBIZ-6783 >> - Lots of non-parameterized and non type checked declarations. >> - Implementations with no interfaces (e.g. TemporalExpression, >> GroupModel, >> Cache, etc ...) > Yes I started some improvement and we need to continue. Step by step, > slim, clean, increase solidity (ahhhh nice speech) >> >> The list goes on and on. Every one of the SOLID principles for Bob >> Martin >> is violated in many places and most of the code smells in his book also >> exist. >> >> I started a thread a while back suggesting that I would like to start >> refactoring without too many JIRAs because it would slow us down. >> However, >> the feedback from the community I got is that JIRA creation is >> preferred. >> This, however, would slow down progress especially if I'm just making >> minor >> one-line changes. We need an efficient way to make continuous daily >> improvements to the code base. > One jira per purpose don't wast some time for us and help to follow > all commit >> >> Also, we need to document our design philosophy for others to >> consider when >> writing code. I don't mean just formatting conventions but also >> things like >> writing to interfaces, TDD, design rules specific to OFBiz, and so on. >> >> To summarize: >> - We have a LOT of refactoring work, it's everywhere > Open a master issue with macro sub-task, linked to wiki for each > conception detail >> - We need a more efficient workflow for continuous daily refactoring, >> the >> current workflow is too bureaucratic > it's not a pb, we will not close a jira at each commit but only when > the improvement is completed after 10 - 20 or more commit >> - We need help from everyone > Nereide's commiter are available ! :) (enfin je crois Gil, Julien ?) > we just need some code orientation to realize because we aren't high > technical developer. >> - We need to expand the coding guidelines to introduce some design >> concepts, not just formatting. > Adrian started with the thread safe design, feel free to load your > mind on the wiki :) > > Nicolas >> Those are my very long 2 cents. >> >> Taher Alkhateeb >> >> On Wed, Feb 3, 2016 at 8:19 PM, Sharan-F <[hidden email]> wrote: >> >>> Hi Everyone >>> >>> A few months ago we started looking at a proposed framework re-write >>> sub >>> project with Adrian as our mentor. >>> >>> https://cwiki.apache.org/confluence/display/OFBIZ/Potential+Framework+Project+for+the+Foundation+Sub+Component >>> >>> >>> With Adrian gone it makes it hard for us to continue so have decided to >>> abandon this effort. >>> >>> We don't want to give up on having a better framework and know that >>> another >>> option is to tidy up our existing framework. (So yes – this means >>> refactoring, and yes it will be a lot of work) >>> >>> In general we do sometimes tidy up or refactor as we go along and >>> some work >>> has already started with movement of entity definitions into a separate >>> datamodel component. If we really do want to tidy up our framework >>> then we >>> will need as many people from the community as possible to help out. >>> >>> Now here comes the big question – is the community interested in really >>> doing this and are there people out there willing to help out? >>> >>> Thanks >>> Sharan >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> View this message in context: >>> http://ofbiz.135035.n4.nabble.com/Framework-Cleanup-Options-Tidy-Up-Refactor-tp4676797.html >>> >>> Sent from the OFBiz - Dev mailing list archive at Nabble.com. >>> > |
Re: Framework Cleanup Options - Tidy Up & Refactor?
Administrator
|
In reply to this post by Nicolas Malin-2
Inline... only when I feel needed...
Le 04/02/2016 09:45, Nicolas Malin a écrit : > Le 04/02/2016 07:19, Taher Alkhateeb a écrit : >> Hi Sharan and Everyone, [...] >> >> I started a thread a while back suggesting that I would like to start >> refactoring without too many JIRAs because it would slow us down. However, >> the feedback from the community I got is that JIRA creation is preferred. >> This, however, would slow down progress especially if I'm just making minor >> one-line changes. We need an efficient way to make continuous daily >> improvements to the code base. > One jira per purpose don't wast some time for us and help to follow all commit +1 >> >> Also, we need to document our design philosophy for others to consider when >> writing code. I don't mean just formatting conventions but also things like >> writing to interfaces, TDD, design rules specific to OFBiz, and so on. >> >> To summarize: >> - We have a LOT of refactoring work, it's everywhere > Open a master issue with macro sub-task, linked to wiki for each conception detail +1 One thing you can also do is opening a single Jira and put trivial things in comments. Beware though that when problems arise (expect them) it's then difficult to follow things. Fortunately the "recent" introduction of the "reply feature" by comment allows more of this but should not be abused. One thing you need to avoid as much as possible is commits bursts. I remember being unable to follow the flow (review) when Adam did that, even when splitting commits done in his git repo. >> - We need a more efficient workflow for continuous daily refactoring, the >> current workflow is too bureaucratic > it's not a pb, we will not close a jira at each commit but only when the improvement is completed after 10 - 20 or more commit >> - We need help from everyone > Nereide's commiter are available ! :) (enfin je crois Gil, Julien ?) we just need some code orientation to realize because we aren't high technical > developer. >> - We need to expand the coding guidelines to introduce some design >> concepts, not just formatting. > Adrian started with the thread safe design, feel free to load your mind on the wiki :) Do you mean this https://cwiki.apache.org/confluence/display/OFBIZ/A+New+Application+Framework+Design Nicolas? Jacques > > Nicolas >> Those are my very long 2 cents. >> >> Taher Alkhateeb >> >> On Wed, Feb 3, 2016 at 8:19 PM, Sharan-F <[hidden email]> wrote: >> >>> Hi Everyone >>> >>> A few months ago we started looking at a proposed framework re-write sub >>> project with Adrian as our mentor. >>> >>> https://cwiki.apache.org/confluence/display/OFBIZ/Potential+Framework+Project+for+the+Foundation+Sub+Component >>> >>> With Adrian gone it makes it hard for us to continue so have decided to >>> abandon this effort. >>> >>> We don't want to give up on having a better framework and know that another >>> option is to tidy up our existing framework. (So yes – this means >>> refactoring, and yes it will be a lot of work) >>> >>> In general we do sometimes tidy up or refactor as we go along and some work >>> has already started with movement of entity definitions into a separate >>> datamodel component. If we really do want to tidy up our framework then we >>> will need as many people from the community as possible to help out. >>> >>> Now here comes the big question – is the community interested in really >>> doing this and are there people out there willing to help out? >>> >>> Thanks >>> Sharan >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> View this message in context: >>> http://ofbiz.135035.n4.nabble.com/Framework-Cleanup-Options-Tidy-Up-Refactor-tp4676797.html >>> Sent from the OFBiz - Dev mailing list archive at Nabble.com. >>> > > |
Re: Framework Cleanup Options - Tidy Up & Refactor?
|
|
In reply to this post by Nicolas Malin-2
I'm ready to help on these
matters ! Nicolas guess it right !
Gil On 04/02/2016 09:45, Nicolas Malin
wrote:
Le 04/02/2016 07:19, Taher Alkhateeb a écrit : |
|
|
In reply to this post by Julien NICOLAS
Hi All
Thanks for the feedback so far. It sounds like we need to have a clear vision of what needs to be done and also organise things so it's easy for people to know what they can work on. I'll see if I can summarise the main points onto a wiki page. Thanks Sharan |
Re: Framework Cleanup Options - Tidy Up & Refactor?
|
|
In reply to this post by taher
I think JIRAs are essential if you expect others to help out.
I don't think that it would be a bad thing to create the JIRA after you fix something and attach a patch to the JIRA showing all the little changes that you made as part of the JIRA rather than writing a description that is longer than the code being fixed. Ron On 04/02/2016 1:19 AM, Taher Alkhateeb wrote: > Hi Sharan and Everyone, > > When we lost Adrian in the beginning of the rewrite project I really felt > lost. His feedback made things simple and I miss having him around for > mentoring and feedback. I think deferring the rewrite project is a good > idea for now. > > I shifted my energy into just playing with the code and dabbling here and > there and I got surprised by the many problems that exist pretty much > everywhere. This would be things like: > > - Extending classes from external libraries into the core APIs > - Writing to implementations instead of interfaces > - Files too long > - Different levels of abstractions mixed together > - Poor test coverage, lack of TDD > - Implicit (hidden) dependencies (I dislike this the most) > > I think the above issues indicate that we really do need less energy on new > features, and much more on refactoring. We should refactor everything > including core API interfaces. Some examples of work we can do: > > - EntitySaxReader implements javolution interfaces and looks hideous > - HtmlFormRenderer is 3000 lines of code and the interfaces it implements > are also huge > - XmlFormRenderer does not implement more than half of the methods > - Lots of dependencies on deprecated classes / constructors (e.g. > HtmlScreenRenderer, FoScreenRenderer) > - Start.java has some problems which I'm trying to tackle in JIRA: > OFBIZ-6783 > - Lots of non-parameterized and non type checked declarations. > - Implementations with no interfaces (e.g. TemporalExpression, GroupModel, > Cache, etc ...) > > The list goes on and on. Every one of the SOLID principles for Bob Martin > is violated in many places and most of the code smells in his book also > exist. > > I started a thread a while back suggesting that I would like to start > refactoring without too many JIRAs because it would slow us down. However, > the feedback from the community I got is that JIRA creation is preferred. > This, however, would slow down progress especially if I'm just making minor > one-line changes. We need an efficient way to make continuous daily > improvements to the code base. > > Also, we need to document our design philosophy for others to consider when > writing code. I don't mean just formatting conventions but also things like > writing to interfaces, TDD, design rules specific to OFBiz, and so on. > > To summarize: > - We have a LOT of refactoring work, it's everywhere > - We need a more efficient workflow for continuous daily refactoring, the > current workflow is too bureaucratic > - We need help from everyone > - We need to expand the coding guidelines to introduce some design > concepts, not just formatting. > > Those are my very long 2 cents. > > Taher Alkhateeb > > On Wed, Feb 3, 2016 at 8:19 PM, Sharan-F <[hidden email]> wrote: > >> Hi Everyone >> >> A few months ago we started looking at a proposed framework re-write sub >> project with Adrian as our mentor. >> >> https://cwiki.apache.org/confluence/display/OFBIZ/Potential+Framework+Project+for+the+Foundation+Sub+Component >> >> With Adrian gone it makes it hard for us to continue so have decided to >> abandon this effort. >> >> We don't want to give up on having a better framework and know that another >> option is to tidy up our existing framework. (So yes – this means >> refactoring, and yes it will be a lot of work) >> >> In general we do sometimes tidy up or refactor as we go along and some work >> has already started with movement of entity definitions into a separate >> datamodel component. If we really do want to tidy up our framework then we >> will need as many people from the community as possible to help out. >> >> Now here comes the big question – is the community interested in really >> doing this and are there people out there willing to help out? >> >> Thanks >> Sharan >> >> >> >> >> >> >> >> >> >> -- >> View this message in context: >> http://ofbiz.135035.n4.nabble.com/Framework-Cleanup-Options-Tidy-Up-Refactor-tp4676797.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 |
«
Return to OFBiz - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |