Hi Groza,

Inline...

Le 18/09/2024 à 15:55, Groza Danut a écrit :
Hi all,

My proposal comes from my personal observations so far. I believe currently
the 'customer' of the Ofbiz Project should be the developer, not the end
user. I say this because of the following reasons:

This is what somehow explained at https://ofbiz.apache.org/mailing-lists.html
Though not exactly with the difference you mention. See below at point 3.

We (OFBiz team) did not invent but followed a scheme used by TLP (Top Level 
Projects) at the ASF.
See the "Available projects" dropdown at 
https://lists.apache.org/list.html?d...@ofbiz.apache.org
BTW, OFBiz (born in 2001) was the 26th TLP to join the ASF (in mid 2006).

1. There is no SaaS offering for Ofbiz. That means, if you are an end user,
you will not be able to use Ofbiz if you don't know how to install it.
2. If there are some bugs or minor modifications needed in Ofbiz to make it
work for the specific case of the company that is using it, there is still
a need for a developer to make the changes.
3. You will most definitely need support as an end user.

For these reasons I believe the end user will actually benefit most from
Ofbiz when there is a company that supplies Ofbiz as a service, as is the
case for example with Hot Wax Systems.

We have a list of service providers, maybe not always up to date (as you are a 
contributor you could update it ;)
https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Service+Providers


In this regard I believe the Ofbiz Project itself should focus on the
developer as it's main 'customer', or user, and use this information when
there is a need to make decisions.

As long as a developer is not involved in developing OFBiz itself, the user ML 
should be used, simple as that.


If the project would decide to move towards a more developer friendly
approach, then I have the following improvements/practices to propose:

1. Simplicity: Focus on simple code, avoiding unnecessary complexity.
- This could translate as taking a service implementation and breaking it
up in several classes, or methods, each with it's own scope and objective.
This would make unit testing a specific component feasible. As an example
the createOrder method from the OrderServices has 970 lines. Those could be
split up in multiple classes and methods.

Advices are always welcomed, implementation even more :)


2. Feedback: Continuous feedback from the system. Are tests run after each
commit? Is there a place where we can see the test results, so we can find
out if our commit(or PR) broke something?

Our CI takes care of that. Particularly BuildBot, look for "ofb" at 
https://ci2.apache.org/#/builders
More information at 
https://github.com/apache/ofbiz-tools/blob/master/documentation/BuildBot/BuildBot.md


3. Test-Driven Development (TDD): Writing tests before the actual code to
ensure that it meets the required functionality.
- In the current state it is quite hard to write unit tests. Splitting up
services into smaller classes that can be mocked would make the code a lot
easier to test.

That sounds like a good idea.


4. Refactoring: Encourage refactoring.
- This of course assumes that there are proper tests in place. Also in
order to encourage refactoring I propose to add another item to the OFBiz
commit message template: 'Refactored', to aid the committers when reviewing
a PR, and to encourage developers to refactor code.

We had a discussion once where one of the main committer then said that all keywords used 
in the commit comment template could be replaced by "Improved".
When you fix a bug you improve the code, etc. :).
This said adding  "Refactored" to the template could be indeed helpful when 
nothing else but refactoring as been done.


Feedback or other proposals are welcomed.

Thanks for the ideas

Jacques

Reply via email to