Bonjour,

Scrat wrote
> mais ne pourrait-on pas introduire dans le développement de Libre Office
> une véritable démarche qualité?

Je ne code pas sur LO puisque je ne connais pas le C++, mais je suis
régulièrement le développement de LO en regardant régulièrement la liste des
patchs introduits sur le code.
Il est faux de dire qu’il n’y a pas de démarche qualité. La suite est
beaucoup testée… Des tests, les dévs en ajoutent constamment.
http://linuxfr.org/news/sortie-de-libreoffice-5-3#qualit%C3%A9-de-code



Scrat wrote
> j'ai du mal à comprendre ces "effets de bords" systématiques qui
> bousillent des parties du code qu'on croyait (à tort) blindées chaque fois
> qu'on introduit de nouvelles fonctionnalités.

Oui, mais justement, ajouter des tests n’empêchent aucunement les
régressions. Ça empêche uniquement les régressions sur ce que vous testez,
mais ce n’est qu’une partie de ce qui est possible, quoi qu’on fasse. C’est
utile pour éviter des régressions mais pas les régressions.

Sur Grammalecte, j’ai plus de 6000 tests. J’en ajoute régulièrement. Ai-je
moins de régressions pour autant? Je n’en ai pas vraiment l’impression.
Certes, les bugs d’autrefois sont sécurisés pour éviter le retour des faux
positifs testés, pour garantir que certains fonctionnements… mais ça
n’empêche aucunement l’apparition de nouvelles régressions, de nouveaux
problèmes. Dès que j’ajoute une règle ou en modifie une autre, malgré tous
les tests, je sais que je vais avoir des effets de bord quelque part. Il y a
toujours une chose à laquelle je n’ai pas pensé, malgré mes efforts pour
envisager tous les cas de figure.



Scrat wrote
> N'est-il pas possible de programmer de façon plus "étanche", de sorte que
> chaque fonctionnalité ne puisse pas être affectée par toute modification
> d'une autre partie du code ?

Les effets de bord, c’est précisément ce qui est difficile à éviter avec le
C++, le langage s’y prête bien. Ce n’est pas pour rien que Mozilla a créé le
langage Rust, qui offre des mécanismes de sûreté.
https://www.quora.com/How-does-Rust-enforce-safety



> Vous prétendez vouloir sortir la meilleure suite bureautique, mais
> franchement, vous vous tirez dans le pied à chaque nouvelle version.
> Comment voulez-vous qu'un responsable de parc informatique déploie ce
> logiciel en entreprise s'il n'est pas assuré de la pérennité des
> fonctionnalités existantes ?

À mon avis, le problème n’est pas tant le développement que le marketing
fait autour de ces versions… Seules les dernières versions .6 ou .7
devraient être marquées stables… Si vous vous contentiez de ces versions,
auriez-vous autant à vous plaindre? Mais aurions-nous autant de testeurs si
on attendait autant pour déclarer stables ces versions?


Par ailleurs, réflexion faite, je pense aussi que TDF devrait engager
quelques dévs pour se focaliser sur les bugs les plus irritants pour la
communauté, établis par un processus de vote ou par un comité d’utilisateurs
quelconque. Les pauvres devront se contenter de faire de la correction de
bugs, mais je crois aussi que ça apaiserait les esprits. :)
Parce qu’il est vrai qu’on a le sentiment parfois que certains problèmes
sont injustement considérés comme non prioritaires. Comme celui des
lettrines. Préservez les documents, ça devrait être prioritaire.


Cordialement,
Olivier



--
View this message in context: 
http://nabble.documentfoundation.org/Methode-de-developpement-de-Libre-Office-tp4208151p4208750.html
Sent from the QA mailing list archive at Nabble.com.

-- 
Envoyez un mail à qa+unsubscr...@fr.libreoffice.org pour savoir comment vous 
désinscrire
Les archives de la liste sont disponibles à 
http://listarchives.libreoffice.org/fr/qa/
Tous les messages envoyés sur cette liste seront archivés publiquement et ne 
pourront pas être supprimés

Répondre à