Certes, pendant tout ce temps, quelque chose est resté inchangé. À savoir, le code est envoyé à une liste de diffusion (ou à plusieurs listes), et là, il est examiné et discuté jusqu'à ce qu'il soit considéré comme prêt à être inclus dans le noyau Linux. Mais malgré le fait que ce processus de travail avec du code ait été utilisé avec succès pendant de nombreuses années, il a été constamment critiqué. Par exemple, ce
Un article récent de Sara Novotny de Microsoft a fait beaucoup de bruit sur Internet. Cet article disait que les techniques de collaboration de code utilisées dans le développement du noyau Linux sont obsolètes. Il dit que si la communauté des développeurs Linux veut attirer de jeunes professionnels dans ses rangs, ces méthodes seraient bonnes à remplacer par quelque chose de plus moderne. Dans le débat autour de ces idées, leurs défenseurs et opposants se sont affrontés.
Je crois que ma position me permet de fournir quelques idées concernant le développement du noyau Linux. Depuis près de dix ans maintenant, j'écris du code pour Linux et d'autres projets organisés de manière similaire. Quand j'étais chez Red Hat, j'ai contribué au code d'infrastructure du noyau x86, à l'hyperviseur KVM et au code de l'émulateur QEMU, et au code de l'hyperviseur Xen. J'ai également participé au développement d'autres projets. Je n'ai pas fait beaucoup de Linux pendant environ 7 ans, mais uniquement parce que j'ai consacré mon temps à travailler sur C ++ - le framework Seastar et sur la base de données ScyllaDB... Ces deux projets ont été développés en utilisant une méthodologie très similaire à celle utilisée dans le développement Linux. Je travaille maintenant en tant qu'ingénieur principal chez Datadog, une entreprise où les processus de développement logiciel sont presque exactement le contraire de ceux utilisés sous Linux. C'est beaucoup plus proche de la façon dont le développement est organisé dans d'autres sociétés Web.
Alors de quel côté suis-je? Permettez-moi de préciser tout de suite que je n'aime pas le processus de développement Linux. Je suis presque sûr que ce n'est pas seulement un obstacle pour les nouveaux développeurs, mais aussi un obstacle à une productivité élevée sur votre code (et il ne s'agit pas de courrier électronique). C'est la source des sentiments négatifs ressentis par les développeurs. Et je ne vais pas suivre ce modèle pour aucun projet dans lequel j'ai le droit exclusif de prendre des décisions sur la façon dont le travail sera organisé.
Mais en même temps, il semble que de nombreux critiques du processus de développement Linux croient que le fait que ses défenseurs se battent si férocement pour lui n'est qu'une conséquence du fait que la communauté Linux est pleine de personnes âgées qui ont une mainmise sur la tradition et pas disposé à changer sous aucun prétexte. Ce n'est pas le cas (même si je suis sûr qu'il y a de telles personnes dans la communauté Linux). Le processus de développement du noyau Linux apporte des avantages uniques et importants à ses utilisateurs. Si vous appliquez les mêmes principes à tout autre projet, un tel projet n'en bénéficiera que.
Tout autre outil, en plus du courrier électronique, impose à ceux qui les utilisent des schémas de travail plutôt rigides, privant Linux d'un tel avantage. Et les listes de diffusion ne sont qu'un mécanisme notable qui attire l'attention des débatteurs. Nous avons besoin d'outils capables de réduire les barrières à l'entrée pour les développeurs Linux. Des outils capables de corriger les failles du processus de développement. Celui qui permet à différentes organisations de reconnaître les points forts de l'organisation de développement Linux. Des outils comme ceux-ci peuvent vraiment faire une différence pour l'ensemble de l'industrie du développement logiciel.
Il existe un grand nombre de ces mécanismes qui sont très utiles. Afin de ne pas prolonger notre conversation, je me concentrerai sur l'un d'entre eux, que je considère comme le plus important. Je ferai de mon mieux pour révéler son essence et expliquer pourquoi, malgré ses atouts, il provoque tant d'émotions négatives chez les développeurs. Je vais également vous dire pourquoi, d'une part, il peut bénéficier à d'autres projets, et d'autre part, pourquoi il est extrêmement important pour Linux.
Valider les messages et les correctifs
Dans le monde du développement du noyau Linux, il existe une règle: le code destiné à être inclus dans le noyau doit être divisé en correctifs séparés. Chacun d'eux doit résoudre un et un seul problème. Un message de validation significatif doit être préparé pour chaque patch. Il arrive souvent que ces messages soient plus longs que le code qu'ils décrivent.
C'est un excellent exemple de ce qui manque généralement dans d'autres projets. La plupart des messages de commit que j'ai vus dans les projets modernes sur GitHub ressemblent à quelque chose comme "changements au 25 août", ou légèrement (mais seulement légèrement) mieux, comme "implémentation de la fonction X". Si quelqu'un a besoin de regarder du code comme celui-ci à l'avenir, il ne lui sera pas facile de comprendre pourquoi de telles modifications ont été apportées au code. Certains des bogues corrigés par ces commits peuvent être subtils. Si vous ne savez pas exactement comment ces erreurs ont été corrigées, elles peuvent facilement revenir au projet. En lisant le court message de validation sans signification, je ne suis peut-être pas au courant des circonstances dans lesquelles le bogue a été découvert.
Voici un petit exemple. Jetez un œil au commit sur le noyau Linuxfait par mon bon ami Johann Weiner. Il m’est facile d’imaginer comment, dans un autre projet, un message adressé à un commit similaire aurait ressemblé à «supprimer les avertissements». Et quand je lis le message du commit discuté ici, j'apprends pourquoi il est possible, sans nuire au projet, de se débarrasser de ces avertissements, sur les circonstances dans lesquelles cela, en effet, ne mènera à rien de mauvais, et sur quoi les règles doivent être respectées si un jour il est décidé de changer ce code.
Je suis sûr qu'il y a des gens dans de nombreuses organisations qui font cela. Mais lorsque vous travaillez sur le noyau Linux, tous ceux qui sont impliqués dans cette entreprise doivent le faire. Par conséquent, je suis assez confiant qu'en lisant le message de validation, je comprendrai tout ce qu'il y a à comprendre sur les changements de code correspondants. Si nous parlons d'une erreur, alors j'apprendrai dans quels systèmes elle s'est manifestée, dans quelles conditions elle s'est produite, pourquoi elle n'a aucunement affecté les autres systèmes et à quoi il faut faire attention pour que cette erreur ne revienne pas au projet.
Ce type de travail est hautement souhaitable dans toute organisation. Cela permet aux autres personnes (et au développeur lui-même, quand il se tourne vers son code après un certain temps) de comprendre plus facilement les raisons pour lesquelles des modifications sont apportées au code, de comprendre pourquoi le code fonctionne comme il le fait. Cela permet aux nouveaux programmeurs de mieux connaître le projet. Cela résout le problème du retour d'anciennes erreurs, réduit le risque que du code, apparemment sans rapport avec celui en question, puisse y casser quelque chose.
Dans d'autres projets, c'est «hautement souhaitable». Mais sous Linux, c'est absolument nécessaire pour deux raisons:
- Linux . , . Linux, , - . , , , . ( ) , Linux. , Linux.
- (). Linux, . , 2020 , Linux , LTS-. , , - , Linux LTS-, Linux. , 2000- , . , , Red Hat .
Les backports ne sont généralement pas un problème pour les entreprises en ligne modernes qui n'ont pas besoin de maintenir plusieurs lignes de produits parallèles. Ils créent quelque chose, le transmettent aux utilisateurs, et c'est là que ça se termine. Mais lorsque les backports entrent en jeu, les choses se compliquent. Le développeur (probablement pas l'auteur du programme) peut avoir besoin de décider comment adapter légèrement le code à une base de code plus ancienne qui est légèrement différente de la base moderne. Et la solution qui minimise les risques peut souvent être (et est souvent) celle qui consiste à créer un correctif uniquement pour implémenter une certaine partie d'un grand ensemble de changements. Imaginez un commit de 2000 lignes contenant 5 lignes de code pour corriger un bogue. Imaginez également que cette erreur se soit produite après la refactorisation de l'API. Que choisiriez-vous:préparer un backport basé sur un vaste ensemble de changements, ou basé sur des correctifs bien documentés, bien documentés et décomposés? En tant que personne qui a fait d'innombrables backports, je sais déjà comment je répondrais à une telle question.
Eh bien, avec ou sans backports, les projets doivent payer un prix élevé pour les avantages d'être organisés de cette manière lorsque l'accent est mis sur la documentation minutieuse des changements. Maintenant, le programmeur doit s'occuper non seulement du code, mais aussi de la façon de le réorganiser et de le mettre en conformité avec les règles de travail sur le projet.
Certaines de ces refactorisations de code sont simples. Disons que nous parlons d'utiliser la commande git add -p et de choisir ce qui va entrer dans un lot de modifications. Les choses se compliquent un peu plus si le programmeur est confronté à des dépendances circulaires entre des fragments de code individuels. Imaginez une fonction qui renvoie un objet d'un type qui sera ajouté au projet après y avoir ajouté cette fonction. Afin de faire face à cette situation, vous devrez utiliser du code qui, par conséquent, n'entrera pas dans le projet fini, mais ne jouera que le rôle d'une solution temporaire.
Tout cela ajoute un casse-tête aux programmeurs, mais on ne peut pas dire que de telles tâches sont totalement insolubles. Supposons que vous ayez, avec une précision chirurgicale, divisé tout ce que vous faites en fragments faciles et pratiques à utiliser. Les vrais problèmes commencent après que d'autres programmeurs ont commencé à regarder votre code. La révision du code dans toute organisation est très importante. Les experts lisent le code de quelqu'un d'autre et suggèrent (ou exigent) des modifications.
Supposons qu'un programmeur ait été invité à ajouter un nouveau paramètre à une certaine méthode présente dans le premier patch à partir d'un ensemble de correctifs. Et supposons également que cette méthode soit utilisée dans tous les correctifs suivants.
Cela signifie que le programmeur devra revenir au premier patch et ajouter un nouveau paramètre à la méthode. Après cela, les patchs suivants ne pourront plus être appliqués. Par conséquent, le programmeur devra non seulement se demander pourquoi il en est ainsi, mais devra également corriger manuellement toutes les erreurs. Si tous les correctifs individuels ont déjà été testés, les résultats de ces tests sont désormais obsolètes et les correctifs devront être testés à nouveau.
La réorganisation du travail est un petit problème. Mais retravailler ce qui a déjà été fait est un problème beaucoup plus sérieux.
Voici ce que je voudrais transmettre à la communauté des développeurs Linux et à ceux qui sont liés à cette communauté: tout cela, bien sûr, est tout à fait faisable. Mais si ce n'est pas une barrière à l'entrée pour les jeunes professionnels, alors je ne sais même pas ce qu'on peut appeler une «barrière à l'entrée». La nécessité de consacrer votre temps, vos efforts, vos nerfs et vos ressources informatiques à réorganiser, réécrire, retravailler ce qui a déjà été fait n'est clairement pas ce à quoi aspirent les programmeurs. À cet égard, je suis tombé sur une idée qui apparaît périodiquement sous cette forme: "... mais un bon programmeur n'aura pas de problèmes avec cela." Il est également exprimé comme ceci: "mais il enseigne aux programmeurs un certain style de pensée, exactement celui qu'un bon programmeur devrait avoir." Ce genre de raisonnement me paraît peu sincère et inutile. En effet:Je viens d'énumérer toutes les forces de cette méthode, mais je trouve aussi que toutes ces refactorisations de code sont des tâches lourdes et fastidieuses. Cela peut être comparé au nettoyage d'un appartement. Disons que quelqu'un dit que c'est très bien quand la maison est maintenue propre (je suis d'accord avec ça). La même personne est tout à fait capable de passer l'aspirateur sur les planchers (je le peux), mais souvent il ne le fait pas. La raison en est simple: il a d'autres choses plus importantes à faire. Par exemple, c'est pourquoi je suis extrêmement heureux d'avoir un robot aspirateur Roomba. Cette chose m'a permis de profiter de la propreté et en même temps de ne pas avoir à me ranger. Ce qui m'amène à ma prochaine réflexion, dirigée vers des personnes en dehors du monde Linux.que toutes ces refactorisations de code sont des tâches lourdes et fastidieuses. Cela peut être comparé au nettoyage d'un appartement. Disons que quelqu'un dit que c'est très bien quand la maison est maintenue propre (je suis d'accord avec ça). La même personne est tout à fait capable de passer l'aspirateur sur les planchers (je peux), mais souvent il ne le fait pas. La raison en est simple: il a d'autres choses plus importantes à faire. Par exemple, c'est pourquoi je suis extrêmement heureux d'avoir un robot aspirateur Roomba. Cette chose m'a permis de profiter de la propreté et en même temps de ne pas avoir à me ranger. Ce qui m'amène à ma prochaine réflexion, dirigée vers des personnes en dehors du monde Linux.que toutes ces refactorisations de code sont des tâches lourdes et fastidieuses. Cela peut être comparé au nettoyage d'un appartement. Disons que quelqu'un dit que c'est très bien quand la maison est maintenue propre (je suis d'accord avec ça). La même personne est tout à fait capable de passer l'aspirateur sur les planchers (je peux), mais souvent il ne le fait pas. La raison en est simple: il a d'autres choses plus importantes à faire. Par exemple, c'est pourquoi je suis extrêmement heureux d'avoir un robot aspirateur Roomba. Cette chose m'a permis de profiter de la propreté et en même temps de ne pas m'engager à mettre les choses en ordre moi-même. Ce qui m'amène à ma prochaine réflexion, dirigée vers des personnes en dehors du monde Linux.La même personne est tout à fait capable de passer l'aspirateur sur les planchers (je le peux), mais souvent il ne le fait pas. La raison en est simple: il a d'autres choses plus importantes à faire. Par exemple, c'est pourquoi je suis extrêmement heureux d'avoir un robot aspirateur Roomba. Cette chose m'a permis de profiter de la propreté et en même temps de ne pas avoir à me ranger. Ce qui m'amène à ma prochaine réflexion, dirigée vers des personnes en dehors du monde Linux.La même personne est tout à fait capable de passer l'aspirateur sur les planchers (je peux), mais souvent il ne le fait pas. La raison en est simple: il a d'autres choses plus importantes à faire. Par exemple, c'est pourquoi je suis extrêmement heureux d'avoir un robot aspirateur Roomba. Cette chose m'a permis de profiter de la propreté et en même temps de ne pas avoir à me ranger. Ce qui m'amène à ma prochaine réflexion, dirigée vers des personnes en dehors du monde Linux.destiné aux personnes en dehors du monde Linux.destiné aux personnes en dehors du monde Linux.
Voici ce que je voudrais dire à ceux qui ne font pas partie de la communauté Linux: Il y a des atouts très réels dans le processus de développement utilisé pour travailler sous Linux. Certains outils ne sont pas capables de faire face pleinement à la tâche qui fonctionne sous Linux. GitHub, par exemple, fait un excellent travail sur les projets où un nouveau code est toujours ajouté après le code existant. Vous pouvez, bien sûr, utiliser la commande git push --force, en incluant de force une certaine branche dans le référentiel, mais alors les commentaires attachés au commit seront, en fait, "suspendus dans l'air", et la discussion sur ce commit n'aura aucun sens.
Les outils de développement modernes simplifient beaucoup. Ils vous permettent de déclencher l'exécution de certaines actions lorsque certaines conditions se présentent, ils prennent en charge les processus d'intégration continue et de déploiement de projet, informent les programmeurs des changements dans le code et résolvent de nombreuses autres tâches. Mais ils compliquent certainement le processus de décomposition des résultats du travail de quelqu'un en petits morceaux avec lesquels il est facile et pratique de travailler. L'utilisation d'e-mails en texte brut complique beaucoup, mais cette organisation du travail, il faut le noter, n'interfère pas avec l'application de processus de développement menant à un objectif précis.
Même s'il était possible d'évaluer objectivement et avec précision combien l'écosystème Linux aurait gagné et perdu (rien qu'il n'aurait perdu) en abandonnant le processus de développement existant, cela ne changerait pratiquement rien. Le fait est que la situation actuelle illustre parfaitement la nature humaine, lorsque les gens s'efforcent de préserver ce qui s'est très bien montré auparavant dans la pratique.
Y a-t-il un moyen de sortir de cette situation?
Je crois sincèrement que si nous avions à notre disposition des outils qui pourraient fournir à différentes organisations les mêmes avantages que la communauté Linux tire de sa méthodologie de développement, ce serait très bénéfique pour tout le monde. Et si de tels outils existaient, alors peut-être que même la communauté Linux pourrait les remplacer par des e-mails texte normaux.
Je n'ai pas de réponse à la question de savoir à quoi pourraient ressembler ces outils. Mais j'oserai tenter ma chance et y réfléchir un peu:
- Git — . , , , , . GitHub, - git-, «-» Linux, git, . , -, , , , . Git . CSS HTML, — , CSS HTML- . , HTML CSS? , , , .
- , , , , , . , , , ? . , : « create_foo() , create_bar()», : « create_bar() y, ». , , . , , , , GPT-3, , .
- , , , , - , . , , , . , , , , , , , , , .
-, Linux?
