Difficile

Salut à tous
J’ai 20 ans d’expérience en développement / conception informatique,( je le précise pour la suite).
Depuis 2 jours je me suis intéressé à Dolibarr, ayant fait le tour des autres propositions du marché.

D’un point de vue utilisateur je trouve l’outil assez intuitif et tout marche bien.
Par contre d’un point de vue développeur … c’est autre chose
Il y a beaucoup de travail effectué sur ce logiciel et je ne veux pas être malpoli, mais c’est très très dur de rentrer dedans.
La doc me semble pas forcément à jour (j’ai pris la version de dolibar7.0, peut être que la doc est obsoléte) mais bon.

  • les fichiers Tpl par exemple …comment l’outil les utilise
    [li]autres point: je veux changer le html généré pour utiliser bootstrap 4, bon et bien je ne vois pas du tout comment faire.
    Mais peut être n’est ce pas la philo de l’outil de pouvoir faire ça, je le conçois mais j’aurais aimé le savoir avant.[/li]
    [li]
    Je vois des fichiers de 1400 lignes… mais tous cela est illisible, in-maintenable
    [/li]

Au départ j’étais excité comme un poux, me disant enfin un truc qui marche, Open source (et c’est vrai que miraculeusement il marche), mais Dieu que c’est difficile pour un développeur.
Alors j’entends déjà « Oui mais moi c’est facile, etc … tu dois être une quiche. »
J’ai fait des systèmes autrement plus compliqués et qui me semblait beaucoup mieux fait, je ne me considère donc pas comme un nul.
Et je ne veux vexer personne.

Ma demande (pour en venir au fait): Y a t-il des schémas (permettant de comprendre le boot de l’appli par exemple, la création de module simple, sans que la doc ne parle de dev/skeletons qui n’existent pas ou autre billevesées, les requêtes SQL etc …
Y a t’il d’autres sources que la doc existantes ?

Merci

Je me permet de répondre car je viens de passer des 25 années de codage (DUT info en 91 …)
Oui le code est loin d’être structuré au mieux, rien que l’architecture des répertoires l’usage de notions utilisant des mots différents (project/projet, fichinter/interventional/fichEinter, …) me donne des cheveux blancs
Mais la base de l’open source c’est de faire du reverse ingéniering et quand j’ai commencé à développer mes premiers modules dans dolibarr et ben je ne m’en suis pas priée, même si effectivement j’y ai passé pas mal de nuit…
J’ai moi aussi lu du code foireux (et en tant que spécialiste développement access/excel VBA je peu t’assurer que j’ai eu souvent les yeux qui piquent…), mais d’apprendre en relisant les lignes de ses paires, analysant la structure des tables et en pestant encore aujourd’hui sur les petites choses qui changent au grée des versions (merci le remplacement de « tvalib » par « label » dans la gestion des taux de TVA…)

Ensuite pour ce qui en est de la documentation, je préfère de loin du code documenté que des docs à jours, mais rien ne t’empeche de produire une telle doc, N’est-ce pas la base de l’esprit libriste???

ET oui 94 pour moi… purée

bon tu vois depuis que j’ai écrit le message j’ai compris comment faire une requête sql, youpiee…
Ensuite oui je pense que je ferai une doc
Ensuite j’aurais besoin de vous pour avancer car je pense ne pas être à la fin de mes pérégrinations …

Et non je ne suis pas d’accord avec toi. On doit lire du code, c’est OK pour moi (d’ailleurs il est parfois pas du tout commenté) mais une bonne doc c’est bien. Ne serait ce que pour les mécanismes de base (un p’tit schema par exemple)
J’ai travaillé sur Laravel, Angular2 etc et sans une bonne doc ce serait la foire.

A très bientôt

Bonsoir à vous,
ceci est un necropost :happy:

En lisant vos retours, je vous trouve très gentil avec le code de Dolibarr.
Oui c’est un produit génial, qui fonctionne.

Mais une fois le capot ouvert… quelle catastrophe ! tout y est mélangé : les vues, les règles métiers, les objets, un code spaghetti (et pourtant j’aime les pâtes) insondable.
Des fichiers de 4000 lignes (!!!), pas d’utilisation de l’Autoload des classes, j’ai le sentiment que des couches superposées se sont multipliées au cours du temps et la découpe de l’architecture logicielle a été malmenée (SRP).

Bref, je viens de coder mon 2eme module, et franchement j’y laisse ma sérénité à chaque fois :happy:

Bonjour :happy:
C’est un sujet qui revient souvent. J’ai vu beaucoup de post de dev qui critiquaient le code Dolibarr. je les comprends pas de soucis. Mais après faut prosposer des trucs avancer réelement.
www.dolibarr.fr/forum/t/addstylesheet-addscript-for-header/26743/1
www.dolibarr.fr/forum/t/dolibarr-architecture/27203/1



https://github.com/Dolibarr/dolibarr/issues/2868
www.dolibarr.fr/forum/t/wiki-dolibarr-org/28266/1

Bref vous n’êtes pas le seul à le penser y’a pas de soucis. Mais après si vous êtes dev et que vous avez des compétences proposer des PR github
:wink:

1 J'aime

Bonjour,
oui c’est vrai vous avez entièrement raison :happy: j’y pense souvent même.
Si je devais ne faire qu’une seule chose là maintenant : ce serait un helper pour générer les vues et les composants.

Mais je me demande si ça ne vaudrait pas le coup de développer un new dolibarr en // qui serait basé sur un pattern MVC, et ensuite prévoir une interface pour migrer de l’ancien vers le nouveau dolibarr.
Un travail titanesque vu la richesse des fonctionnalités de Dolibarr actuellement, mais sur le long terme ce serait payant :happy:

Bonjour à tous,

Je viens de coder un petit module qui se met en frontal à ContratPlus pour notre workflow. Donc j’ai un retour concret sur cette discussion.

Utilisateur de Dolibarr depuis 2006 sinon et j’en ai installé aussi pas mal à droite à gauche. J’adore Dolibarr. J’ai aussi codouillé en PHP plusieurs fois, dont des sites marchands proprios à remonter, mais c’est pas un langage qui m’intéresse (je dirais même que je déteste le PHP), c’est le résultat qui me botte. Et de ce point de vue, Dolibarr est une réussite totale. Une communauté, des gens qui en vivent, une asso, un leader qui fait le job. J’ai assez d’ancienneté dans le libre pour affirmer que tout ça est une belle chance…

Je suis d’accord avec vous que coté code, ça ne vas pas trop. Et après ? C’est un logiciel qui date du début du siècle, que l’on peut mettre à jour très facilement et qui a plein de qualités. On ne va pas réécrire Dolibarr pour ça. Tout simplement parce que personne n’a le temps de faire ça sans gagner sa vie…

Ce que l’on pourrait améliorer :

- Une mailing list en français pour accélérer les échanges de la première communauté de contribution (les forums sont infernaux à suivre, même avec le RSS). J’écris l’anglais correctement mais ça doit limiter pas mal de monde, une ML en français ne ferait pas de mal.
- Normaliser le nommage dans Dolibarr : tout en anglais et consistant ? Un travail de titan… Pourtant… entre les noms de tables, de classes de fonctions et de variables, à moitié en franglais, je plains les contributeurs étrangers.
- Le MVC… mouis mais pas que… Il faudrait (en théorie) revoir plus que ça. Mais bon…

Comme je ne connaissais rien au code de Dolibarr, j’ai fais au plus efficace : un vrai IDE intuitif (on est obligé d’avoir un IDE sur un gros projet inconnu), que j’utilisais déjà quand je devais taffer en Java : Netbeans mais dans sa version netbeans php 8.2 et on est tout prêt pour tracer avec xdebug. sans aucun setup (rien à voir avec Eclipse) ! Le goodie est qu’en plus on a accès aux tables en interne, comme si c’était des sources. Et comme Dolibarr, l’IDE Netbeans se prend en main en deux secondes…

Finalement, le code source est devenu ma doc puisque la doc n’est pas à jour ou incomplète. Puis un gros travail d’observation (genre les tables avant et après telle ou telle opération car il y a beaucoup de non dits, donc le « avant/après » est le juge de paix).

Ensuite, faut avouer que pour un simple plugin avec un trigger et un peu de calcul, j’en ai bavé… Mais les triggers, les hooks et les autres ouvertures sur le core permettent de faire de bien belles choses… j’en ai bavé pour comprendre comment tourniquait globalement Dolibarr (j’ai du assimiler 10% hihi). Un tel projet ne s’intègre pas en deux jours.

Par contre le rapport production/ temps du développeur est vraiment mauvais. C’est pas nécessairement Dolibarr qui est en cause (vu la taille du projet) mais faut avouer qu’il y est pour quelque chose. Il manque un mooc, une vraie doc pratique, etc… PHP est aussi en cause. Coder avec un tel langage prends du temps. Plus le langage est fragile plus le dev doit être attentionné. Avec certains langages, je code sans debuggeur. Avec PHP, je suis tout le temps en train de tracer. C’est un langage en carton alors je dois être en béton.

Les cotés positifs de Dolibarr sont par contre si nombreux qu’il ne faut pas s’embourber sur tout ça. C’est un logiciel incroyablement modulaire et qui fait un job phénoménal, tout en étant simplissime d’utilisation. Il a su évoluer depuis plus de 15 ans vers un résultat incroyable. Il a des qualités de fond uniques dans le libre. Et enfin, il a une vraie compta. Bref SAGEBP dans ton fondement, Dolibarr vaincra :wink:

Voilà…

Je tiens à signaler aussi que Laurent est réactif et m’a aidé.
Un big up à toute la communauté aussi, ainsi qu’à Régis s’il passe dans le coin.

Amicalement à tous,

Stef (Ile d’Oléron)

1 J'aime

Salut,

Pour le MOOC, c’est encours : www.dolibarr.fr/forum/t/bientot-l-ecole-dolibarr/28627/1

Bonjour,
Je partage aussi l’avis de wtf1.
Si l’on se réfère à un article publié par OCTO en 2013 http://blog.octo.com/les-nouvelles-architectures-front-web-et-leur-impact-sur-les-dsi-partie-1/ , Dolibarr a une architecture de type « Modèle 1 » .
De plus, Dolibarr n’utilise pas de moteur de template, ce qui permettrait de diminuer le nombre de lignes de code et séparer le traitement de l’affichage.
Au final, Dolibarr se retrouve avec 738000 lignes de code alors que Odoo (*) qui a une architecture de type « Modèle 3 » en est à 457000 (source : https://www.openhub.net/p/dolibarr , https://www.openhub.net/p/odoo ) et que Odoo a selon moi un périmètre fonctionnel plus important.

Je pourrai évoquer aussi que le code Dolibarr n’est pas orienté objet et que l’accès aux données ne se fait pas via un ORM mais directement en SQL.

(*) version communautaire - hors modules tiers type OCA

Bonjour Mayjo79 et bienvenu chez Dolibarr !

Je vois que votre société est un promoteur de Odoo, donc votre commentaire ne m’étonne pas.
Comparer le nombre de lignes de code, on nous l’avait encore jamais fait… surtout pour deux logiciels qui n’utilisent pas le même language (Pyton vs php) ça n’a pas beaucoup de valeur.
Tout le monde sait que php ça fait pas de beau code bien optimisé et c’est même souvent moche, mais pourtant tout le monde l’utilise pour ça simplicité !

Et dire que Odoo est Open source, aujourd’hui ? c’est plus vraiment le cas.

Dolibarr a des qualités et des défauts mais le MVC et toutes les optimisations grâce au Web MV sur un ERP ??? C’est pas ça le point important pour un ERP

Et dans tous les cas, comme Dolibarr est un VRAI logiciel libre, vous pouvez forker/Agrémenté/ameliorer etc. A votre bon cœur !

Odoo a effectivement changé en 2015 de modèle en passant d’un modèle « open-source » à un modèle « open-core ».
Je l’expliquais à l’époque dans cet article : https://agipme.fr/2015/05/changement-de-licence-libre-pour-odoo-22.html
A ce jour le coeur d’Odoo (édition communautaire) est open-source et ses nombreux modules communautaires qui le sont également (ex: OCA- https://github.com/oca ), en font une solution complète et « open-source ».

Concernant votre réponse sur la taille du code, PHP n’est pas reconnu comme spécialement plus verbeux que Python.
L’indicateur « nb lignes de code » ne me paraît pas complétement délirant !!

Salut
On est reparti pour un comparatif Odoo vs Dolibarr ?
Je rejoins ksar pour sa remarque, la comparaison du nombre de lignes de code n’a aucun intérêt.
Comparez les fonctionnalités plutôt et au même coût !

Sinon
Oui le mode de dev pourrait être mieux !
Oui la mise en place de templates indépendantes du core serait mieux !
Oui …
Citation : N’oubliez jamais que le mieux est l’ennemi du bien !

Mais l’écosystème Dolibarr n’est pas le même que celui de Odoo.
On manque de devs, bienvenu à la maison :lol:
@+

Salut Mayjo79,

et donc ton objectif en venant poster ici ? (à part faire de la pub pour odoo :wink: )

Vous remarquerez que c’est l’administrateur du forum qui a déduit et publié que je travaillais sur Odoo.
Moi, il s’avère que récemment j’ai voulu me remettre à Dolibarr et que je suis tombé sur cet échange.
J’ai juste voulu approuver wtf1 par un autre prisme.

Je tiens à préciser que je peux être critique aussi envers Odoo : https://agipme.fr/2015/10/odoo-9-jaime-je-naime-pas.html ou https://agipme.fr/2014/02/openerp-v8-avec-cms-et-e-commerce.html

Bonjour :happy:
Je comprends le point de vue : Dolibarr = à l’ancienne.

  • en 2000 il fallait faire des menu ou des sites en flash en 800*600 ou des iframes
  • en 2005 il fallait faire des sites accessibles
  • en 2010 il fallait faire des sites en ajax
  • en 2015…

Bref pas facile de faire évoluer en fonction de la tendance un programme en un clin d’œil…

Ce que j’en conclus :

  • participer au code qui est accessible à tous
  • faire parti de l’asso et prendre des décisions

Dans tout les cas merci pour vos avis :sunglasses: