Torvalds Zitat über einen guten Programmierer [geschlossen]

238

Aus Versehen bin ich auf folgendes Zitat von Linus Torvalds gestoßen:

"Schlechte Programmierer sorgen sich um den Code. Gute Programmierer sorgen sich um Datenstrukturen und ihre Beziehungen."

Ich habe in den letzten Tagen darüber nachgedacht und bin immer noch verwirrt (was wahrscheinlich kein gutes Zeichen ist), daher wollte ich Folgendes diskutieren:

  • Welche Interpretation ist möglich / sinnvoll?
  • Was kann daraus gelernt werden?
beyeran
quelle
18
Ich denke, diese Frage hat wahrscheinlich mehrere Antworten, die gleichermaßen gültig sind. Aber es ist trotzdem eine gute Frage. Ich liebe dieses Zitat. Es drückt aus, warum ich Programmierer nicht verstehe, die sich Gedanken über das Wechseln der Sprache machen. In einem Programm kommt es selten auf die Sprache an, auf die Datenstrukturen und deren Beziehung.
Ryan Kinal
5
Wenn Sie sich die Zeit nehmen, um die Datenstrukturen "elegant" zu gestalten, muss der Code möglicherweise nicht kompliziert sein, um mit diesen Datenstrukturen umzugehen. Ich bin wahrscheinlich zu dumm, um die Bedeutung von Torvalds Zitat wirklich zu kennen. :}
Programmierer
3
@RyanKinal Aber natürlich spielt die Sprache eine Rolle , denn sie erleichtert es erheblich, mit bestimmten Datenstrukturen umzugehen und darüber nachzudenken. Denken Sie beispielsweise an alle Sprachen, die auf LISt-Analyse spezialisiert sind, oder an Sprachen, die systemeigene Unterstützung für Datenstrukturen haben, die in andere Sprachen gehackt werden müssen (es fallen Ihnen Mengen und spärliche Arrays ein).
Kojiro
83
Torvalds ist übrigens nicht allein: "Zeigen Sie mir Ihr Flussdiagramm und verbergen Sie Ihre Tabellen, und ich werde weiterhin verwirrt sein. Zeigen Sie mir Ihre Tabellen, und ich werde Ihr Flussdiagramm normalerweise nicht brauchen. Es wird offensichtlich sein. " - Fred Brooks, der mythische Mann-Monat. "Zeigen Sie mir Ihren Code und verbergen Sie Ihre Datenstrukturen, und ich werde weiterhin verwirrt sein. Zeigen Sie mir Ihre Datenstrukturen, und ich werde Ihren Code normalerweise nicht benötigen; es wird offensichtlich sein." und "Intelligente Datenstrukturen und dummer Code funktionieren viel besser als umgekehrt." - Eric S. Raymond, die Kathedrale und der Basar.
Jörg W Mittag
4
Dies erklärt, warum der Linux-Kernel ein Chaos ist :)
l1x

Antworten:

326

Es könnte hilfreich sein, darüber nachzudenken, was Torvalds kurz zuvor gesagt hat:

Git hat tatsächlich ein einfaches Design mit stabilen und einigermaßen gut dokumentierten Datenstrukturen. Tatsächlich bin ich ein großer Befürworter des Entwerfens Ihres Codes um die Daten herum, anstatt umgekehrt, und ich denke, dies ist einer der Gründe, warum git ziemlich erfolgreich war Zwischen einem schlechten und einem guten Programmierer besteht die Frage, ob er seinen Code oder seine Datenstrukturen für wichtiger hält.

Was er sagt ist, dass gute Datenstrukturen den Code sehr einfach zu entwerfen und zu warten machen, wohingegen der beste Code schlechte Datenstrukturen nicht ausgleichen kann.

Wenn Sie sich über das Git-Beispiel wundern, ändern viele Versionskontrollsysteme ihr Datenformat relativ regelmäßig, um neue Funktionen zu unterstützen. Wenn Sie ein Upgrade durchführen, um die neue Funktion zu erhalten, müssen Sie häufig ein Tool ausführen, um auch die Datenbank zu konvertieren.

Als DVCS zum ersten Mal populär wurde, konnten viele Leute nicht herausfinden, was mit dem verteilten Modell passiert, das Zusammenführungen so viel sauberer macht als eine zentralisierte Versionskontrolle. Die Antwort ist absolut nichts, außer verteilte Datenstrukturen hatte zu viel besser sein, um eine Hoffnung auf Arbeit überhaupt zu haben. Ich glaube, dass zentralisierte Zusammenführungsalgorithmen inzwischen aufgeholt haben, aber es hat ziemlich lange gedauert, da ihre alten Datenstrukturen die Art von Algorithmen einschränkten, die sie verwenden konnten, und die neuen Datenstrukturen eine Menge vorhandenen Codes zerstört haben.

Im Gegensatz dazu haben sich die zugrunde liegenden Datenstrukturen trotz einer Explosion von Features in Git kaum verändert. Sorgen Sie sich zuerst um die Datenstrukturen, und Ihr Code wird natürlich sauberer.

Karl Bielefeldt
quelle
25
Der beste Code kann schlechte Datenstrukturen nicht
ausgleichen.
5
Er spricht vom Standpunkt der Programmierer, die Änderungen am Git selbst vornehmen. Die Sichtweise des Endbenutzers ist völlig orthogonal zu dieser Diskussion, abgesehen von einfach zu wartendem Code, der für weniger Fehler und schnellere Funktionserweiterungen sorgt.
Karl Bielefeldt
2
@ James: Er sagt, dass die Software besser ist (daher einfacher zu benutzen und von mehr Leuten benutzt wird), weil die Datenstrukturen besser sind. Natürlich müssen Sie nicht über die Datenstrukturen der von Ihnen verwendeten Software Bescheid wissen , aber Sie kümmern sich indirekt um sie, auch wenn Sie es nicht bemerken, denn die Datenstrukturen sind der Antrieb für die Dinge, die Sie realisieren Wert darauf legen.
Ruakh
1
+1. Diese Antwort setzt einen Zusammenhang mit einer Aussage, die andernfalls als etwas ganz anderes aufgefasst werden könnte. Jeder, der eine 5000-Zeilen-Monstrosität einer Datei gelesen hat, weiß genau, was ich meine.
Riwalk
20
"Kümmern Sie sich zuerst um die Datenstrukturen, und Ihr Code wird natürlich sauberer.": Der römische Staatsmann Cato ( de.wikipedia.org/wiki/Cato_the_Elder ) pflegte zu sagen "Rem tene, verba sequentur" = "Haben Sie das Argument klar in In deinem Geist werden die Worte natürlich folgen ". Gleiches gilt für die Programmierung: Verstehen Sie zuerst die Datenstrukturen und das Design, der eigentliche Code folgt von selbst.
Giorgio
60

Algorithmen + Datenstrukturen = Programme

Code ist nur der Weg, um die Algorithmen und Datenstrukturen auszudrücken .

zxcdw
quelle
Letzte Ausgabe ethoberon.ethz.ch/WirthPubl/AD.pdf
Donnerstag,
Dies gilt für die prozedurale Programmierung. in OOP ist ein bisschen anders.
m3th0dman
3
Es ist nicht grundsätzlich jeder anders. Sie haben Daten und führen eine Reihe von Vorgängen aus. Mitgliedsvariablen und Methoden. Genau das Gleiche. Die gesamte Essenz des Rechnens seit den 50er Jahren basiert auf der sehr einfachen Regel, dass Programme aus Algorithmen bestehen, die Datenstrukturen modifizieren, und gilt auch 60 Jahre später. Sie können Programme auch als Funktionen betrachten . Sie nehmen Eingaben auf, mit denen sie arbeiten, um eine Ausgabe zu erzeugen . Genau wie mathematische Funktionen.
zxcdw
31

Dieses Zitat ist einer der Regeln in "Die Kunst der Unix-Programmierung", die Torvalds 'Stärke als Schöpfer von Linux ausmacht, sehr vertraut. Das Buch finden Sie hier online

Aus dem Buch ist das folgende Zitat, das erklärt, was Torvalds sagt.

Repräsentationsregel: Falten Sie Wissen in Daten, damit die Programmlogik dumm und robust sein kann.

Selbst die einfachste prozedurale Logik ist für den Menschen schwer zu verifizieren, aber recht komplexe Datenstrukturen sind recht einfach zu modellieren und zu begründen. Um dies zu sehen, vergleichen Sie die Aussagekraft und die Erklärungskraft eines Diagramms eines Zeigerbaums mit fünfzig Knoten mit einem Flussdiagramm eines Programms mit fünfzig Zeilen. Oder vergleichen Sie einen Array-Initialisierer, der eine Konvertierungstabelle mit einer entsprechenden switch-Anweisung ausdrückt. Der Unterschied in Transparenz und Klarheit ist dramatisch. Siehe Rob Pikes Regel 5.

Daten sind leichter zu erfassen als Programmlogik. Wenn Sie also die Wahl zwischen Komplexität in Datenstrukturen und Komplexität im Code sehen, wählen Sie die erstere. Mehr: Bei der Entwicklung eines Designs sollten Sie aktiv nach Möglichkeiten suchen, um die Komplexität von Code zu Daten zu verlagern.

Die Unix-Community hat diese Erkenntnis nicht geschaffen, aber eine Menge Unix-Code zeigt seinen Einfluss. Insbesondere die Fähigkeit der Sprache C, Zeiger zu manipulieren, hat die Verwendung dynamisch modifizierter Referenzstrukturen auf allen Codierungsebenen ab dem Kernel gefördert. Einfache Zeigerjagden in solchen Strukturen erfüllen häufig Aufgaben, die Implementierungen in anderen Sprachen stattdessen in aufwändigeren Prozeduren ausführen müssten.

Jay Atkinson
quelle
Daran habe ich mich auch erinnert!
Jesvin Jose
1
OTOH, schauen Sie sich eine StackOverflow-Frage an int**. Das sollte Sie davon überzeugen, dass Daten tatsächlich NICHT offensichtlich sind. es wird nur so, indem den Daten eine Bedeutung beigemessen wird. Und diese Bedeutung ist im Code.
MSalters
29

Code ist einfach, es ist die Logik hinter dem Code, die komplex ist.

Wenn Sie sich Gedanken über Code machen, bedeutet dies, dass Sie diese Grundlagen noch nicht kennen und wahrscheinlich auf dem Komplex verloren gehen (dh Datenstrukturen und ihre Beziehungen).

Idioten
quelle
17
Heh, ich frage mich, ob die nächste Generation von Programmierern fragen wird: "Morons hat einmal gesagt Code is easy, it's the logic behind the code that is complex, was hat er gemeint?"
Yannis
36
@YannisRizos Das wird besonders verwirrend sein, wenn die Leute sich nicht sicher sind, ob es von Leuten gesagt wurde , die Idioten waren, oder von einer einzelnen Person namens Idioten.
KChaloux
14

Um die Antwort von Morons ein wenig zu erweitern, besteht die Idee darin, dass das Verstehen der Einzelheiten des Codes (Syntax und in geringerem Maße Struktur / Layout) so einfach ist, dass wir Tools erstellen, die das können. Compiler können alles verstehen, was über Code bekannt sein muss, um daraus ein funktionierendes Programm / eine funktionierende Bibliothek zu machen. Ein Compiler kann die Probleme der Programmierer jedoch nicht lösen .

Sie könnten das Argument noch einen Schritt weiter führen und sagen: "Es gibt jedoch Programme, die Code generieren." Der generierte Code basiert jedoch auf einer Art Eingabe, die fast immer von Hand erstellt wird.

Welchen Weg Sie auch einschlagen, um zum Code zu gelangen: Sei es über eine Konfiguration oder eine andere Eingabe, die dann den Code über ein Tool erzeugt, oder wenn Sie ihn von Grund auf neu schreiben, ist es nicht der Code, der zählt. Es ist das kritische Denken aller Teile, die benötigt werden, um zu dem Code zu gelangen, der wichtig ist. In Linus 'Welt sind das hauptsächlich Datenstrukturen und -beziehungen, in anderen Bereichen können es jedoch auch andere Teile sein. Aber in diesem Zusammenhang sagt Linus nur: "Es ist mir egal, ob Sie Code schreiben können, es ist mir wichtig, dass Sie die Dinge verstehen, die die Probleme lösen, mit denen ich zu tun habe."

Daniel DiPaolo
quelle
Jeder Programmierer verwendet Programme, die Code generieren. Sie werden oft als "Compiler" bezeichnet, manchmal in Kombination mit "Linkern". Sie nehmen eine (relativ) für Menschen lesbare und beschreibbare Eingabe, die normalerweise (aber nicht immer) in einer Art Textformat vorliegt, und wandeln sie in Daten um, die der Computer als Anweisungen verstehen und ausführen kann.
ein CVn
13

Linus bedeutet das:

Zeigen Sie mir Ihre Flussdiagramme [Code] und verbergen Sie Ihre Tabellen [Schema], und ich werde weiterhin mystifiziert sein; Zeigen Sie mir Ihre Tabellen [Schema] und ich brauche normalerweise keine Flussdiagramme [Code]: Sie werden offensichtlich sein.

- Fred Brooks, "Der Monat des mythischen Mannes", Kapitel 9.

Daniel Shawcross Wilkerson
quelle
12

Ich denke, er sagt, dass das allgemeine High-Level-Design (Datenstrukturen und ihre Beziehungen) viel wichtiger ist als die Implementierungsdetails (Code). Ich denke, er schätzt Programmierer, die ein System entwerfen können, über diejenigen, die sich nur auf Details eines Systems konzentrieren können.

Beides ist wichtig, aber ich stimme zu, dass es im Allgemeinen viel besser ist, den Überblick zu behalten und Probleme mit den Details zu haben, als umgekehrt. Dies hängt eng mit dem zusammen, was ich zum Ausdruck bringen wollte , um große Funktionen in kleine aufzuteilen .

GlenPeterson
quelle
+1: Ich stimme dir zu. Ein weiterer Aspekt ist, dass sich Programmierer oft mehr Gedanken darüber machen, welche coolen Sprachfunktionen sie verwenden werden, anstatt sich auf ihre Datenstrukturen und Algorithmen zu konzentrieren und wie sie auf einfache und klare Weise niedergeschrieben werden.
Giorgio
Ich stimme auch zu. Tatsache ist, dass es einfach ist, einzelne Codeteile zu ändern, Datenstrukturen oder Schnittstellen zwischen Codeteilen jedoch schwieriger zu ändern (da diese Art von Änderungen viele Dinge und nicht nur eine betreffen kann).
Brendan
5

Ich kann dem nicht ganz zustimmen, weil Sie sich darum kümmern müssen. Und eines der Dinge, die ich an der Programmierung liebe, sind die Wechsel zwischen verschiedenen Abstraktionsebenen und Größen, die sich schnell vom Nachdenken über Nanosekunden zum Nachdenken über Monate und wieder zurück bewegen.

Die höheren Dinge sind jedoch wichtiger.

Wenn ich einen Fehler in einigen Problembereichen habe, der zu falschem Verhalten führt, ist es wahrscheinlich nicht allzu schwer, ihn zu beheben. Wenn es zu einer Unterperformance führt, spielt es wahrscheinlich keine Rolle.

Wenn ich einen Fehler bei der Auswahl der Datenstruktur in einem Subsystem habe, der zu falschem Verhalten führt, ist das Problem viel größer und schwerer zu beheben. Wenn es dazu führt, dass es unterdurchschnittlich abschneidet, kann es sehr ernst sein oder, wenn es erträglich ist, ist es immer noch merklich weniger gut als ein konkurrierender Ansatz.

Wenn ich einen Fehler in der Beziehung zwischen den wichtigsten Datenstrukturen in einer Anwendung habe, der zu falschem Verhalten führt, liegt eine massive Umgestaltung vor mir. Wenn es zu einer Underperformance führt, könnte es so schlimm sein, dass es fast besser wäre, wenn es sich falsch verhält.

Und genau das macht es schwierig, diese Probleme auf niedrigerer Ebene zu finden (das Beheben von Fehlern auf niedriger Ebene ist normalerweise einfach, es ist schwierig, sie zu finden).

Das Low-Level-Zeug ist wichtig, und seine verbleibende Bedeutung wird oft ernsthaft unterschätzt, aber es ist blass im Vergleich zu den großen Sachen.

Jon Hanna
quelle
2

Jemand, der Code kennt, sieht die "Bäume". Aber jemand, der Datenstrukturen versteht, sieht den "Wald". Daher konzentriert sich ein guter Programmierer mehr auf Datenstrukturen als auf Code.

Tom Au
quelle
2
Aber entweder den Wald oder die Bäume unter Ausschluss des anderen zu betrachten, kann sich nachteilig auswirken, daher denke ich nicht, dass diese Analogie passt.
Kojiro
1
@kojiro: In dem Ausdruck kann man den Wald vor lauter Bäumen nicht sehen , wird angenommen, dass jemand, der den Wald sehen kann, auch die Bäume sieht (siehe en.wiktionary.org/wiki/see_the_forest_for_the_trees ). Daher halte ich es hier für eine gute Analogie.
Treb
2

Es ist wichtig zu wissen, wie die Daten fließen werden. Um den Fluss zu kennen, müssen Sie gute Datenstrukturen entwerfen.

Wenn Sie zwanzig Jahre zurückblicken, war dies eines der großen Verkaufsargumente für den objektorientierten Ansatz mit SmallTalk, C ++ oder Java. Das große Kriterium - zumindest mit C ++, weil ich das zuerst gelernt habe - war das Entwerfen der Klasse und der Methoden, und dann würde alles andere zusammenpassen.

Zweifellos sprach Linus weiter, aber schlecht gestaltete Datenstrukturen erfordern oft eine zusätzliche Überarbeitung des Codes, was auch zu anderen Problemen führen kann.

Oktopusgrabbus
quelle
2

Was kann daraus gelernt werden?

Wenn ich darf, meine Erfahrungen in den letzten Wochen. Die vorangegangenen Diskussionen verdeutlichten die Antwort auf meine Frage: "Was habe ich gelernt?"

Ich habe Code umgeschrieben und über die Ergebnisse nachgedacht, die ich immer wieder gesehen und gesagt habe: "Struktur, Struktur ...", deshalb gab es so dramatische Unterschiede. Jetzt sehe ich, dass es die Datenstruktur war , die den Unterschied ausmachte. Und ich meine alles .

  • Beim Testen meiner ursprünglichen Lieferung teilte mir der Geschäftsanalyst mit, dass dies nicht funktioniert habe. Wir sagten "30 Tage hinzufügen", meinten aber "einen Monat hinzufügen" (der Tag im resultierenden Datum ändert sich nicht). Addiere diskrete Jahre, Monate, Tage; Zum Beispiel nicht 540 Tage für 18 Monate.

  • Das Problem: In der Datenstruktur wurde eine einzelne Ganzzahl durch eine Klasse mit mehreren Ganzzahlen ersetzt. Die Änderung der Konstruktion war auf eine Methode beschränkt. Ändern Sie die tatsächlichen Datumsberechnungsanweisungen - alle 2 von ihnen.

Die Auszahlung

  • Die neue Implementierung hatte mehr Funktionalität, aber der Algorithmuscode war kürzer und deutlich einfacher.

Beim Korrigieren des Verhaltens / der Ergebnisse des Codes:

  • Ich habe die Datenstruktur geändert, nicht den Algorithmus.
  • Nirgendwo im Code wurde die Steuerlogik berührt.
  • Es wurde keine API geändert.
  • Die Datenstruktur-Factory-Klasse hat sich überhaupt nicht geändert.
Radarbob
quelle
1

Ich stelle mir gerne ein sehr kluges Team von Bibliothekaren in einer wunderschön gestalteten Bibliothek mit einer Million zufälliger und brillanter Bücher vor, es wäre eine ziemliche Torheit.

Tudor Watson
quelle
1

Kann nicht mehr mit Linus übereinstimmen. Die Konzentration auf die Daten hilft dabei, eine einfache und flexible Lösung für ein bestimmtes Problem zu finden. Git selbst ist ein erprobendes Beispiel - mit so vielen Funktionen, die in den Jahren der Entwicklung unterstützt wurden, bleibt die Kerndatenstruktur weitgehend unverändert. Das ist Magie! --2c

mc2
quelle
0

Ich habe gesehen, das sind zahlreiche Bereiche.

Denken Sie an Unternehmensanalysen ... Angenommen, Sie analysieren, wie Sie Marketing in einem Konsumgüterunternehmen wie Colgate am besten unterstützen können. Wenn Sie mit ausgefallenen Fenstern oder der neuesten Technologie beginnen, helfen Sie dem Unternehmen nicht annähernd so viel, als würden Sie zuerst die Datenanforderungen des Unternehmens durchdenken und sich dann später um die Präsentation kümmern. Das Datenmodell überdauert die Präsentationssoftware.

Betrachten Sie eine Webseite. Es ist viel besser, zuerst über das nachzudenken, was Sie anzeigen möchten (HTML), und sich danach über Stil (CSS) und Skripterstellung (wählen Sie Ihr Werkzeug aus) Gedanken zu machen.

Das heißt nicht, dass Codierung auch nicht wichtig ist. Sie benötigen Programmierkenntnisse, um am Ende das zu bekommen, was Sie brauchen. Es ist, dass Daten die Grundlage sind. Ein schlechtes Datenmodell spiegelt entweder ein zu komplexes oder ein ungedachtes Geschäftsmodell wider.

MathAttack
quelle
0

Ich schreibe viel häufiger neue Funktionen und aktualisiere vorhandene, als dass ich meinem Datenbankschema neue Spalten oder Tabellen hinzufügen muss. Dies gilt wahrscheinlich für alle gut konzipierten Systeme. Wenn Sie Ihr Schema jedes Mal ändern müssen, wenn Sie Ihren Code ändern müssen, ist dies ein klares Zeichen, dass Sie ein sehr schlechter Entwickler sind.

Qualität des Codeindikators = [Codeänderungen] / [Datenbankschemaänderungen]

"Zeigen Sie mir Ihre Flussdiagramme und verbergen Sie Ihre Tabellen, und ich werde weiterhin verwirrt sein. Zeigen Sie mir Ihre Tabellen, und ich werde Ihre Flussdiagramme normalerweise nicht benötigen; sie werden offensichtlich sein." (Fred Brooks)

Joel Jacobson
quelle
-2

Es scheint, dass diese Idee verschiedene Interpretationen in den verschiedenen Arten der Programmierung hat. Dies gilt sowohl für die Systementwicklung als auch für die Unternehmensentwicklung. Beispielsweise könnte man argumentieren, dass die starke Verschiebung des Fokus in Richtung der Domäne im domänengetriebenen Design dem Fokus auf Datenstrukturen und Beziehungen sehr ähnlich ist.

eulerfx
quelle
-4

Hier ist meine Interpretation davon: Sie verwenden Code, um Datenstrukturen zu erstellen, daher sollte der Fokus auf Letzterem liegen. Es ist wie beim Bau einer Brücke - Sie sollten sich zum Ziel setzen, eine solide Struktur zu entwerfen, anstatt eine, die ansprechend aussieht. Es ist einfach so, dass gut geschriebene Datenstrukturen und Brücken aufgrund ihres effizienten Designs gleichermaßen gut aussehen.

Bob
quelle