Zwar blieb die ganze Zeit etwas unverändert. Der Code wird nämlich an eine Mailingliste (oder mehrere Listen) gesendet und dort überprüft und diskutiert, bis er als bereit für die Aufnahme in den Linux-Kernel angesehen wird. Trotz der Tatsache, dass dieser Prozess der Arbeit mit Code seit vielen Jahren erfolgreich eingesetzt wird, wurde er ständig kritisiert. Zum Beispiel dies
Ein kürzlich veröffentlichter Artikel von Sara Novotny von Microsoft hat im Internet viel Lärm gemacht. In diesem Artikel heißt es, dass die bei der Entwicklung des Linux-Kernels verwendeten Code-Collaboration-Techniken veraltet sind. Es heißt, wenn die Linux-Entwicklergemeinde junge Fachkräfte für sich gewinnen möchte, wäre es gut, diese Methoden durch etwas Moderneres zu ersetzen. In der Debatte um diese Ideen stießen ihre Verteidiger und Gegner zusammen.
Ich glaube, dass meine Position es mir ermöglicht, einige Ideen zur Entwicklung des Linux-Kernels zu liefern. Seit fast zehn Jahren schreibe ich Code für Linux und andere Projekte, die auf ähnliche Weise organisiert sind. Als ich bei Red Hat war, habe ich zum x86-Kernel-Infrastrukturcode, zum KVM-Hypervisor- und QEMU-Emulatorcode und zum Xen-Hypervisor-Code beigetragen. Ich war auch an der Entwicklung anderer Projekte beteiligt. Ich habe ungefähr 7 Jahre lang nicht viel Linux gemacht, aber nur, weil ich meine Zeit der Arbeit am C ++ Seastar- Framework und an der ScyllaDB- Datenbank gewidmet habe... Beide Projekte wurden mit einer Methodik entwickelt, die der in der Linux-Entwicklung verwendeten sehr ähnlich ist. Ich arbeite jetzt als leitender Ingenieur bei Datadog, einem Unternehmen, in dem Softwareentwicklungsprozesse fast genau das Gegenteil von denen sind, die unter Linux verwendet wurden. Dies kommt der Organisation der Entwicklung in anderen Webunternehmen viel näher.
Auf welcher Seite bin ich? Lassen Sie mich gleich klarstellen, dass mir der Linux-Entwicklungsprozess nicht gefällt. Ich bin mir ziemlich sicher, dass dies nicht nur ein Hindernis für neue Entwickler ist, sondern auch ein Hindernis für eine hohe Produktivität Ihres Codes (und es geht nicht um E-Mail). Dies ist die Quelle negativer Gefühle, die Entwickler erfahren. Und ich werde diesem Modell für kein Projekt folgen, bei dem ich das ausschließliche Recht habe, Entscheidungen darüber zu treffen, wie die Arbeit organisiert wird.
Gleichzeitig scheinen viele Kritiker des Linux-Entwicklungsprozesses der Ansicht zu sein, dass die Tatsache, dass seine Verteidiger so heftig dafür kämpfen, nur eine Folge der Tatsache ist, dass die Linux-Community voll von alten Menschen ist, die Tradition und Würgegriff haben nicht bereit, sich unter irgendeinem Vorwand zu ändern. Dies ist nicht der Fall (obwohl ich sicher bin, dass es solche Leute in der Linux-Community gibt). Der Linux-Kernel-Entwicklungsprozess bietet seinen Benutzern einige einzigartige und wichtige Vorteile. Wenn Sie dieselben Prinzipien auf ein anderes Projekt anwenden, wird ein solches Projekt nur davon profitieren.
Jedes andere Tool außer E-Mail schreibt denjenigen vor, die sie verwenden, ziemlich starre Arbeitsschemata, wodurch Linux eines solchen Vorteils beraubt wird. Und Mailinglisten sind nur ein auffälliger Mechanismus, der die Aufmerksamkeit der Debattierer auf sich zieht. Wir brauchen Tools, die die Eintrittsbarrieren für Linux-Entwickler senken können. Tools, mit denen Fehler im Entwicklungsprozess behoben werden können. Eine, mit der verschiedene Organisationen die Stärken der Linux-Entwicklungsorganisation erkennen können. Tools wie diese können für die gesamte Softwareentwicklungsbranche wirklich einen Unterschied machen.
Es gibt viele dieser Mechanismen, die von großem Nutzen sind. Um unser Gespräch nicht zu verlängern, werde ich mich auf einen von ihnen konzentrieren, den ich für den wichtigsten halte. Ich werde mein Bestes tun, um seine Essenz zu enthüllen und darüber zu sprechen, warum es trotz seiner Stärken bei Entwicklern so viele negative Emotionen hervorruft. Ich werde Ihnen auch sagen, warum es einerseits anderen Projekten zugute kommen kann und andererseits, warum es für Linux unglaublich wichtig ist.
Übertragen Sie Nachrichten und Patches
In der Linux-Kernel-Entwicklungswelt gibt es eine Regel: Code, der in den Kernel aufgenommen werden soll, muss in separate Patches aufgeteilt werden. Jeder von ihnen muss nur ein Problem lösen. Für jeden Patch sollte eine aussagekräftige Festschreibungsnachricht erstellt werden. Es kommt häufig vor, dass solche Nachrichten länger sind als der von ihnen beschriebene Code.
Dies ist ein Paradebeispiel dafür, was in anderen Projekten im Allgemeinen fehlt. Die meisten Commit-Nachrichten, die ich in modernen Projekten auf GitHub gesehen habe, sehen aus wie "Änderungen ab dem 25. August" oder etwas (aber nur geringfügig) besser, wie "Implementierung von Funktion X". Wenn jemand in Zukunft Code wie diesen betrachten muss, wird es für ihn nicht einfach sein, herauszufinden, warum solche Änderungen am Code vorgenommen wurden. Einige der Fehler, die durch diese Commits behoben werden, sind möglicherweise subtil. Wenn Sie nicht wissen, wie genau solche Fehler behoben wurden, können sie problemlos zum Projekt zurückkehren. Während ich die kurze, bedeutungslose Festschreibungsnachricht lese, sind mir möglicherweise die Umstände nicht bekannt, unter denen der Fehler entdeckt wurde.
Hier ist ein kleines Beispiel. Schauen Sie sich das Commit für den Linux-Kernel angemacht von meinem guten Freund Johann Weiner. Ich kann mir leicht vorstellen, wie in einem anderen Projekt eine Nachricht an ein ähnliches Commit wie "Entfernen von Warnungen" ausgesehen hätte. Und wenn ich die Botschaft des hier diskutierten Commits lese, erfahre ich, warum es möglich ist, diese Warnungen ohne Schaden für das Projekt loszuwerden, unter welchen Umständen dies tatsächlich zu nichts Schlimmem führen wird und worüber Die Regeln müssen befolgt werden, wenn eines Tages beschlossen wird, diesen Code zu ändern.
Ich bin sicher, dass es in vielen Organisationen Menschen gibt, die dies tun. Bei der Arbeit am Linux-Kernel muss dies jedoch jeder tun, der an diesem Geschäft beteiligt ist. Daher bin ich ziemlich zuversichtlich, dass ich durch das Lesen der Festschreibungsnachricht alles verstehen werde, was über die entsprechenden Codeänderungen zu verstehen ist. Wenn es sich um einen Fehler handelt, werde ich erfahren, in welchen Systemen er sich manifestiert hat, unter welchen Bedingungen er aufgetreten ist, warum er andere Systeme in keiner Weise beeinflusst hat und worauf zu achten ist, damit dieser Fehler nicht zum Projekt zurückkehrt.
Diese Art von Arbeit ist in jeder Organisation sehr wünschenswert. Dies erleichtert es anderen Personen (und dem Entwickler selbst, wenn er sich nach einer Weile seinem Code zuwendet), die Gründe für Änderungen am Code zu verstehen und zu verstehen, warum der Code so funktioniert, wie er funktioniert. Dies erleichtert neuen Programmierern das Kennenlernen des Projekts. Dies löst das Problem der Rückgabe alter Fehler und verringert die Gefahr, dass ein Code, der scheinbar nicht mit dem betreffenden Code zusammenhängt, etwas darin beschädigt.
In anderen Projekten ist dies „sehr wünschenswert“. Unter Linux ist dies jedoch aus zwei Gründen unbedingt erforderlich:
- Linux . , . Linux, , - . , , , . ( ) , Linux. , Linux.
- (). Linux, . , 2020 , Linux , LTS-. , , - , Linux LTS-, Linux. , 2000- , . , , Red Hat .
Backports sind normalerweise kein Problem für moderne Online-Unternehmen, die nicht mehrere parallele Produktlinien unterhalten müssen. Sie erstellen etwas, geben es an Benutzer weiter und dort endet es. Aber wenn Backports ins Spiel kommen, werden die Dinge komplizierter. Der Entwickler (wahrscheinlich nicht der Autor des Programms) muss möglicherweise entscheiden, wie der Code geringfügig an eine ältere Codebasis angepasst werden soll, die sich geringfügig von der modernen unterscheidet. Und die Lösung, die das Risiko minimiert, kann (und ist oft) darin bestehen, einen Patch zu erstellen, um nur einen bestimmten Teil einer großen Anzahl von Änderungen zu implementieren. Stellen Sie sich ein Commit mit 2.000 Zeilen vor, das 5 Codezeilen enthält, um einen Fehler zu beheben. Stellen Sie sich außerdem vor, dass dieser Fehler nach dem Refactoring der API aufgetreten ist. Was würdest du wählen:Vorbereiten eines Backports basierend auf einer Vielzahl von Änderungen oder basierend auf gut dokumentierten, gut dokumentierten, kaputten Patches? Als Person, die unzählige Backports gemacht hat, weiß ich bereits, wie ich eine solche Frage beantworten würde.
Nun, mit oder ohne Backports müssen Projekte einen hohen Preis für die Vorteile einer solchen Organisation zahlen, wenn es darum geht, Änderungen sorgfältig zu dokumentieren. Jetzt muss sich der Programmierer nicht nur um den Code kümmern, sondern auch darum, wie er neu organisiert und an die Arbeitsregeln des Projekts angepasst werden kann.
Einige dieser Code-Refactorings sind einfach. Nehmen wir an, wir sprechen über die Verwendung des Befehls git add -p und die Auswahl der Änderungen. Etwas komplizierter wird es, wenn ein Programmierer mit zirkulären Abhängigkeiten zwischen einzelnen Codefragmenten konfrontiert ist. Stellen Sie sich eine Funktion vor, die ein Objekt eines Typs zurückgibt, das dem Projekt hinzugefügt wird, nachdem diese Funktion hinzugefügt wurde. Um mit dieser Situation fertig zu werden, müssen Sie Code verwenden, der nicht in das fertige Projekt gelangt, sondern nur die Rolle einer temporären Lösung spielt.
All dies bereitet Programmierern Kopfschmerzen, aber man kann nicht sagen, dass solche Aufgaben völlig unlösbar sind. Angenommen, Sie haben alles, was Sie tun, mit chirurgischer Präzision in Fragmente unterteilt, die einfach und bequem zu verwenden sind. Die eigentlichen Probleme beginnen, nachdem andere Programmierer Ihren Code überprüft haben. Die Überprüfung des Codes in jeder Organisation ist sehr wichtig. Experten lesen den Code eines anderen und schlagen Änderungen vor (oder fordern).
Angenommen, ein Programmierer wurde gebeten, einer bestimmten Methode, die im ersten Patch vorhanden war, aus einer Reihe von Korrekturen einen neuen Parameter hinzuzufügen. Nehmen wir außerdem an, dass diese Methode in allen nachfolgenden Patches verwendet wird.
Dies bedeutet, dass der Programmierer zum ersten Patch zurückkehren und der Methode einen neuen Parameter hinzufügen muss. Danach können die nächsten Patches nicht mehr angewendet werden. Daher muss der Programmierer nicht nur darüber nachdenken, warum dies so ist, sondern auch alle Fehler manuell korrigieren. Wenn alle einzelnen Patches zuvor getestet wurden, sind die Ergebnisse dieser Tests jetzt veraltet und die Patches müssen erneut getestet werden.
Die Neuorganisation der Arbeit ist ein kleines Problem. Die Überarbeitung des bereits Erreichten ist jedoch ein viel ernsthafteres Problem.
Folgendes möchte ich der Linux-Entwickler-Community und denjenigen, die mit dieser Community verwandt sind, mitteilen: All dies ist natürlich durchaus machbar. Aber wenn dies keine Eintrittsbarriere für junge Berufstätige ist, dann weiß ich nicht einmal, was man als "Eintrittsbarriere" bezeichnen kann. Die Notwendigkeit, Ihre Zeit, Mühe, Nerven und Computerressourcen für die Reorganisation, das Umschreiben und die Überarbeitung des bereits Erreichten aufzuwenden, ist eindeutig nicht das, wonach Programmierer streben. In dieser Hinsicht bin ich auf eine Idee gestoßen, die regelmäßig in dieser Form erscheint: "... aber ein guter Programmierer wird damit keine Probleme haben." Es wird auch so geäußert: "Aber es lehrt Programmierer einen bestimmten Denkstil, genau den, den ein guter Programmierer haben sollte." Diese Art von Argumentation erscheint mir unaufrichtig und nutzlos. Tatsächlich:Ich habe gerade alle Stärken dieser Methode aufgelistet, finde aber auch, dass all diese Code-Refactorings umständliche und langwierige Aufgaben sind. Es kann mit der Reinigung einer Wohnung verglichen werden. Nehmen wir an, jemand sagt, dass es sehr gut ist, wenn das Haus sauber gehalten wird (dem stimme ich zu). Dieselbe Person ist durchaus in der Lage, Fußböden zu staubsaugen (ich kann), aber oft nicht. Der Grund dafür ist einfach: Er hat andere, wichtigere Dinge zu tun. Deshalb bin ich zum Beispiel unglaublich glücklich, einen Roomba-Roboterstaubsauger zu haben. Dieses Ding erlaubte mir, die Sauberkeit zu genießen und mich gleichzeitig nicht aufräumen zu müssen. Das bringt mich zu meinem nächsten Gedanken, der sich an Menschen außerhalb der Linux-Welt richtet.dass all diese Code-Refactorings umständliche und mühsame Aufgaben sind. Es kann mit der Reinigung einer Wohnung verglichen werden. Nehmen wir an, jemand sagt, dass es sehr gut ist, wenn das Haus sauber gehalten wird (dem stimme ich zu). Dieselbe Person ist durchaus in der Lage, Böden zu staubsaugen (ich kann), aber oft nicht. Der Grund dafür ist einfach: Er hat andere, wichtigere Dinge zu tun. Deshalb bin ich zum Beispiel unglaublich glücklich, einen Roomba-Roboterstaubsauger zu haben. Dieses Ding erlaubte mir, die Sauberkeit zu genießen und mich gleichzeitig nicht damit zu beschäftigen, die Dinge selbst in Ordnung zu bringen. Das bringt mich zu meinem nächsten Gedanken, der sich an Menschen außerhalb der Linux-Welt richtet.dass all diese Code-Refactorings umständliche und mühsame Aufgaben sind. Es kann mit der Reinigung einer Wohnung verglichen werden. Nehmen wir an, jemand sagt, dass es sehr gut ist, wenn das Haus sauber gehalten wird (dem stimme ich zu). Dieselbe Person ist durchaus in der Lage, Böden zu staubsaugen (ich kann), aber oft nicht. Der Grund dafür ist einfach: Er hat andere, wichtigere Dinge zu tun. Deshalb bin ich zum Beispiel unglaublich glücklich, einen Roomba-Roboterstaubsauger zu haben. Dieses Ding erlaubte mir, die Sauberkeit zu genießen und mich gleichzeitig nicht aufräumen zu müssen. Das bringt mich zu meinem nächsten Gedanken, der sich an Menschen außerhalb der Linux-Welt richtet.Dieselbe Person ist durchaus in der Lage, Fußböden zu staubsaugen (ich kann), aber oft nicht. Der Grund dafür ist einfach: Er hat andere, wichtigere Dinge zu tun. Deshalb bin ich zum Beispiel unglaublich glücklich, einen Roomba-Roboterstaubsauger zu haben. Dieses Ding erlaubte mir, die Sauberkeit zu genießen und mich gleichzeitig nicht aufräumen zu müssen. Das bringt mich zu meinem nächsten Gedanken, der sich an Menschen außerhalb der Linux-Welt richtet.Dieselbe Person ist durchaus in der Lage, Böden zu staubsaugen (ich kann), aber oft nicht. Der Grund dafür ist einfach: Er hat andere, wichtigere Dinge zu tun. Deshalb bin ich zum Beispiel unglaublich glücklich, einen Roomba-Roboterstaubsauger zu haben. Dieses Ding erlaubte mir, die Sauberkeit zu genießen und mich gleichzeitig nicht aufräumen zu müssen. Das bringt mich zu meinem nächsten Gedanken, der sich an Menschen außerhalb der Linux-Welt richtet.richtet sich an Menschen außerhalb der Linux-Welt.richtet sich an Menschen außerhalb der Linux-Welt.
Folgendes möchte ich denjenigen außerhalb der Linux-Community sagen: Der Entwicklungsprozess, der für die Arbeit unter Linux verwendet wird, weist sehr reale Stärken auf. Einige Tools können die unter Linux ausgeführte Aufgabe nicht vollständig bewältigen. GitHub leistet beispielsweise hervorragende Arbeit bei Projekten, bei denen immer neuer Code nach vorhandenem Code hinzugefügt wird. Sie können natürlich den Befehl git push --force verwenden, um einen bestimmten Zweig zwangsweise in das Repository aufzunehmen, aber dann sind die mit dem Commit verbundenen Kommentare tatsächlich "in der Luft hängen", und die Diskussion dieses Commits ist bedeutungslos.
Moderne Entwicklungswerkzeuge vereinfachen viel. Sie ermöglichen es Ihnen, die Ausführung einiger Aktionen auszulösen, wenn bestimmte Bedingungen eintreten, sie unterstützen kontinuierliche Integrations- und Projektbereitstellungsprozesse, benachrichtigen Programmierer über Änderungen im Code und lösen viele andere Aufgaben. Aber sie erschweren sicherlich den Prozess, die Ergebnisse der Arbeit einer Person in kleine Teile zu zerlegen, mit denen einfach und bequem zu arbeiten ist. Die Verwendung von Nur-Text-E-Mails erschwert die Arbeit erheblich, aber diese Arbeitsorganisation beeinträchtigt nicht die Anwendung von Entwicklungsprozessen, die zu einem bestimmten Ziel führen.
Selbst wenn es möglich wäre, objektiv und genau zu bewerten, wie viel das Linux-Ökosystem durch die Aufgabe des bestehenden Entwicklungsprozesses gewonnen und verloren hätte (nichts, was es verloren hätte), würde es kaum etwas ändern. Tatsache ist, dass die aktuelle Situation die menschliche Natur perfekt veranschaulicht, wenn Menschen danach streben, das zu bewahren, was sich zuvor in der Praxis sehr gut gezeigt hat.
Gibt es einen Ausweg aus dieser Situation?
Ich bin der festen Überzeugung, dass es für alle sehr vorteilhaft wäre, wenn wir Tools zur Verfügung hätten, die verschiedenen Organisationen die gleichen Vorteile bieten könnten, die die Linux-Community aus ihrer Entwicklungsmethode zieht. Und wenn solche Tools existieren würden, könnte vielleicht sogar die Linux-Community normale Text-E-Mails durch sie ersetzen.
Ich habe keine Antwort auf die Frage, wie solche Tools aussehen könnten. Aber ich werde mir erlauben, ein Risiko einzugehen und ein wenig darüber nachzudenken:
- Git — . , , , , . GitHub, - git-, «-» Linux, git, . , -, , , , . Git . CSS HTML, — , CSS HTML- . , HTML CSS? , , , .
- , , , , , . , , , ? . , : « create_foo() , create_bar()», : « create_bar() y, ». , , . , , , , GPT-3, , .
- , , , , - , . , , , . , , , , , , , , , .
-, Linux?
