|
From: | Destailleur Laurent |
Subject: | Re: [Dolibarr-dev] We need bug fixers, not feature developers ! |
Date: | Mon, 24 Feb 2014 17:54:21 +0100 |
Indeed, this is an important reminder.I'm guilty as much as anyone of working on new features without fixing enough broken code.But, as you may know, it's relatively easy to get paid for working on new features while it's nearly impossible for bug fixing..On the other hand, the Dolibarr codebase suffer from an old and intricate coding structure that don't help fixing bugs efficiently and keeping them that way.
IMHO, even before squashing bugs, it needs a big overhaul of its internal structure.From the top of my head, here are the issues I'm constantly fighting with :
- Inconsistent coding style (cf. Florian post)
- Relatively Inefficient bug tracker. (Personal opinion)
- Classes inconsistency and missing a lot of utility methods. (See next point)
- Duplicated code all over the place that should be factored into the native objects. This makes maintenance a nightmare.
- Inconsistent API with half french naming and all.
- Not using parameterized queries and field tested database drivers such as PDO.
- Not using a internationalization/localization toolkit such as gettext
- Legacy libraries with bad design decisions (Yes, I'm looking at you PDF documents)
- I forgot a lot of other issues.
I wanted to keep that discussion for the DevCamp but since I already opened the pandora box, here's my thinking:As you stated, Dolibarr is now a mature piece of software.Since removing code is the best way to reduce bugs, maybe it's time to start a disruptive 4.0 development cycle with ambitious objectives and set everything else on maintenance only mode.Here's what would be my go-to list:
- Unify coding style (PSR preferred here because it's community driven, clearly defined and sees massive adoption).
- Reduce codebase by redesigning objects and nicely factoring existing code.
- Fully embrace OOP and other modern PHP features.
- Parameterized SQL queries and unified database driver (PDO).
- English only code and comments.
- Gettext translation support.
- Get rid of legacy libraries.
- Break the API, yes, let's break it bad for the greatest good, it's a new release after all.
- HTML5 pages.
- Document, document and document (With better discussions on API design, code comments…).
- Rolling releases with automatic updates? Ok, maybe it's too much for now!
Yes, this is a lot of work but it won't be doing itself if we don't set the goal.Oh, now, I should get back to coding new features I'm being paid for…
Cheers,2014-02-24 11:59 GMT+01:00 Destailleur Laurent <address@hidden>:
I used a title that may hurt every developer. This is just to be sure everybody read my note ;-)Dolibarr is now a very large success among a very large number of users but also developers.During 3.5 beta and still now, we had received a lot of (too much ?) number of Push request for new feature, but nearly no code to fix bug.80% of request coming from external developers was new feature. Each request to add feature introduce around 2 bugs (this is an average value). This means to keep the bug ratio to same level we nee to spend 66% of code change (PR) to fix bug and 33% of code change (PR) to add new features.Because external submission are 80% of PR (Pull Request) to add new feature, we are far away of this ratio. The only one solution we had to not see the bug rate increase dangerously is to have the core team to work ONLY on bug fixes.This is what happened during all the 3.5 period (so several month). But this means also there is less time to validate "major" pull requests of really intersting new features.So some of you may see their pull request with status "pending" even several month after submitting them. Sorry for that. And after a long time, i will probably have to discard completely this pull request that can't be merged easily. Sorry 2.There is now so many people using Dolibarr, that keeping quality and keeping bug rates under control must be a priority, before adding new feature. But this does not mean we will slow down the increase f new feature. This just means that the conclusion is a strange paradox: if you want to help dolibarr project to increase the number of feature, make priority on bugs fix on old feature !(so bug rate will go down and if bug rate goes down, you will see new feature appears more quickly !)...Does this means Dolibarr popularity is growing too quickly ? May be, but this is a good news, isn't it ?
All this text to finally thanks all guys (core team and others) that helped me to fix bugs during the 3.5 beta ! and just after the release of 3.5. I hope they will understand it is a bug thanks !PS: Well 3.5.1 will be released very soon with result of all fixes...PPS: To find what are opened bugs, just create an account on doliforge.org and go onto this report:
And use the comments of tickets to ask advice on how you can fix a selected bug...
Laurent, Dolibarr main project leader------------------------------------------------------------------------------------Twitter: http://www.twitter.com/eldy10_______________________________________________
Dolibarr-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
--Raphaël DoursenaudDirecteur technique (CTO)
Technopole Hélioparc2 avenue du Président Pierre Angot64053 PAU CEDEX 9SARL GPC.solutions au capital de 7 500 € - R.C.S. PAU 528 995 921
_______________________________________________
Dolibarr-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
[Prev in Thread] | Current Thread | [Next in Thread] |