Discussion :

[Aeson]

Mais si tu nous parlais un peu de ton Kernel a architecture en Micro Service ? J ai 25 Nuget dans mon projet... je fais du Microservice 🤣🤣

[yildiz-online]

Mais si tu nous parlais un peu de ton Kernel a architecture en Micro Service ? J ai 25 Nuget dans mon projet... je fais du Microservice 🤣🤣

Si tu confonds module/librairie et service, ça va être compliqué.

Je te conseille Software Architecture Patterns, de Mark Richards, c'est un bon bouquin pour débuter.

[Aeson]

Je sais très bien ce que c est... tracasse... aucun rapport avec un Kernel.... c est toi qui est venu avec ce terme sans aucun rapport..

Tu me reproche d etre hors sujet mais après tu parle d architecture
Microservice...

Avoue... t es un pingouin extrémiste et t as pas supporté qu on ose parler mal de ta secte... 🤣🤣🤣 c est tout...

[bombseb]

Désolé, mais moi je pense que le nombre de lignes de code supprimées ou ajoutées est un indicateur parmis d'autres de la vitalité d'un projet.
Certe ca n'est pas un gage de qualité mais c'est un indicateur interressant

[Steinvikel]

Je pense pouvoir dire sereinement, comme ça a été évoqué à plusieurs reprise avant, que le nombre de lignes ajoutés/supprimés (ça comprend celles modifiés aussi ?), est un indicateur direct du "dynamisme" du projet. Et que le nombre de lignes constituant le code est un autre indicateur ...non pertinent pour la qualité, mais qui y est tout de même relié. Plus un projet est gros, plus il requiert de rigueur, certains outils d'aide ou d'automatisation y deviennent indispensables, est certaines étapes, critiques. >> beaucoup de lignes = statistiquement plus de défauts, la qualité c'est pas le nombre absolu de défauts, c'est son ratio, en proportion à la taille (pour faire simple).
C'est très facile d'avoir une très bonne qualité pour un programme de 100 lignes... nettement moins pour un autre de plus de 1 000 000. Que ce soit par programmation procédurale ou non.

personne ne s'est pâmé devant la qualité du code, donc pourquoi venir et dire que ce n'est pas un indicateur?

Jusqu'à preuve du contraire, tout le monde à le droit de donner son avis. Il a souhaité rappeler que faire un lien directe entre "taille" et "qualité" serait une fausse conclusion... pourquoi t'évertuer à le blamer pour ça ? Tu as exprimé ton désaccord, lui également... il n'y a plus de raison de continuer, à moins d'essayer d'avoir le dernier mot. Si tel est le cas, sachez tout les deux, que lire des messages chargés de haine et de discrédit, sont désagréables à lire, pour votre opposant, comme pour le lecteur lambda.

Connaître le nombre de lignes ajoutée est une valeur intéressante sur la progression du projet, pas sur sa qualité, on peut en déduire si il attire plus de contributeurs, et faire une corrélation avec le nombre de fonctionnalités introduites dans le laps de temps étudié.
Il est également intéressant de connaitre la participation des sociétés impliquées, nulle question de "qui à la plus grosse" vu qu'on a pas vraiment de point de comparaison possible avec les autres OS grand public qui sont fermés.

Le monde n'est pas binaire, ce n'est pas parce que la taille n'est pas un indicateur direct, qu'il n'en est pas un indicateur du tout. Tout est histoire de corrélation, les acteurs de big datas l'ont bien compris depuis longtemps (ex: le profilage des régies publicitaires).
Question noyaux, c'est effectivement difficile de comparer avec un autre aussi dynamique, mais question OS (ou distribution) c'est déjà plus aisé, en voici quelques'uns :
lecture --> - la distribution historique (les variantes principales [les variantes de variantes])

- Debian (SteamOS, Ubuntu [Lubuntu [LXLE], Xubuntu, Hybryde Linux, Emmabuntüs Debian Edition... Elementary OS, Triskel, Linux Mint, BackTrack, GendBuntu, Ubuntu Kylin], Linux Mint Debian Edition, CrunchBang (#!), Pure OS, Tails, PuppyLinux (tahr)[DoudouLinux, PrimTux] ...Raspian [OSMC])
- Slackware (SuSE [OpenSUSE, SUSE Linux Enterprise], PuppyLinux (slacko)[ToutouLinux, Legacy OS, ASRI Edu])
- Red Hat entreprise (Mageia, Fedora [BLAG Linux et GNU], CentOS, Oracle Linux, Scientific Linux)
- Arch (Manjaro, Parabola GNU/Linux-libre)
- Gentoo (Chrome OS [Chromium OS], Ututo XS, CLIP)
- Android (CyanogenMod [LineageOS])

la taille n'est certainement pas significative dans tous les cas, elle pourrait l'être pour les soft monolithiques, mais tout ce qui est modulaire n'est pas concerné.

...et quand tu développes une solution pour ttes les intégrer /interfacer, tu t'aperçois qu'elles ont toutes des merdes par ci par là, différentes, et que mettre en accord tout ce petit monde pour que ça fonctionne à merveille, s'avère finalement plus difficile que d'avoir incorporé cette "homogénéité/cohérence" dès leurs développement. Est-ce une fausse idée reçu ?

...salutations respectueuses, sans animosité, simplement chargé de désaccords.

[yildiz-online]

Jusqu'à preuve du contraire, tout le monde à le droit de donner son avis. Il a souhaité rappeler que faire un lien directe entre "taille" et "qualité" serait une fausse conclusion... pourquoi t'évertuer à le blamer pour ça ? Tu as exprimé ton désaccord, lui également... il n'y a plus de raison de continuer, à moins d'essayer d'avoir le dernier mot. Si tel est le cas, sachez tout les deux, que lire des messages chargés de haine et de discrédit, sont désagréables à lire, pour votre opposant, comme pour le lecteur lambda.

Comme tu le dis, tout le monde à le droit de s'exprimer, si mes propos ne te conviennent pas, tu as la fonctionnalité ignorer à disposition.

Le monde n'est pas binaire, ce n'est pas parce que la taille n'est pas un indicateur direct, qu'il n'en est pas un indicateur du tout. Tout est histoire de corrélation, les acteurs de big datas l'ont bien compris depuis longtemps (ex: le profilage des régies publicitaires).

Lorsque je fais une étude pour introduire une nouvelle technologie pour les équipes de développement, jamais je n'ai considéré la taille comme un indicateur, par contre ce qui m'intéresse:
-La licence
-La maturité
-Le nombre et date des commits
-La documentation
-La disposition d'un support
-L'activité dans le bugtracker
-La connaissance du produit sur le marché.
-La courbe d'apprentissage
-Le prix

...et quand tu développes une solution pour ttes les intégrer /interfacer, tu t'aperçois qu'elles ont toutes des merdes par ci par là, différentes, et que mettre en accord tout ce petit monde pour que ça fonctionne à merveille, s'avère finalement plus difficile que d'avoir incorporé cette "homogénéité/cohérence" dès leurs développement. Est-ce une fausse idée reçu ?

Cela dépend de différents facteurs, si les modules font partie d'un même écosystème, il s'intégreront naturellement assez facilement si des standards ont été établis.
Il y a également la possibilité d'avoir recours à des contrats (WSDL, WADL, SWAGGER... pour des web services, design by contract pour des librairies).
Ou encore de passer par des middleware entre services(broker, ESB) ou des patterns entre librairies (bridge, anticorruption layer pour archi hexagonale...) qui fourniront une abstraction.

Sinon, tout ajout de dépendance exogène est évidemment un risque.

[Steinvikel]

ok, merci pour le retour.

Sinon, pour en revenir sur l'histoire de qualité, j'ai l'impression que j'ai pas encore réussi à me faire comprendre.
Quand je disais que chacun à le droit d’apporter son opinion, c'est parce que tu reprochais à Aeson d'avoir fait un lien entre taille et qualité, alors que ce lien n'est pas présent dans l'article. Il avait simplement apporté un éléments nouveau, en plus, et ton argumentaire exposait en premier lieu le fait qu'il apportait cet élément, non pas que cet élément était faux? J'ai donc défendu en premier lieu la liberté d'expression.

J'ai pas réussi à saisir le lien entre "taille" et "qualité" dans ton analogie avec "taille" et l'étude d'une "nouvelle techno".
Dans mes précédents exemples, "taille" était l'un des critères pouvant définir la qualité, la qualité de la solution sur laquelle tu l'appliques.
Pour l'étude d'une techno langage, ce pourrait être la taille de la RFC par exemple. Comme je me le répète, ce n'est pas pertinent, ça ne m'étonne donc pas que tu n'utilises pas ce critère.

Une techno qui est adopté pour une solution, on peut y faire exactement le même lien pour la taille de la solution (son dimensionnement) pour du code ou pour autre chose. non ?
Ce lien n'est pas pertinent, oui, mais c'est un lien.
ex: faire une cloche pour une marmite, pour un haut-fourneau, ou pour une cuve de réacteur nucléaire, peut faire appel à une même technique, mais chaque fois qu'elle sera employé dans une dimension plus conséquente, verra ses défauts exacerbés. Il faut alors développer d'autres méthodes/techno, soit pour remplacer, soit pour compléter, compenser /corriger /inhiber ces défauts.
Je vois le même paradigme dans le management, et le codage.
<troll> Je finirai par rappeler que ce n'est pas parce que tu ne le vois pas qu'il n'existe pas </troll>

Pour toi la taille n'a absolument aucun rapport de près ou de loin avec la qualité d'un code, aucuns rapprochements possibles, de manière absolu, ou statistiquement. Soit, c'est ton point de vu, et le mien est différent. Je pense que nous n'avons plus aucun intérêt à poursuivre plus loin, ayant chacun apporté nos éléments.