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