it-swarm.com.de

Wie werden riesige Open-Source-Bibliotheken gepflegt, während Code weit entfernt von "sauberem Code" ist?

Ich bin immer noch unerfahren darin, qualitativ hochwertigen Code zu schreiben, daher lese ich Bücher, die sich mit dem Problem befassen, wie Clean Code von Robert C. Martin, und überprüfe weiterhin 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 von ihnen weit von den Prinzipien entfernt ist, die zum Schreiben von sauberem Code verwendet werden - z. B. Methoden, die enthalten Hunderte von Codezeilen.

Meine Frage lautet also: Sind die Prinzipien von sauberem Code zu eingeschränkt, und wir können in vielen Bibliotheken wie diesen darauf verzichten? Wenn nicht, wie werden riesige Bibliotheken gepflegt, ohne viele dieser Prinzipien zu berücksichtigen?

Ich freue mich über jede kurze Klarstellung. Ich entschuldige mich, wenn die Frage von einem Neuling albern erscheint.

[~ # ~] edit [~ # ~]

Überprüfen Sie diese Beispiel in Butterknife Bibliothek - eine der bekanntesten Bibliotheken in Android Community).

81
Islam Salah

Gute Antwort hier schon, aber lassen Sie mich ein Wort über Ihr Buttermesser Beispiel sagen: Obwohl ich keine Ahnung habe, was der Code tut, sieht er auf den ersten Blick für mich nicht wirklich unhaltbar aus. Variablen und Methodennamen scheinen absichtlich ausgewählt zu sein, der Code ist richtig eingerückt und formatiert, er enthält 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 gesamte Klasse). Wenn ich mir den Code anschaue, sehe ich immer noch genug Struktur, damit sie leicht "bereinigt" werden können, indem diese Blöcke selbst in Methoden extrahiert werden (mit einem geringen Risiko, Fehler bei der Verwendung von Refactoring-Tools einzuführen).

Das eigentliche Problem mit einem solchen Code besteht darin, dass ein Block und ein weiterer 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 weiterzuentwickeln, und es dauert etwas 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, aber eine Umstrukturierung erfordert, dann wünschen Sie sich, jemand hätte früher damit begonnen, den Code zu bereinigen.

83
Doc Brown

Die in "Clean Code" genannten Grundsätze sind nicht immer allgemein vereinbart. Das meiste davon ist gesunder Menschenverstand, aber einige der Meinungen des Autors sind eher kontrovers und werden nicht von allen geteilt.

Insbesondere die Präferenz für kurze Methoden ist nicht jedermanns Sache. Wenn der Code in einer längeren Methode an keiner anderen Stelle wiederholt wird, erhöht das Extrahieren eines Teils davon 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 um sie 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 unterschiedliche Muster und Designprinzipien im Spiel sind.

Die Sprache ist auch ein Faktor: Clean Code setzt Java oder eine ähnliche Sprache voraus - wenn Sie C oder LISP verwenden, gelten viele der Ratschläge nicht.

Kurz gesagt, das Buch ist eine Einzelperson Meinungen 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 Stil entschieden haben, der für sie funktioniert. Wenn dieser Stil einer Meinung oder Richtlinie widerspricht, dann ist es (um es klar auszudrücken) die Richtlinie, die falsch oder irrelevant ist, da der Arbeitscode die Meinungen übertrifft.

158
JacquesB

Zusammenfassung

Wie JacquesB schreibt, stimmen nicht alle dem "Clean Code" von Robert C. Martin zu.

Die Open-Source-Projekte, bei denen Sie festgestellt haben, dass sie gegen die von Ihnen erwarteten Prinzipien "verstoßen", haben wahrscheinlich einfach andere Prinzipien.

Meine Perspektive

Ich beaufsichtige zufällig mehrere Codebasen, die den Prinzipien von Robert C. Martin sehr entsprechen. Ich behaupte jedoch nicht wirklich, dass sie richtig sind , ich kann nur sagen, dass sie für uns gut funktionieren - und dass "wir" tatsächlich eine Kombination von mindestens ist

  • umfang und Architektur unserer Produkte,
  • die Zielmarkt-/Kundenerwartungen,
  • wie lange die Produkte aufbewahrt werden,
  • die von uns verwendete Entwicklungsmethode,
  • die Organisationsstruktur unseres Unternehmens und
  • gewohnheiten, Meinungen und Erfahrungen unserer Entwickler.

Grundsätzlich läuft dies darauf hinaus: Jedes Team (sei es ein Unternehmen, eine Abteilung oder ein Open Source-Projekt) ist einzigartig. Sie werden unterschiedliche Prioritäten und Standpunkte haben und natürlich unterschiedliche Kompromisse eingehen. Diese Kompromisse und der daraus resultierende Codestil sind weitgehend 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".

Ich glaube jedoch, dass jedes Team, um große Codebasen über Jahre hinweg erfolgreich verwalten zu können, eine Reihe von Codekonventionen vereinbaren sollte, die seiner Meinung nach für die oben genannten Aspekte geeignet sind. Das kann bedeuten, Praktiken von Robert C. Martin, von 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, "Code von einer langen Methode in mehrere private Methoden aufzuteilen".

Robert C. Martin sagt, dass dieser Stil es erlaubt, den Inhalt jeder Methode auf eine Abstraktionsebene zu beschränken - als vereinfachtes Beispiel würde eine öffentliche Methode wahrscheinlich nur aus Aufrufen privater Methoden wie verifyInput(...), loadDataFromHardDisk(...), transformDataToJson(...) und schließlich sendJsonToClient(...), und diese Methoden würden die Implementierungsdetails enthalten.

  • Einige Leute mögen dies, weil die Leser einen schnellen Überblick über die allgemeinen Schritte erhalten und auswählen können, über welche Details sie lesen möchten.
  • Einige Leute mögen es nicht, weil man, wenn man alle Details wissen will, in der Klasse herumspringen muss, um dem Ausführungsfluss zu folgen (darauf bezieht sich JacquesB wahrscheinlich, 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.

34
Jens Bannmann

Viele Open-Source-Bibliotheken leiden tatsächlich unter objektiv schlechten Codierungspraktiken und werden nur schwer von einer kleinen Gruppe von Langzeitmitarbeitern gepflegt, die mit der schlechten Lesbarkeit umgehen können, weil sie mit den Teilen von sehr vertraut sind der Code, den sie am häufigsten pflegen. Das Refactoring von Code zur Verbesserung der Lesbarkeit im Nachhinein ist oft eine Herkulesanstrengung, da jeder auf derselben Seite sein muss, es keinen Spaß macht und sich nicht auszahlt, da keine neuen Funktionen implementiert sind.

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 dafür habe. Und ein guter Name muss kurz sein und genau beschreiben, was die Funktion mit der Außenwelt tut. Dies hängt auch damit zusammen, dass versucht wird, 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 gegenseitig widersprechenden Regeln des gesunden Menschenverstandes. Das Lesen von Büchern ist gut, aber nur die Erfahrung zeigt Ihnen, wie Sie falsche Komplexität finden. Hier werden die tatsächlichen Lesbarkeitsgewinne erzielt.

13
Kafein

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

Dies ist keine Kritik an allen Projektbesitzern/Managern, über deren Projekte ich spreche, es ist einfach eine Frage der verwendeten Zeit. Diese Leute haben bessere Dinge mit ihrer Zeit zu tun, wie ihren tatsächlich bezahlten Job.

Am Anfang ist der Code die Arbeit einer Person und wahrscheinlich klein. Und kleiner Code muss nicht sauber sein. Oder besser gesagt, der Aufwand, der erforderlich ist, um den Code sauber zu machen, ist größer als der Nutzen.

Mit der Zeit ist der Code eher ein Stapel von Patches vieler verschiedener Leute. Die Patch-Autoren haben kein Eigentum an dem Code, sie möchten nur, dass diese eine Funktion hinzugefügt oder dieser eine Fehler auf einfachste Weise behoben wird.

Der Besitzer hat keine Zeit zum Aufräumen und niemand anderes kümmert sich darum.

Und der Code wird groß. Und hässlich.

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

An diesem Punkt ist es nicht nur so, dass es die Leute nicht interessiert, sie sind nicht länger wagen aufräumen, da sie Angst haben, Dinge zu zerbrechen.

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

Meine persönlichen Erfahrungen sind nicht ganz so schlecht, aber ich habe ein paar sehr seltsame Dinge gesehen.

7
Stig Hemmer

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

Die Antwort, IMHO, ist, dass es funktioniert "gut genug" , auch bekannt als " schlechterist besser " Philosophie . Im Grunde genommen haben beide trotz der felsigen Geschichte zwischen Open Source und Bill Gates de facto die gleiche Idee übernommen, dass die meisten Leute interessieren sich für Features, nicht für Bugs .

Dies führt uns natürlich auch zu " Normalisierung der Abweichung ", was zu Situationen wie Heartbleed führt, in denen genau wie zur Beantwortung Ihrer Frage ein massiver überwachsenSpaghetti-Stapel von Open-Source-Code namens OpenSSL ging " ngereinigt " für so etwas wie zehn Jahre , Abschluss mit einem massivSicherheitslücke Beeinflussung Tausende von Millionen von Menschen .

Die Lösung bestand darin, ein ganz neues System namens LibreSSL zu erfinden, das sauberen Code verwenden und natürlich fastniemandbenutzt es .

Wie werden also riesige, schlecht codierte Open Source-Projekte gepflegt? Die Antwort liegt in der Frage. Viele von ihnen werden nicht in einem sauberen Zustand gehalten. Sie sind zufällig gepatcht von Tausende von verschiedenen Personen zu behandeln Anwendungsfälle auf verschiedenen seltsamen Maschinen und Situationen, in denen die Entwickler niemals Zugriff haben) zum Testen. Der Code funktioniert "gut genug" bis nicht , wenn alle in Panik geraten und sich entscheiden Geld auf das Problem werfen .

Warum sollten Sie sich also die Mühe machen, etwas ' den richtigen Weg ' zu tun, wenn es sonst niemand ist?

Die Antwort ist, dass Sie nicht sollten. Sie entweder tun oder Sie tun nicht und die Welt dreht sich weiter unabhängig davon, weil die menschliche Natur ändert sich nicht auf der Skala von a - MenschLebenszeit . Persönlich versuche ich nur, sauberen Code zu schreiben, weil mir das Gefühl gefällt, es zu tun.

3
don bright

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

Meine Perspektive

Ich bin ein Betreuer vieler solcher Projekte mit weniger als großartigem Code. Manchmal werde ich aufgrund von Kompatibilitätsproblemen sogar daran gehindert, solchen Code zu verbessern, da die Bibliotheken jede Woche millionenfach heruntergeladen werden.

Dies erschwert die Wartung - 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 lesbarem Code

Wenn du sagst:

Ich fand, dass der Code in vielen von ihnen weit von den Prinzipien entfernt ist, die zum Schreiben von sauberem Code angesprochen wurden - z. B. Methoden, die Hunderte von Codezeilen enthalten.

Codezeilen sind kein gutes Maß wie lesbar es ist. In der Studie, die ich mit dem Linux-Kernel verknüpft habe, wurde analysiert, und eine Umfrage unter Programmierern ergab, dass "normaler" Code (Code, den die Leute grundsätzlich erwarten) und konsistenter Code verständlicher sind als "sauberer" Code. Dies stimmt auch mit meiner persönlichen Erfahrung überein.

Einige Open Source-Projekte sind nicht besonders einladend

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

Persönlich bin ich mit seiner Haltung dort absolut nicht einverstanden - aber es ist auch etwas, was die Leute tun.

2

Was guten Code ausmacht, hängt vom Kontext ab, und klassische Bücher, die Sie dazu führen, sind, wenn auch nicht zu alt, um 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 völlig unterschiedliche Ziele verfolgen und entsprechend geschrieben sind. Berücksichtigen Sie die folgenden Punkte in keiner bestimmten Reihenfolge:

  • Wenn ich eine Bibliothek oder aus einer Bibliothek importiere, bin ich wahrscheinlich nicht genug Experte in ihrer internen Struktur, um genau zu wissen, welchen winzigen Teil ihres Toolkits ich für alles benötige, woran ich arbeite, es sei denn, ich kopiere was a Die Antwort von Stack Exchange sagte mir, ich solle es tun. Also fange ich an, from A import (wenn es in Python ist, sagen wir) und sehen, was kommt. Aber das bedeutet, dass das, was ich aufgelistet sehe, die logischen Aufgaben widerspiegeln muss, die ich ausleihen muss, und das muss in der Codebasis sein. Unzählige Hilfsmethoden, die es kürzer machen, werden mich nur verwirren.
  • Bibliotheken sind für den unerfahrensten Programmierer da, der versucht, einen Algorithmus zu verwenden, von dem die meisten Menschen 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 umgestalten, um Anhänger mit kurzen Methoden und einer Sache glücklich zu machen.
  • Jede Bibliotheksmethode, die von Menschen ausgeliehen wird, kann Code auf der ganzen Welt mit katastrophalen Folgen brechen, wenn er entfernt oder sogar umbenannt wird. Sicher, ich wünschte, sklearn würde den Tippfehler in Calinski-Harabasz korrigieren , aber das könnte einen weiteren Vorfall verursachen linker Block . Meiner Erfahrung nach besteht das größte Problem bei der Bibliotheksentwicklung darin, dass sie sich zu sehr bemühen, eine neue "Verbesserung" des guten Codes für die Strukturierung aller Elemente zu übernehmen.
  • Inhouse sind Kommentare im besten Fall ein notwendiges Übel, aus allen möglichen Gründen, die ich nicht erbrechen 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 beispielsweise keine lineare Algebra aus einer Papiertüte 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 Kommentarblock mit 100 Zeilen und eine Codezeile, die buchstäblich in die Signaturzeile hätte eingefügt werden können (wenn die Sprache dies zulässt).
  • Angenommen, Sie aktualisieren etwas auf Github und warten ab, ob Ihr Code akzeptiert wird. Es muss klar sein, warum Ihre Codeänderung funktioniert. Ich weiß aus Erfahrung, dass Refactoring, um den Campingplatz im Rahmen eines funktionalen Commits sauberer zu machen, oft viel Zeileneinsparung, Neuanordnung und Umbenennung bedeutet, was die Arbeit Ihres lohnlosen Gutachters erschwert und andere oben genannte Probleme verursacht.

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

2
J.G.

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

Dies ergibt sich aus der Art des Entwicklungsprozesses. Eine einfache Methode wird im Laufe der Zeit erweitert, neue Funktionen werden hinzugefügt und 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 Art von Open Source ist die Tatsache, dass viele Softwareprodukte nicht aktiv entwickelt werden. Daher gibt es keine Refactoring-Arbeiten, die beispielsweise komplexe Methoden in mehrere einfache Methoden aufteilen würden.

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 Flusenregeln und schwere Unit-Tests (oder sogar TDD). Sowohl Flusen- als auch Komponententests verhindern normalerweise dieses Problem (es ist schwierig, komplexe/lange Methoden zu testen).

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

1
Sulthan