Comment les énormes bibliothèques open source sont-elles maintenues alors que le code est loin des pratiques de «code propre»?

Je n'ai toujours pas l'expérience nécessaire pour écrire du code de haute qualité. Je lis donc des livres sur le sujet, tels que Clean Code de Robert C. Martin, et vérifie le code de bibliothèques connues pour améliorer mes compétences.

Bien que de nombreuses bibliothèques open source soient maintenues depuis des années, ce qui signifie qu’il est très improbable qu’elles ne soient pas sur la bonne voie, j’ai trouvé que le code dans beaucoup d’entre elles était loin des principes qui régissent l’écriture de code propre - par exemple, les méthodes contenant des centaines de lignes de code.

Ma question est donc la suivante: les principes du code propre sont-ils trop limités et nous pouvons nous en passer dans de nombreuses bibliothèques comme celles-ci? Sinon, comment maintenir d'énormes bibliothèques sans tenir compte de plusieurs de ces principes?

J'apprécierai toute brève clarification. Je m'excuse si la question semble être stupide de la part d'un novice.

MODIFIER

Consultez cet exemple dans la bibliothèque Butterknife - l’une des bibliothèques les plus connues de la communauté Android.

Bonne réponse ici déjà, mais laissez-moi dire un mot à propos de votre exemple butterknife : bien que je ne sache pas ce que le code fait, à première vue, il ne me semble pas vraiment incommode. Les variables et les noms de méthodes semblent avoir été choisis délibérément, le code est correctement mis en retrait et formaté, il contient des commentaires et les méthodes longues affichent au moins une structure en blocs.

Oui, cela ne suit en aucun cas les règles de "code propre" d'oncle Bob, et certaines méthodes sont sûrement trop longues (probablement toute la classe). Mais en regardant le code, je vois encore assez de structure pour pouvoir les "nettoyer" facilement en extrayant ces blocs dans des méthodes (avec un faible risque d'introduire des bogues lors de l'utilisation d'outils de refactoring).

Le vrai problème avec ce code est qu’ajouter un bloc, un bloc et un autre bloc fonctionne dans une certaine mesure, parfois sur plusieurs années. Mais chaque jour, le code devient de plus en plus difficile à évoluer, et sa modification et son test prennent un peu plus de temps. Et quand vous devez vraiment changer quelque chose qui ne peut pas être résolu en "ajoutant un autre bloc", mais qui nécessite une restructuration, alors vous souhaiterez que quelqu'un ait commencé à nettoyer le code plus tôt.

Les principes énoncés dans "Code propre" ne sont pas toujours acceptés de manière générale. Cela relève en grande partie du bon sens, mais certaines opinions de l'auteur sont plutôt controversées et ne sont pas partagées par tout le monde.

En particulier, la préférence pour les méthodes courtes n'est pas acceptée par tout le monde. Si le code d'une méthode plus longue n'est pas répété ailleurs, en extraire une partie d'une méthode distincte (pour obtenir plusieurs méthodes plus courtes), la complexité globale augmente, car ces méthodes sont désormais visibles pour d'autres méthodes qui ne devraient pas s'en soucier. C'est donc un compromis, pas une amélioration objective.

Les conseils du livre s’adressent également (comme tous les conseils) à un type de logiciel particulier: les applications d’entreprise. D'autres types de logiciels, tels que les jeux ou les systèmes d'exploitation, ont des contraintes différentes de celles des logiciels d'entreprise. Par conséquent, différents modèles et principes de conception sont en jeu.

Le langage est également un facteur: Clean Code suppose Java ou un langage similaire - si vous utilisez C ou Lisp, de nombreux conseils ne s'appliquent pas.

En bref, le livre est l’opinion d’une personne seule sur une classe de logiciels en particulier. Cela ne s'appliquera pas partout.

En ce qui concerne les projets open source, la qualité du code varie de catastrophique à géniale. Après tout, n'importe qui peut publier son code en open source. Mais si vous regardez un projet open source mature et réussi avec plusieurs contributeurs, vous pouvez être presque certain qu'ils ont consciemment opté pour un style qui leur convient. Si ce style est en contradiction avec une opinion ou une ligne directrice, alors (pour parler franchement) c'est la ligne directrice qui est fausse ou non pertinente, car le code de travail l'emporte sur les opinions.

Sommaire

Comme l'écrit JacquesB, tout le monde n'est pas d'accord avec le "code propre" de Robert C. Martin.

Les projets open source que vous avez trouvés "violés" par les principes auxquels vous vous attendiez sont susceptibles de comporter simplement d'autres principes.

Ma perseption

Il se trouve que je supervise plusieurs bases de code qui adhèrent beaucoup aux principes de Robert C. Martin. Cependant, je ne prétends pas vraiment qu'ils ont raison , je peux seulement dire qu'ils fonctionnent bien pour nous - et que "nous" est en fait une combinaison d'au moins

• la portée et l'architecture de nos produits,
• le marché cible / les attentes du client,
• combien de temps les produits sont maintenus,
• la méthodologie de développement que nous utilisons,
• la structure organisationnelle de notre entreprise et
• les habitudes, opinions et expériences passées de nos développeurs.

En gros, cela se résume à ceci: chaque équipe (qu’il s’agisse d’une entreprise, d’un département ou d’un projet open source) est unique. Ils auront des priorités et des points de vue différents et, bien entendu, ils feront des compromis différents. Ces compromis, et le style de code auquel ils résultent, sont en grande partie une question de goût et il ne peut être prouvé qu'ils sont "faux" ou "correct". Les équipes peuvent seulement dire "nous faisons cela parce que cela fonctionne pour nous" ou "nous devrions changer cela parce que cela ne fonctionne pas pour nous".

Cela dit, je pense que pour pouvoir gérer avec succès de grandes bases de code au fil des ans, chaque équipe doit s’accorder sur un ensemble de conventions de code qu’elles estiment appropriées aux aspects mentionnés ci-dessus. Cela peut signifier adopter des pratiques de Robert C. Martin, d'un autre auteur, ou inventer les siennes; cela peut vouloir dire les écrire formellement ou les documenter "par exemple". Mais ils devraient exister.

Exemple

Considérons la pratique consistant à "diviser le code d’une méthode longue en plusieurs méthodes privées".

Robert C. Martin dit que ce style permet de limiter le contenu de chaque méthode pour un niveau d'abstraction - comme un exemple simplifié, une méthode publique consisterait probablement des appels à des méthodes privées comme verifyInput(...), loadDataFromHardDisk(...), transformDataToJson(...)et enfin sendJsonToClient(...), et ces méthodes aurait les détails de la mise en œuvre.

• Certaines personnes aiment cela, car les lecteurs peuvent obtenir un aperçu rapide des étapes de haut niveau et choisir quels détails ils souhaitent lire.
• Certaines personnes ne l'aiment pas parce que, lorsque vous souhaitez connaître tous les détails, vous devez parcourir la classe pour suivre le déroulement de l'exécution (c'est à cela que JacquesB fait probablement référence lorsqu'il écrit sur l'ajout de complexité).

La leçon est la suivante: ils ont tous raison, car ils ont le droit d’avoir une opinion.

De nombreuses bibliothèques open source ne en fait souffrent de manière objective les pratiques de codage pauvres et sont maintenus avec difficulté par un petit groupe de collaborateurs à long terme qui peuvent faire face à la mauvaise lisibilité , car ils sont très familiers avec les parties du code qu'ils maintiennent le plus souvent . Refactoriser le code pour améliorer la lisibilité après le fait est souvent un effort herculéen, car tout le monde doit se trouver sur la même page, ce n'est pas amusant et cela ne paie pas, car de nouvelles fonctionnalités ne sont pas implémentées.

Comme d'autres l'ont dit, tout livre sur le code propre qui énonce quoi que ce soit contient nécessairement des conseils qui ne sont pas universellement acceptés. En particulier, presque toutes les règles peuvent être suivies avec un zèle excessif, remplaçant un problème de lisibilité par un autre.

Personnellement, j'évite de créer des fonctions nommées si je n'ai pas un bon nom pour elles. Et une bonne réputation doit être courte et décrire fidèlement ce que la fonction fait au monde extérieur. Cela est également lié au fait d’essayer d’avoir le moins d’arguments de fonction possible et de ne pas avoir de données inscriptibles au niveau mondial. Tenter de réduire une fonction très complexe en fonctions plus petites entraîne souvent de très longues listes d’arguments lorsque la fonction est réellement complexe. Créer et maintenir un code lisible est un exercice d'équilibre entre des règles de sens commun contradictoires. Lire des livres est une bonne chose, mais seule l’expérience vous apprendra à trouver la fausse complexité , c’est là que les gains de lisibilité sont réels.

La plupart des projets open source sont mal gérés. Il y a évidemment des exceptions à cela, mais vous trouverez beaucoup de déchets dans le monde du logiciel libre.

Ce n’est pas une critique de tous les propriétaires / gestionnaires de projets dont je parle des projets, c’est simplement une question de temps. Ces personnes ont plus à faire avec leur temps, comme leur véritable emploi rémunéré.

Au début, le code est l'œuvre d'une personne et est probablement petit. Et le petit code n'a pas besoin d'être propre. Ou plutôt, l'effort nécessaire pour rendre le code propre est plus important que l'avantage.

À mesure que le temps passe, le code est plus une pile de correctifs par beaucoup de personnes différentes. Les auteurs de correctifs ne se sentent pas propriétaires du code, ils veulent simplement que cette fonctionnalité soit ajoutée ou que celui-ci soit corrigé de la manière la plus simple possible.

Le propriétaire n'a pas le temps de tout nettoyer et personne d'autre ne s'en soucie.

Et le code devient gros. Et laid.

Comme il est de plus en plus difficile de se repérer dans le code, les utilisateurs commencent à ajouter des fonctionnalités au mauvais endroit. Et au lieu de corriger les bogues, ils ajoutent des solutions de contournement à d’autres endroits dans le code.

À ce stade, il n’ya pas que les gens qui s’en foutent, ils n’osent plus nettoyer, ils ont peur de tout casser.

Certaines personnes ont qualifié les bases de code de "punition cruelle et inhabituelle".

Mes expériences personnelles ne sont pas si mauvaises, mais j’ai vu quelques choses très étranges.

Il me semble que vous vous demandez comment cela fonctionne si personne ne fait ce qu’il est supposé faire. Et si cela fonctionne, alors pourquoi sommes-nous censés faire ces choses ?

La réponse, à mon humble avis, est que cela fonctionne "assez bien" , également connu sous le nom de " pire est mieux " philosophie . Fondamentalement, malgré l’histoire tumultueuse entre l’open source et Bill Gates, ils ont tous deux adopté la même idée, à savoir que la plupart des gens se soucient des fonctionnalités, pas des bogues .

Bien entendu, cela nous conduit également à la " normalisation de la déviance ", qui conduit à des situations telles que Heartbleed , où, exactement comme pour répondre à votre question, une pile de spaghettis de code source libre énorme et envahi par le grand public appelée OpenSSL a été " non nettoyée " pendant environ dix ans. , aboutissant à une faille de sécurité massive touchant des milliers de millions de personnes .

La solution consistait à inventer un tout nouveau système appelé LibreSSL , qui allait utiliser un code épuré , et bien sûr, presque personne ne l’ utilise .

Alors, comment maintenir d’énormes projets Open Source mal codés? La réponse est dans la question. Beaucoup d'entre eux ne sont pas maintenus dans un état propre. Ils sont patchés au hasard par des milliers de personnes différentes pour couvrir des cas d'utilisation sur des machines étranges et des situations auxquelles les développeurs n'auront jamais accès. Le code fonctionne "assez bien" jusqu'à ce qu'il ne fonctionne pas , lorsque tout le monde panique et décide de jeter de l'argent sur le problème .

Alors, pourquoi devriez-vous vous donner la peine de faire quelque chose "de la bonne façon " si personne d'autre ne le fait?

La réponse est que vous ne devriez pas. Vous faites ou vous ne le faites pas , et le monde continue à tourner, peu importe la raison, parce que la nature humaine ne change pas à l'échelle de la vie humaine . Personnellement, j'essaie seulement d'écrire du code en clair parce que j'aime ce que je ressens.

Ce qui constitue un bon code dépend du contexte, et les livres classiques qui vous guident sont, s’ils ne sont pas trop vieux pour parler de l’open source, du moins une partie de la tradition qui mène la guerre sans fin contre les mauvaises bases de code internes. Il est donc facile de négliger le fait que les bibliothèques ont des objectifs complètement différents et sont écrites en conséquence. Considérez les problèmes suivants, sans ordre particulier:

• Lorsque j'importe une bibliothèque ou d'une bibliothèque, je ne suis probablement pas assez expert en structure interne pour savoir exactement quelle fraction de sa boîte à outils me faut pour tout ce sur quoi je travaille, à moins que je ne copie quel Réponse Stack Exchange m'a dit de faire. Alors je commence à taper from A import(si c'est en Python, disons) et vois ce qui se passe. Mais cela signifie que ce que je vois dans la liste doit refléter les tâches logiques que je devrai emprunter, et c'est ce qui doit être dans la base de code. Les innombrables méthodes d'assistance qui le rendent plus court ne feront que me confondre.
• Les bibliothèques sont là pour le programmeur le plus inexpérimenté essayant d’utiliser un algorithme dont la plupart des gens n’ont que vaguement entendu parler. Ils ont besoin d'une documentation externe, qui doit refléter le code avec précision, ce qui est impossible si nous continuons à tout refondre pour rendre heureux les adeptes de la méthode courte et du one-one-one-chose.
• Toutes les méthodes de bibliothèque empruntées par les utilisateurs risquent de faire basculer le code dans le monde entier, avec des conséquences désastreuses si elles sont supprimées ou même renommées. Bien sûr, j'aimerais que Sklearn corrige la faute de frappe à Calinski-Harabasz , mais cela pourrait provoquer un autre incident concernant le pad gauche . En fait, d'après mon expérience, le plus gros problème de l'évolution des bibliothèques réside dans le fait qu'elles essaient trop d'adopter de nouvelles "améliorations" de code pour améliorer leur structure.
• En interne, les commentaires sont au mieux un mal nécessaire, pour toutes sortes de raisons que je n'ai pas besoin de régurgiter (bien que ces points exagèrent quelque peu). Un bon commentaire explique pourquoi le code fonctionne, pas comment. Mais les bibliothèques savent que leurs lecteurs sont des programmeurs compétents qui ne pourraient pas, par exemple, écrire-algèbre linéaire pour sortir d’un sac en papier. En d'autres termes, tout doit être commenté à propos de : pourquoi ça marche! (C'est une autre exagération.)
• Disons que vous mettez à jour quelque chose sur Github et attendez de voir si votre code sera accepté. Pourquoi le changement de code fonctionne-t-il? Je sais par expérience que refactoriser pour rendre le camping plus propre dans le cadre d'un engagement fonctionnel signifie souvent beaucoup d'économie de ligne, de réarrangement et de changement de nom, ce qui rend le travail de votre réviseur sans salaire plus difficile et pose d'autres problèmes susmentionnés.

Je suis sûr que les personnes plus expérimentées que moi peuvent mentionner d'autres points.

Il y a déjà beaucoup de bonnes réponses - je veux donner le point de vue d'un mainteneur open source.

Ma perseption

Je suis responsable de nombreux projets de ce type avec moins de code. Parfois, on m'empêche même d'améliorer ce code pour des raisons de compatibilité, car les bibliothèques sont téléchargées des millions de fois par semaine.

Cela rend le maintien plus difficile - en tant que membre principal de Node.js, il y a des parties du code que j'ai peur de toucher, mais il y a beaucoup de travail à faire malgré tout et les gens utilisent la plate-forme avec succès et l'apprécient. La chose la plus importante est que cela fonctionne.

Sur le code lisible

Quand tu dis:

J’ai trouvé que le code dans beaucoup d’entre eux était loin des principes visant à écrire du code propre - par exemple, des méthodes contenant des centaines de lignes de code.

Les lignes de code ne sont pas une grande mesure de sa lisibilité. Dans l’étude, j’ai analysé le lien avec le noyau Linux et une enquête auprès de programmeurs a révélé que le code "normal" (code attendu par les utilisateurs) et le code cohérent étaient meilleurs que le code "propre" du point de vue de la compréhensibilité. Cela correspond également à mon expérience personnelle.

Certains projets open source ne sont pas très accueillants

Linus "a déclaré " que Linux ne devrait pas avoir de débogueur intégré car les utilisateurs de débogueurs ne sont pas assez bons pour travailler sur linux et il ne veut pas en attirer plus.

Personnellement, je suis absolument en désaccord avec sa position là-bas - mais c'est aussi quelque chose que les gens font.

Un logiciel open source ne signifie pas nécessairement que plusieurs auteurs sont impliqués. Lorsqu'un logiciel (ou une unité de logiciel) est écrit par un seul auteur, des fonctions longues apparaissent fréquemment.

Cela vient de la nature du processus de développement. Une méthode simple se prolonge dans le temps, de nouvelles fonctionnalités sont ajoutées et des problèmes corrigés.

Les méthodes longues réduisent considérablement la compréhension de la fonctionnalité pour les nouveaux auteurs. Cependant, avec un seul auteur, c'est rarement un problème et le problème a tendance à être négligé. Une autre nature de l'open source est le fait qu'un grand nombre de logiciels n'est pas activement développé. Par conséquent, aucun travail de refactorisation ne permet, par exemple, de scinder des méthodes complexes en plusieurs méthodes simples.

Vous n'avez montré aucun exemple, mais si j'ai bien compris, cela est souvent lié au langage de développement. Certaines langues appliquent dès le début des règles strictes en matière de peluchage et de tests unitaires lourds (ou même TDD). Les tests unitaires et les tests unitaires préviennent généralement ce problème (il est difficile de tester les méthodes complexes / longues à l’unité).

En général, il est plus difficile de nettoyer le code si le logiciel est développé par un seul auteur et si d'autres contributeurs ne corrigent que de petits problèmes.