Wie werden große Open-Source-Bibliotheken gewartet, während Code weit von „sauberem Code“ entfernt ist?

Ich bin noch unerfahren darin, qualitativ hochwertigen Code zu schreiben. Deshalb lese ich Bücher, die sich mit diesem Thema befassen, wie beispielsweise Clean Code von Robert C. Martin, und überprüfe ständig den Code bekannter Bibliotheken, um meine Fähigkeiten zu verbessern.

Obwohl viele Open Source-Bibliotheken seit Jahren gepflegt werden, was bedeutet, dass es sehr unwahrscheinlich ist, dass sie nicht auf dem richtigen Weg sind, habe ich festgestellt, dass der Code in vielen davon weit entfernt ist von den Prinzipien, die für das Schreiben von sauberem Code gelten - z. B. Methoden, die enthalten Hunderte von Codezeilen.

Meine Frage lautet also: Sind die Prinzipien von sauberem Code zu eingeschränkt, und auf sie können wir in vielen Bibliotheken wie diesen verzichten? Wenn nicht, wie werden große Bibliotheken unter Beibehaltung vieler dieser Prinzipien verwaltet?

Ich freue mich über eine kurze Erläuterung. Ich entschuldige mich, wenn die Frage von einem Neuling albern zu sein scheint.

BEARBEITEN

Überprüfen Sie dieses Beispiel in der Butterknife- Bibliothek - einer der bekanntesten Bibliotheken in der Android-Community.

Gute Antwort hier schon, aber lassen Sie mich ein Wort zu Ihrem Buttermesser- Beispiel sagen : Obwohl ich keine Ahnung habe, was der Code macht, sieht er für mich auf den ersten Blick nicht wirklich unerreichbar aus. Variablen und Methodennamen scheinen absichtlich gewählt zu sein, der Code ist richtig eingerückt und formatiert, er hat einige Kommentare und die langen Methoden zeigen zumindest eine Blockstruktur.

Ja, es folgt in keiner Weise den "Clean Code" -Regeln von Onkel Bob, und einige der Methoden sind sicher zu lang (wahrscheinlich die ganze Klasse). Aber wenn ich mir den Code ansehe, sehe ich immer noch genügend Struktur, so dass sie leicht "aufgeräumt" werden können, indem diese Blöcke in Methoden extrahiert werden (mit einem geringen Risiko, Fehler bei der Verwendung von Refactoring-Tools einzuführen).

Das eigentliche Problem bei einem solchen Code ist, dass ein Block und ein anderer Block hinzugefügt werden und ein anderer Block bis zu einem gewissen Grad funktioniert, manchmal über Jahre. Aber mit jedem Tag wird es schwieriger, den Code ein wenig zu entwickeln, und es dauert ein bisschen länger, ihn zu ändern und zu testen. Und wenn Sie wirklich etwas ändern müssen, das nicht durch "Hinzufügen eines weiteren Blocks" gelöst werden kann, sondern eine Umstrukturierung erfordert, möchten Sie, dass jemand früher mit der Bereinigung des Codes begonnen hat.

Die in "Clean Code" genannten Grundsätze sind nicht immer allgemein vereinbart. Das meiste davon gehört zum gesunden Menschenverstand, aber einige der Meinungen des Autors sind eher umstritten und werden nicht von allen geteilt.

Insbesondere die Bevorzugung kurzer Methoden ist nicht jedermanns Sache. Wenn der Code in einer längeren Methode nicht an anderer Stelle wiederholt wird, erhöht das Extrahieren eines Teils in eine separate Methode (sodass Sie mehrere kürzere Methoden erhalten) die Gesamtkomplexität, da diese Methoden jetzt für andere Methoden sichtbar sind, die sich nicht darum kümmern sollten. Es ist also ein Kompromiss, keine objektive Verbesserung.

Die Ratschläge in diesem Buch richten sich (wie alle Ratschläge) auch an eine bestimmte Art von Software: Unternehmensanwendungen. Andere Arten von Software wie Spiele oder Betriebssysteme unterliegen anderen Einschränkungen als Unternehmenssoftware, sodass andere Muster und Designprinzipien zum Tragen kommen.

Die Sprache ist auch ein Faktor: Clean Code geht von Java oder einer ähnlichen Sprache aus - wenn Sie C oder Lisp verwenden, treffen viele der Ratschläge nicht zu.

Kurz gesagt handelt es sich bei dem Buch um eine Einzelmeinung zu einer bestimmten Klasse von Software. Es wird nicht überall gelten.

Bei Open Source-Projekten reicht die Codequalität von miserabel bis brillant. Schließlich kann jeder seinen Code als Open Source veröffentlichen. Wenn Sie sich jedoch ein ausgereiftes und erfolgreiches Open Source-Projekt mit mehreren Mitwirkenden ansehen, können Sie ziemlich sicher sein, dass sie sich bewusst für einen für sie geeigneten Stil entschieden haben. Wenn dieser Stil einer Meinung oder Richtlinie widerspricht, dann ist (um es klar auszudrücken) die Richtlinie falsch oder irrelevant, da der Arbeitscode die Meinungen übertrumpft.

Zusammenfassung

Wie JacquesB schreibt, sind nicht alle mit Robert C. Martins "Clean Code" einverstanden.

Die Open-Source-Projekte, bei denen Sie festgestellt haben, dass sie die erwarteten Prinzipien "verletzen", haben wahrscheinlich einfach andere Prinzipien.

Meine Perspektive

Ich beaufsichtige zufällig mehrere Codebasen, die sich sehr stark an die Prinzipien von Robert C. Martin halten. Ich behaupte jedoch nicht wirklich, dass sie richtig sind , ich kann nur sagen, dass sie gut für uns funktionieren - und dass "wir" in der Tat eine Kombination von zumindest ist

• Umfang und Architektur unserer Produkte,
• die Zielgruppe / Kundenerwartungen,
• wie lange die Produkte aufbewahrt werden,
• die von uns verwendete Entwicklungsmethodik,
• die Organisationsstruktur unseres Unternehmens und
• Gewohnheiten, Meinungen und Erfahrungen unserer Entwickler.

Im Grunde läuft dies auf Folgendes hinaus: Jedes Team (sei es ein Unternehmen, eine Abteilung oder ein Open Source-Projekt) ist einzigartig. Sie werden unterschiedliche Prioritäten und unterschiedliche Standpunkte haben und natürlich unterschiedliche Kompromisse eingehen. Diese Kompromisse und der daraus resultierende Codestil sind größtenteils Geschmackssache und können nicht als "falsch" oder "richtig" nachgewiesen werden. Die Teams können nur sagen "Wir machen das, weil es für uns funktioniert" oder "Wir sollten das ändern, weil es für uns nicht funktioniert".

Um jedoch große Codebasen über Jahre hinweg erfolgreich verwalten zu können, sollte sich jedes Team auf eine Reihe von Codekonventionen einigen, die seiner Meinung nach für die oben genannten Aspekte geeignet sind. Das kann bedeuten, Praktiken von Robert C. Martin oder einem anderen Autor zu übernehmen oder eigene zu erfinden. es kann bedeuten, sie formell aufzuschreiben oder "anhand eines Beispiels" zu dokumentieren. Aber sie sollten existieren.

Beispiel

Betrachten Sie die Praxis des "Aufteilens von Code von einer langen Methode in mehrere private Methoden".

Robert C. Martin sagt , dass dieser Stil zur Begrenzung des Inhalts jeden Verfahren auf eine Abstraktionsebene ermöglicht - als vereinfachtes Beispiel eine öffentliche Methode wäre wahrscheinlich nur Anrufe zu privaten Methoden bestehen wie verifyInput(...), loadDataFromHardDisk(...), transformDataToJson(...)und schließlich sendJsonToClient(...), und diese Methoden müßten die Implementierungsdetails.

• Manche Leute mögen das, weil die Leser sich einen schnellen Überblick über die wichtigsten Schritte verschaffen und auswählen können, über welche Details sie lesen möchten.
• Manche Leute mögen es nicht, weil man, wenn man alle Details wissen will, in der Klasse herumspringen muss, um dem Ausführungsfluss zu folgen (worauf JacquesB wahrscheinlich Bezug nimmt, wenn er über das Hinzufügen von Komplexität schreibt).

Die Lehre ist: Alle haben Recht, weil sie das Recht haben, eine Meinung zu haben.

Viele Open-Source-Bibliotheken leiden tatsächlich unter objektiv schlechten Codierungspraktiken und werden von einer kleinen Gruppe langfristiger Autoren, die mit der schlechten Lesbarkeit umgehen können, nur schwer gepflegt, da sie mit den Teilen des Codes, die sie am häufigsten pflegen, sehr vertraut sind . Das Überarbeiten von Code, um die Lesbarkeit zu verbessern, ist häufig eine herkulische Aufgabe, da jeder auf der gleichen Seite sein muss, es keinen Spaß macht und sich nicht auszahlt, weil keine neuen Funktionen implementiert werden.

Wie andere gesagt haben, enthält jedes Buch über sauberen Code, in dem überhaupt etwas angegeben ist, notwendigerweise Ratschläge, die nicht allgemein vereinbart sind. Insbesondere kann fast jede Regel mit übermäßigem Eifer befolgt werden, wodurch ein Lesbarkeitsproblem durch ein anderes ersetzt wird.

Persönlich vermeide ich es, benannte Funktionen zu erstellen, wenn ich keinen guten Namen für sie habe. Und ein guter Name muss kurz sein und genau beschreiben, was die Funktion für die Außenwelt bedeutet. Dies ist auch mit dem Versuch verbunden, so wenig Funktionsargumente wie möglich und keine global beschreibbaren Daten zu haben. Der Versuch, eine sehr komplexe Funktion in kleinere Funktionen zu zerlegen, führt häufig zu sehr langen Argumentlisten, wenn die Funktion wirklich komplex war. Das Erstellen und Verwalten von lesbarem Code ist eine Übung im Gleichgewicht zwischen sich widersprechenden Regeln des gesunden Menschenverstands. Das Lesen von Büchern ist gut, aber nur die Erfahrung lehrt Sie, wie Sie falsche Komplexität finden.

Die meisten Open Source-Projekte werden schlecht verwaltet. Es gibt offensichtlich Ausnahmen, aber in der Open-Source-Welt gibt es viel Müll.

Dies ist keine Kritik an allen Projektbesitzern / -leitern, über deren Projekte ich spreche, es ist einfach eine Frage der verwendeten Zeit. Diese Leute haben bessere Dinge mit ihrer Zeit zu tun, wie ihre eigentliche bezahlte Arbeit.

Am Anfang ist der Code die Arbeit einer Person und ist wahrscheinlich klein. Und kleiner Code muss nicht sauber sein. Besser gesagt, der Aufwand für die Bereinigung des Codes ist größer als der Nutzen.

Mit der Zeit ist der Code eher ein Stapel Patches von vielen verschiedenen Leuten. Die Patch-Schreiber fühlen sich nicht im Besitz des Codes, sie möchten nur, dass dieses eine Feature hinzugefügt oder dieser eine Fehler auf einfachste Weise behoben wird.

Der Besitzer hat keine Zeit, die Dinge aufzuräumen, und es kümmert niemanden.

Und der Code wird immer größer. Und hässlich.

Da es immer schwieriger wird, sich im Code zurechtzufinden, beginnen die Leute, Features an der falschen Stelle hinzuzufügen. Und anstatt Fehler zu beheben, fügen sie Problemumgehungen an anderen Stellen im Code hinzu.

An diesem Punkt ist es den Leuten nicht nur egal, sie wagen es nicht mehr aufzuräumen, da sie Angst haben, Dinge zu zerbrechen.

Ich habe Leute gehabt, die Codebasen als "grausame und ungewöhnliche Bestrafung" beschrieben haben.

Meine persönlichen Erfahrungen sind nicht ganz so schlimm, aber ich habe ein paar sehr merkwürdige Dinge gesehen.

Mir scheint, Sie fragen sich, wie das überhaupt funktioniert, wenn niemand tut, was er tun soll. Und wenn es funktioniert, warum sollen wir dann diese Dinge tun ?

Die Antwort, IMHO, ist, dass es "gut genug" funktioniert , auch bekannt als " schlechter ist besser " Philosophie . Trotz der felsigen Geschichte zwischen Open Source und Bill Gates sind beide de facto der gleichen Idee gefolgt, dass sich die meisten Menschen für Features interessieren, nicht für Bugs .

Dies führt uns natürlich auch zu einer " Normalisierung der Abweichung ", die zu Situationen wie Heartbleed führt , in denen, genau wie zur Beantwortung Ihrer Frage, ein gewaltiger, überwucherter Haufen Open-Source-Code namens OpenSSL etwa zehn Jahre lang " ungereinigt " war Dies endete mit einer massiven Sicherheitslücke , von der Tausende von Millionen Menschen betroffen waren .

Die Lösung bestand darin, ein ganz neues System namens LibreSSL zu erfinden , das sauberen Code verwenden sollte , und natürlich wird er von fast niemandem verwendet .

Wie werden große, schlecht codierte Open Source-Projekte verwaltet? Die Antwort liegt in der Frage. Viele von ihnen werden nicht in einem sauberen Zustand gehalten. Sie werden nach dem Zufallsprinzip von Tausenden verschiedener Personen gepatcht , um Anwendungsfälle auf verschiedenen fremden Computern und in Situationen abzudecken , auf die die Entwickler niemals Zugriff haben werden. Der Code funktioniert "gut genug", bis er nicht mehr funktioniert , wenn alle in Panik geraten und beschließen, das Problem mit Geld zu bewerfen .

Warum sollten Sie sich also die Mühe machen, etwas richtig zu machen , wenn es sonst niemand tut ?

Die Antwort ist, du solltest nicht. Entweder Sie oder Sie nicht , und die Welt dreht sich ungeachtet dessen weiter, weil sich die menschliche Natur nicht im Maßstab eines menschlichen Lebens ändert . Persönlich versuche ich nur, sauberen Code zu schreiben, weil mir die Art und Weise gefällt, wie es sich anfühlt, dies zu tun.

Was guten Code ausmacht, hängt vom Kontext ab, und klassische Bücher, die Sie dazu anleiten, sind, wenn auch nicht zu alt, um über Open Source zu diskutieren, zumindest Teil einer Tradition, die den unendlichen Krieg gegen schlechte interne Codebasen führt. Es ist also leicht zu übersehen, dass Bibliotheken ganz andere Ziele verfolgen und dementsprechend geschrieben sind. Berücksichtigen Sie die folgenden Punkte in keiner bestimmten Reihenfolge:

• Wenn ich eine Bibliothek importiere oder aus einer Bibliothek importiere, bin ich wahrscheinlich kein Experte in der internen Struktur, um genau zu wissen, welchen winzigen Bruchteil des Toolkits ich für das benötige, woran ich gerade arbeite, es sei denn, ich kopiere was a Die Stack Exchange-Antwort hat mich dazu aufgefordert. Also fange ich an zu tippen from A import(wenn es in Python ist, sagen wir) und sehe, was auf mich zukommt . Das bedeutet aber, dass die aufgelisteten Anforderungen die logischen Aufgaben widerspiegeln, die ich ausleihen muss, und genau das muss in der Codebasis vorhanden sein. Unzählige Hilfsmethoden, die es kürzer machen, werden mich nur verwirren.
• Bibliotheken sind für den unkundigsten Programmierer da, der versucht, einen Algorithmus zu verwenden, von dem die meisten Leute nur vage gehört haben. Sie benötigen externe Dokumentation, und diese muss den Code genau widerspiegeln, was nicht möglich ist, wenn wir ständig alles überarbeiten, um die Anhänger von Short-Methoden und Do-One-Dingen glücklich zu machen.
• Jede Bibliotheksmethode, die von Menschen ausgeliehen wird, könnte den Code auf der ganzen Welt zerstören und katastrophale Folgen haben, wenn sie gestrichen oder sogar umbenannt wird. Sicher, ich wünschte, Sklearn würde den Tippfehler in Calinski-Harabasz korrigieren , aber das könnte einen weiteren Vorfall mit dem linken Pad verursachen . Meiner Erfahrung nach besteht das größte Problem bei der Entwicklung von Bibliotheken darin, dass sie sich zu sehr bemühen, eine neue "Verbesserung" in Bezug auf die Strukturierung von allem mit gutem Code einzuführen.
• Intern sind Kommentare im besten Fall ein notwendiges Übel, und zwar aus allen möglichen Gründen, die ich nicht nachtragen muss (obwohl diese Punkte etwas übertrieben sind). Ein guter Kommentar sagt, warum der Code funktioniert, nicht wie. Aber Bibliotheken wissen, dass ihre Leser kompetente Programmierer sind, die nicht sagen können, dass sie aus einer Papiertüte heraus eine lineare Algebra schreiben können. Mit anderen Worten, alles muss kommentiert werden: Warum funktioniert es? (OK, das ist eine weitere Übertreibung.) Deshalb sehen Sie eine Signaturzeile, einen 100-zeiligen Kommentarblock und eine Codezeile, die buchstäblich in der Signaturzeile stehen könnte (sofern die Sprache dies zulässt).
• Nehmen wir an, Sie aktualisieren etwas in Github und warten, bis Ihr Code akzeptiert wird. Es muss klar sein, warum Ihre Codeänderung funktioniert. Ich weiß aus Erfahrung, dass das Umgestalten des Campingplatzes im Rahmen eines funktionalen Commits häufig eine Menge Zeilenersparnis, Neuordnung und Umbenennung bedeutet, was die Arbeit Ihrer lohnlosen Prüfer erschwert und andere oben genannte Probleme verursacht.

Ich bin sicher, dass Leute mit mehr Erfahrung als ich andere Punkte erwähnen können.

Es gibt bereits viele gute Antworten - ich möchte die Perspektive eines Open-Source-Betreuers aufzeigen.

Meine Perspektive

Ich betreue viele solcher Projekte mit weniger als großartigem Code. Manchmal kann ich diesen Code aus Kompatibilitätsgründen sogar nicht verbessern, da die Bibliotheken jede Woche millionenfach heruntergeladen werden.

Das macht die Wartung schwieriger - als Kernmitglied von Node.j gibt es Teile des Codes, die ich leider nicht anfassen kann, aber es gibt viel zu tun, unabhängig davon, und die Leute nutzen die Plattform erfolgreich und genießen sie. Das Wichtigste ist, dass es funktioniert.

Auf lesbaren Code

Wenn du sagst:

Ich habe festgestellt, dass der Code in vielen von ihnen weit von den Prinzipien entfernt ist, die für das Schreiben von sauberem Code gelten - z. B. Methoden, die Hunderte von Codezeilen enthalten.

Codezeilen sind kein gutes Maß dafür, wie lesbar sie sind. In der Studie, die ich mit dem Linux-Kernel verknüpfte, wurde analysiert und eine Umfrage unter Programmierern ergab, dass "normaler" Code (Code, den die Leute grundsätzlich erwarten) und konsistenter Code in der Verständlichkeit besser sind als "sauberer" Code. Dies entspricht auch meiner persönlichen Erfahrung.

Einige Open Source-Projekte sind nicht sehr einladend

Linus sagte "berühmt" , dass Linux keinen eingebauten Debugger haben sollte, weil Leute, die Debugger verwenden, nicht gut genug sind, um an Linux zu arbeiten, und er nicht mehr von ihnen anziehen will.

Ich persönlich bin absolut anderer Meinung als er - aber es ist auch etwas, was die Leute tun.

Open-Source-Software bedeutet nicht unbedingt, dass mehrere Autoren beteiligt sind. Wenn eine Software (oder eine Softwareeinheit) von einem einzelnen Autor geschrieben wird, treten häufig lange Funktionen auf.

Dies liegt in der Natur des Entwicklungsprozesses. Eine einfache Methode wird im Laufe der Zeit erweitert, neue Funktionen werden hinzugefügt und ein Fehler behoben.

Lange Methoden beeinträchtigen das Verständnis der Funktionalität für neue Autoren erheblich. Bei einem einzelnen Autor ist dies jedoch selten ein Problem, und das Problem wird häufig übersehen. Eine andere Natur von Open Source ist die Tatsache, dass eine Menge Software nicht aktiv entwickelt wird, weshalb es keine Refactoring-Arbeit gibt, die zum Beispiel komplexe Methoden in mehrere einfache Methoden aufteilen würde.

Sie haben keine Beispiele gezeigt, aber nach meinem Verständnis hängt dies oft auch mit der Entwicklungssprache zusammen. Einige Sprachen erzwingen von Anfang an strenge Regeln für das Flusen und das Testen schwerer Einheiten (oder sogar TDD). Sowohl Flusen als auch Unit-Tests verhindern normalerweise dieses Problem (es ist schwierig, komplexe / lange Methoden für Unit-Tests zu verwenden).

Im Allgemeinen ist es schwieriger, Code sauber zu machen, wenn Software von einem einzelnen Autor entwickelt wird und andere Mitwirkende nur kleine Probleme beheben.