Comment les immenses bibliothèques open source sont-elles maintenues tout en ayant du code loin des pratiques de "code propre"?
Je suis encore inexpérimenté pour écrire du code de haute qualité, donc j'ai lu des livres traitant du problème tels que Clean Code par Robert C. Martin, et continue à vérifier le code de bibliothèques bien connues pour améliorer mes compétences .
Bien que de nombreuses bibliothèques open source aient été maintenues pendant des années, ce qui signifie qu'il est très peu probable qu'elles ne soient pas sur la bonne voie, j'ai trouvé que le code dans beaucoup d'entre elles était loin des principes abordés pour écrire du code propre - par exemple des méthodes contenant des centaines de lignes de code.
Ma question est donc la suivante: les principes du code propre sont-ils trop restreints et nous pouvons nous en passer dans de nombreuses bibliothèques comme celles-ci? Sinon, comment les immenses bibliothèques sont-elles maintenues sans tenir compte de bon nombre de ces principes?
J'apprécierai toute brève clarification. Je m'excuse si la question semble stupide de la part d'un débutant.
[~ # ~] modifier [~ # ~]
Vérifiez ceci exemple dans Butterknife bibliothèque - l'une des bibliothèques les plus connues de Android communauté.
Bonne réponse ici déjà, mais permettez-moi de dire un mot sur votre butterknife exemple: bien que je n'aie aucune idée de ce que fait le code, à première vue, il ne me semble pas vraiment impossible à maintenir. Les variables et les noms de méthode semblent être choisis délibérément, le code est correctement mis en retrait et formaté, il a quelques commentaires et les méthodes longues montrent au moins une certaine structure de bloc.
Oui, il ne suit en aucun cas les règles de "code propre" d'oncle Bob, et certaines des méthodes sont sûrement trop longues (probablement toute la classe). Mais en regardant le code, je vois encore assez de structure pour qu'ils puissent être facilement "nettoyés" en extrayant ces blocs dans des méthodes par eux-mêmes (avec un faible risque d'introduire des bogues lors de l'utilisation d'outils de refactoring).
Le vrai problème avec un tel code est que l'ajout d'un bloc et d'un autre bloc et d'un autre bloc fonctionne dans une certaine mesure, parfois sur plusieurs années. Mais chaque jour, le code devient plus difficile à faire évoluer un peu, et il faut un peu plus de temps pour le modifier et le tester. 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 le "Code propre" ne sont pas toujours généralement acceptés. La plupart sont du bon sens, mais certaines des 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 dans une méthode distincte (vous obtenez ainsi plusieurs méthodes plus courtes) augmente la complexité globale, 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 contenus dans le livre sont également (comme tous les conseils) axés sur un type particulier de logiciel: les applications d'entreprise. D'autres types de logiciels comme les jeux ou les systèmes d'exploitation ont des contraintes différentes de celles des logiciels d'entreprise, de sorte que 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, beaucoup de conseils ne s'appliquent pas.
En bref, le livre est une opinion individuelle sur une classe particulière de logiciels. Cela ne s'appliquera pas partout.
Quant aux projets open source, la qualité du code varie de lamentable à brillante. 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 sûr qu'ils ont consciemment choisi un style qui leur convient. Si ce style est en contradiction avec une opinion ou une directive, alors (pour le dire franchement), c'est la directive qui est fausse ou non pertinente, car le code de travail l'emporte sur les opinions.
Résumé
Comme l'écrit JacquesB, tout le monde n'est pas d'accord avec le "Clean Code" de Robert C. Martin.
Les projets open source que vous avez trouvés "violant" les principes que vous attendiez sont susceptibles d'avoir simplement d'autres principes.
Mon point de vue
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
- l'étendue et l'architecture de nos produits,
- le marché cible/les attentes des clients,
- 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, les opinions et l'expérience passée de nos développeurs.
Fondamentalement, cela se résume à: chaque équipe (que ce soit une entreprise, un département ou un projet open source) est unique. Ils auront des priorités et des points de vue différents, et bien sûr ils feront des compromis différents. Ces compromis, et le style de code qu'ils entraînent, sont en grande partie une question de goût et ne peuvent pas être prouvés "faux" ou "bons". Les équipes peuvent seulement dire "nous faisons cela parce que cela fonctionne pour nous" ou "nous devons changer cela parce que cela ne fonctionne pas pour nous".
Cela dit, je pense que pour être en mesure de maintenir avec succès de grandes bases de code au fil des ans, chaque équipe devrait convenir d'un ensemble de conventions de code qui, selon elle, conviennent aux aspects donnés ci-dessus. Cela peut signifier adopter des pratiques de Robert C. Martin, d'un autre auteur, ou inventer les leurs; cela peut signifier les écrire officiellement ou les documenter "par l'exemple". Mais ils devraient exister.
Exemple
Considérez la pratique de "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 à un niveau d'abstraction - comme exemple simplifié, une méthode publique ne consisterait probablement qu'en appels à des méthodes privées comme verifyInput(...), loadDataFromHardDisk(...), transformDataToJson(...) et enfin sendJsonToClient(...), et ces méthodes auraient les détails d'implémentation.
- Certaines personnes aiment cela parce que les lecteurs peuvent obtenir un aperçu rapide des étapes de haut niveau et peuvent choisir les détails sur lesquels ils souhaitent lire.
- Certaines personnes ne l'aiment pas parce que lorsque vous voulez connaître tous les détails, vous devez sauter dans la classe pour suivre le flux d'exécution (c'est ce à quoi JacquesB fait probablement référence lorsqu'il écrit sur l'ajout de complexité).
La leçon est: tous ont raison, car ils ont le droit d'avoir une opinion.
De nombreuses bibliothèques open source souffrent en fait de objectivement de mauvaises pratiques de codage et sont maintenues avec difficulté par un petit groupe de contributeurs à long terme qui peuvent gérer la mauvaise lisibilité car ils connaissent très bien les parties de le code qu'ils gèrent le plus souvent. Refactoriser le code pour améliorer la lisibilité après coup est souvent un effort herculéen car tout le monde doit être sur la même page, ce n'est pas amusant et cela ne paie pas car aucune nouvelle fonctionnalité n'est implémentée.
Comme d'autres l'ont dit, tout livre sur le code propre énonçant 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 un bon nom doit être court 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 pas de données accessibles en écriture à l'échelle mondiale. Essayer 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 était véritablement complexe. La création et le maintien d'un code lisible est un exercice d'équilibre entre des règles de bon sens mutuellement conflictuelles. La lecture de livres est bonne, mais seule l'expérience vous apprendra à trouver fausse complexité, c'est là que les gains de lisibilité réels sont réalisés.
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 open-source.
Ce n'est pas une critique de tous les propriétaires/gestionnaires de projets dont je parle, c'est simplement une question de temps utilisé. Ces personnes ont mieux à faire avec leur temps, comme leur véritable emploi rémunéré.
Au début, le code est l'œuvre d'une seule 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.
Au fil du temps, le code est plus une pile de correctifs par un grand nombre de personnes différentes. Les rédacteurs de patchs ne se sentent pas propriétaires du code, ils veulent juste que cette fonctionnalité soit ajoutée ou que ce bug soit corrigé de la manière la plus simple possible.
Le propriétaire n'a pas le temps de nettoyer les choses et personne d'autre ne s'en soucie.
Et le code prend de l'ampleur. Et laid.
Comme il devient de plus en plus difficile de trouver votre chemin dans le code, les gens commencent à ajouter des fonctionnalités au mauvais endroit. Et au lieu de corriger les bogues, ils ajoutent des solutions de contournement à d'autres endroits du code.
À ce stade, ce n'est pas seulement que les gens s'en moquent, ils n'osent plus nettoyer car ils ont peur de casser les choses.
J'ai vu des gens qualifier les bases de code de "punition cruelle et inhabituelle".
Mes expériences personnelles ne sont pas si mauvaises que ça, mais j'ai vu quelques choses très étranges.
Il me semble que vous demandez comment cela fonctionne-t-il même si personne ne fait ce qu'il est censé faire. Et si cela fonctionne, alors pourquoi sommes-nous censés être faire ces choses ?
La réponse, à mon humble avis, est que cela fonctionne "assez bien" , également connu sous le nom de " pirec'est mieux " philosophie . Fondamentalement, malgré l'histoire mouvementée entre l'open source et Bill Gates, ils ont tous deux adopté de facto la même idée, que la plupart des gens se soucient des fonctionnalités, pas des bugs .
Bien sûr, cela nous conduit également à " normalisation de la déviance " qui conduit à des situations comme Heartbleed , où, précisément comme pour répondre à votre question, un énorme, envahipile de spaghetti de code open source appelé OpenSSL est allé " non nettoyé " pour quelque chose comme dix ans , se terminant par un massiffaille de sécurité affectant des milliers de millions de personnes .
La solution consistait à inventer un tout nouveau système appelé LibreSSL , qui était va utiliser du code de nettoyage , et bien sûr presquepersonnel'utilise .
Alors, comment sont maintenus les é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 cas d'utilisation sur diverses machines étranges et les situations que les développeurs auront jamais accès pour tester. Le code fonctionne "assez bien" jusqu'à ce n'est pas le cas , quand tout le monde panique et décide de jeter de l'argent au problème .
Alors, pourquoi devriez-vous prendre la peine de faire quelque chose ' dans le bon sens ' si personne d'autre ne l'est?
La réponse est que vous ne devriez pas. Soit vous faites ou vous ne faites pas , et le le monde continue de tourner de toute façon, parce que la nature humaine ne change pas à l'échelle d'un - humaindurée de vie . Personnellement, j'essaie seulement d'écrire du code propre parce que j'aime la façon dont on le ressent.
Il y a déjà beaucoup de bonnes réponses - je veux donner la perspective d'un mainteneur open source.
Ma perseption
Je suis le mainteneur d'un grand nombre de ces projets avec moins de bon code. Parfois, je suis même empêché d'améliorer ce code en raison de problèmes de compatibilité, car les bibliothèques sont téléchargées des millions de fois par semaine.
Cela rend la maintenance plus difficile - en tant que membre principal de Node.js, j'ai peur de toucher certaines parties du code, mais il y a beaucoup de travail à faire malgré tout et les gens utilisent la plate-forme avec succès et en profitent. La chose la plus importante est que cela fonctionne.
Sur un code lisible
Quand tu dis:
J'ai trouvé le code dans beaucoup d'entre eux loin des principes abordés pour écrire du code propre - par exemple des méthodes contenant des centaines de lignes de code.
Lignes de code ne sont pas une bonne mesure de la lisibilité. Dans l'étude que j'ai liée au noyau Linux a été analysée et une enquête auprès des programmeurs a trouvé que le code "normal" (code que les gens attendent fondamentalement) et le code cohérent sont meilleurs que le code "propre" en termes de compréhensibilité. Cela correspond également à mon expérience personnelle.
Certains projets open source ne sont pas trop accueillants
Linus "notoirement" a dit que linux ne devrait pas avoir de débogueur intégré car les personnes utilisant des débogueurs ne sont pas assez bonnes pour travailler sur linux et il ne veut pas en attirer davantage.
Personnellement, je suis absolument en désaccord avec sa position - mais c'est aussi quelque chose que les gens font.
Ce qui constitue un bon code dépend du contexte, et les livres classiques qui vous guident sont, s'ils ne sont pas trop anciens pour discuter de l'open source, au moins une partie d'une tradition menant la guerre sans fin contre les mauvaises bases de code internes. Il est donc facile d'ignorer le fait que les bibliothèques ont des objectifs complètement différents, et elles sont écrites en conséquence. Tenez compte des problèmes suivants, sans ordre particulier:
- Lorsque j'importe une bibliothèque ou à partir d'une bibliothèque, je ne suis probablement pas assez expert dans sa structure interne pour savoir exactement quelle petite fraction de sa boîte à outils j'ai besoin pour tout ce sur quoi je travaille, sauf si je copie ce La réponse de Stack Exchange m'a dit de le faire. Je commence donc à taper
from A import(si c'est en Python, disons) et voyez 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. D'innombrables méthodes d'assistance qui le raccourcissent me confondent. - Les bibliothèques sont là pour le programmeur le plus inexpérimenté qui essaie d'utiliser un algorithme dont la plupart des gens n'ont que vaguement entendu parler. Ils ont besoin d'une documentation externe, et cela doit refléter précisément le code, ce qui ne peut pas être fait si nous continuons à tout refactoriser pour rendre heureux les adhérents à la méthode courte et à la chose.
- Chaque méthode de bibliothèque que les gens empruntent pourrait casser le code du monde entier avec des conséquences désastreuses si elle était supprimée ou même renommée. Bien sûr, je souhaite que sklearn corrige la faute de frappe dans Calinski-Harabasz , mais cela pourrait provoquer un autre incident de gauche . En fait, d'après mon expérience, le plus gros problème avec l'évolution des bibliothèques, c'est quand ils essaient trop pour adopter une nouvelle "amélioration" de bon code dans la façon dont ils structurent tout.
- En interne, les commentaires sont au mieux un mal nécessaire, pour toutes sortes de raisons, 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 pouvaient pas, disons, écrire une algèbre linéaire pour sortir d'un sac en papier. En d'autres termes, tout doit être commenté: pourquoi cela fonctionne! (OK, c'est une autre exagération.) C'est pourquoi vous voyez une ligne de signature, un bloc de commentaires de 100 lignes, 1 ligne de code qui aurait pu littéralement être sur la ligne de signature (si la langue le permet, bien sûr).
- Disons que vous mettez à jour quelque chose sur Github et attendez de voir si votre code sera accepté. Il doit être clair pourquoi votre changement de code fonctionne. Je sais par expérience que le refactoring pour rendre le camping plus propre dans le cadre d'un engagement fonctionnel signifie souvent beaucoup d'économies de ligne, de réarrangement et de changement de nom, ce qui rend le travail de votre réviseur sans salaire plus difficile et provoque d'autres problèmes susmentionnés.
Je suis sûr que les personnes ayant plus d'expérience que moi peuvent mentionner d'autres points.
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, de longues fonctions apparaissent fréquemment.
Cela vient de la nature du processus de développement. Une méthode simple est étendue au fil du temps, de nouvelles fonctionnalités sont ajoutées et les bogues corrigés.
Les méthodes longues réduisent considérablement la compréhension des fonctionnalités pour les nouveaux auteurs. Cependant, avec un seul auteur, c'est rarement un problème et le problème a tendance à être ignoré. Une autre nature de l'open source est le fait que beaucoup de logiciels ne sont pas développés activement, donc il n'y a pas de travail de refactoring qui diviserait, par exemple, des méthodes complexes en plusieurs méthodes simples.
Vous n'avez montré aucun exemple, mais d'après ma compréhension, cela est également souvent lié au langage de développement. Certaines langues appliquent des règles strictes de peluchage dès le début et des tests unitaires lourds (ou même TDD). Les tests de peluchage et les tests unitaires empêchent généralement ce problème (il est difficile de tester les méthodes complexes/longues).
En général, il est plus difficile de nettoyer le code si le logiciel est développé par un seul auteur et que d'autres contributeurs ne résolvent que de petits problèmes.