In an open source project, there is a lot of responsibility placed on
the people doing the commits.
They have to ensure that code that they accept is high quality and not
commit code contributions that do not meet quality standards.
- Code must follow generally accepted practices and design patterns as
well as the project's conventions.
- Test coverage must be adequate and updated to reflect the changes made.
- Code must be documented adequately - JavaDocs should pass validation
tests at a minimum and the description accurate even if it is short.
Taher's comments may reflect past coding practices but if crappy code is
updated without being fixed so it is no longer deficient, it is just a
waste of time.
The major quality problems may not be the result of the current update
but it should be fixed before being resubmitted unless the fix is very
small and an important bug fix.
Enhancements should not be committed in code that is not cleaned up.
In a proprietary project, the QA process will be enforced as an
important part of the development effort.
An open source project has to find a way to do this as well if it is
going to produce a high quality product that works and is easy to maintain.
Ron
On 07/06/2016 8:14 AM, Divesh Dutta wrote:
Thanks Taher for the links. Me , Mridul and Pranay have picked some items
from the list. We will keep discussing on these items.
Also as you said it will be great once we come up with some clever solution
to collaborate on these items so that we discuss and make progress on
refactoring effort.
Thanks
--
Divesh Dutta.
On Tue, Jun 7, 2016 at 1:23 PM, Taher Alkhateeb <[email protected]>
wrote:
Hi Divesh,
This initiative is already going and I invite to jump in:
here ->
https://cwiki.apache.org/confluence/display/OFBIZ/Re-Factor+To-Do+List
and here ->
https://cwiki.apache.org/confluence/display/OFBIZ/Coding+Practices
I will work on more tasks and more ideas for people to jump in. However, I
think the problem right now is that of communication and reaching out to
interested members who perhaps are intimidated by the process. That's why
it was a great gesture from Sharan to invite mentors and I will wait for
Sharan or others to come up with some clever solution for us to collaborate
more effectively.
So to give you some clarity on the vision for the refactoring project:
- Code should be clean
- Things should be modular and isolated
- Lower level things should not depend on higher level things
That's it, that's the plan! If we stick to it completely and religiously
and continue doing this for say 12 months or more, then the code would
reach a level of clarity that ALLOWS YOU TO THINK of new ideas and ways to
improve. You cannot think in a mess!
I hope you can join and help out. Take a look at the wiki.
Taher Alkhateeb
On Tue, Jun 7, 2016 at 9:57 AM, Divesh Dutta <
[email protected]
wrote:
Taher,
Please let us know how can others help you here. I am sure there are many
members who are willing to participate here and help you in refactoring.
But all might not know what you have exactly in your mind.
If you can start with some portions of framework and start describing the
problem you see in current implementation , solution you propose with
design notes or implementation notes or some thing to start with for
other
developers, I am sure it will be good start for others to collaborate.
And
we can also create road map of the refactoring work so that all knows
what
is coming up.
As you are leading this effort, I will request you to take further
initiative and we all are here to help you .
Thanks
--
Divesh Dutta.
On Mon, Jun 6, 2016 at 3:35 PM, Taher Alkhateeb <
[email protected]>
wrote:
Hi Sharan,
It's really good to have you on board in this project, thank you for
the
positive energy :) I compile below my ideas based on your feedback:
First of all, the ideas I listed in this thread are just ideas that are
subject to change. The important thing is moving forward and getting
things
done. So I ask everyone not to worry too much about the choice of
technology or tool to use here or there. I'm sure whatever we decide to
go
with eventually is okay. In the end, these are tools, what matters is
people and process.
Second I noticed a problem that maybe you Sharan can help with. I
observed
multiple times from some community members that they actually _want_ to
help but are overwhelmed with the complexity of this process and are
not
sure how to help.
The hesitation for others to engage is because collaboration over the
Wiki
Page, Mailing List and JIRA is definitely not enough. Why?
- Slow (feedback on progress, hints, guidance)
- Not very friendly for beginners
- Intimidating: some might be reluctant to ask basic questions on
architecture or programming or so.
- Overwhelming: We are discussing very technical matters and some
people
would freak out at the complexity. They need to understand that there
are
different tasks at different levels of complexity and that there are
senior
out there who are willing to help. The tools we are using for
collaboration
makes it difficult to convey this fact.
- Impersonal and we cannot get people engaged. Things like
conversations,
brainstorming, assigning tasks, discussing, coaching, teaching and
encouraging are difficult to do. These personal elements are crucial
for
knowledge transfer and support.
In short, I think there are members in the society who are willing to
help, but not sure how. It's really unfortunate not to engage these
individuals because of communication barriers.
My 2 cents!
Taher Alkhateeb
-----Original Message-----
From: Sharan-F [mailto:[email protected]]
Sent: 06 June 2016 10:57
To: [email protected]
Subject: Re: My experience with refactoring the framework
Hi Taher
Thanks for sharing your experience as I think it contains some real
insights and also re-confirms an important task – we need to tidy up
our
code. And the one crucial message I hear loud and clear in your email
is
that we need everyone to help out too.
(BTW I've seen the amount of work that you have done on the start.java
which is looking very elegant now :-)
Your list re-factoring ideas touch on a lot of areas that I'm sure will
generate discussion and I hope that we don't get too caught up in the
discussion that we don't act. We need to stay active by continually
doing
something that improves OFBiz.
I agree that we should look at holding off adding new features or
improvements now and just clean. I've seen the huge amount of activity
that
is happening at the moment so let's see if we can maybe focus some of
that
energy into tidying up our code and getting rid of our ' historic
technical
debt' (as mentioned by Jacques).
It sounds like you have already a list of tasks to replenish our
Current
Re-Factor To Do list so let's do that and get the message out to the
community about what they can do to help. I noticed that if we have a
list
of tasks that people can pick up easily, then they will.
Going forward we may need to have a bit more co-ordination and also
work
together in small groups focussing on particular areas so things dont
get
broken, especially once the applications start being affected.
I'm happy to help so just let me know how I can.
Thanks
Sharan
--
View this message in context:
http://ofbiz.135035.n4.nabble.com/My-experience-with-refactoring-the-framework-tp4682539p4682591.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
