it-swarm.com.de

Wie gehen Sie mit dem Verständnis der Abstraktion im Code um?

Wenn ich mir eine neue Codebasis anschaue, gehe ich gerne von einem Bottom-up-Ansatz aus.
Wo ich eine Datei verstehe und dann zur nächsten Abstraktion übergehe.
Aber oft vergesse ich, was die untergeordnete Abstraktion tut.

Ich bin also an einem Punkt angelangt, an dem ich mich in einer fast endlosen Schleife befinde, zu den Dateien zurückzukehren, die ich zuvor vollständig verstanden habe, und dann zu versuchen, sie neu zu lernen. während ich versuche, zahlreiche andere Abstraktionen zu jonglieren, die in meinem Kopf miteinander verbunden sind.

Gibt es eine bessere Strategie, um mit dieser Situation umzugehen?

Sollte ich nur die Details der unteren Ebene vergessen und sie als gegeben betrachten? Aber selbst dann ist oft ein vorheriges Verständnis der Abstraktion auf niedrigerer Ebene erforderlich, um zu verstehen, was die aktuelle Abstraktion tut.

15
John DeBord

Konkretes Programmieren ist der Impuls, Details zu sich zu ziehen, damit Sie sie alle an einem Ort festnageln können. Wir fangen alle so an und es ist schwer loszulassen.

Abstraktes Programmieren bedeutet definitiv, "die Details der unteren Ebene zu vergessen". Manchmal sogar Details auf hoher Ebene. Sie schieben Details weg und lassen etwas anderes damit umgehen. Das hinterhältige ist, dass Sie dies die ganze Zeit getan haben. Verstehst du wirklich, was alles zwischen print "Hello world" und es erscheint auf Ihrem Bildschirm?

Die Nummer eins, die Sie verlangen müssen, wenn Sie Schwierigkeiten haben, diese Details loszulassen, sind gute Namen. Ein guter Name sorgt dafür, dass Sie nicht überrascht sind, wenn Sie hineinschauen. Deshalb warst du nicht überrascht, dass print etwas auf deinen Bildschirm gebracht hat und es dir egal war, wie. foo "Hello world" wäre eine andere Geschichte gewesen.

Außerdem sollten die Abstraktionsebenen konsistent sein. Wenn Sie sich auf einer Ebene befinden, auf der es um die Berechnung von pi geht, sollten Sie sich auch keine Gedanken darüber machen, wie pi angezeigt wird. Dieses Detail ist in eine Abstraktion gelangt, in die es nicht gehört.

Niedrigere, höhere oder seitwärts gerichtete Details, bei denen es nicht um das geht, woran ich an diesem einen Ort denke, können entweder ganz verschwinden oder sich zumindest hinter einem guten Namen verstecken.

Wenn Sie also wirklich Probleme haben, von Datei zu Datei zu springen, kann ich davon ausgehen, dass Sie jemand mit schlechten Namen oder undichten Abstraktionen überhäuft hat.

Ich behebe das, indem ich mit meinen Fingern lese. Sobald ich anständige Tests für dieses Durcheinander habe, ziehe ich die Verantwortlichkeiten auseinander, gebe ihnen klare Namen, die Überraschungen vermeiden, und zeige sie jemand anderem, um sicherzustellen, dass ich nicht in einer Fantasiewelt lebe.

Anscheinend bin ich nicht allein, wenn es darum geht, so zu arbeiten:

Immer wenn ich an unbekanntem Code arbeite, beginne ich mit dem Extrahieren von Methoden. Wenn ich das mache, suche ich nach Codestücken, die ich benennen kann - dann extrahiere ich. Selbst wenn ich die Methoden extrahiere, die ich später extrahiert habe, habe ich zumindest die Möglichkeit, Details vorübergehend auszublenden, damit ich die Gesamtstruktur sehen kann.

Michael Feathers - Orange Code

31
candied_orange

Unten gibt es einige Aktualisierungen, wie sich das für mich jedes Quartal des Jahres oder so entwickelt hat. Ich denke, sie sind wertvoll.

Gute Benennung. Oder, wenn es sich um den Code eines anderen handelt, versuchen Sie, gute Namen/Verantwortlichkeiten basierend auf sogar schlechten Namen in den Klassen/Funktionen dieses Systems zuzuweisen, damit dies möglich ist Sinn in meinem Kopf. Sobald dies der Fall ist, werden die Implementierungen auf niedriger Ebene viel einfacher zu merken.

Das ist alles was ich habe. Es gibt viele Puristen auf dieser Seite, die bei Gott schwören werden, welche Muster oder Objekte welcher Art auch immer, aber eine gute Benennung wird Sie weit bringen. Ich habe es mehr als gut gemacht, indem ich minimal dokumentierten/gut benannten/gut entkoppelten Code erstellt habe, und es hat mich nie wieder gebissen, selbst wenn mein Code an vielen Orten von vielen Leuten verwendet wurde, aber der Eine Sache, die ich richtig gemacht habe, war, viel Zeit mit guten Namen, guten Kommentaren und Schaltplänen zu verschwenden, die den Fluss meines Codes erklärten. Eine Implementierung auf niedriger Ebene ist erforderlich, um zu verstehen, ob Sie meinen Code tiefgreifend erweitern möchten. Gut geschriebener Code kann auf vernünftige Weise erweitert werden. Es ist also in Ordnung, dass jemand oder Sie die Implementierungen auf niedriger Ebene nicht verstehen/sich nicht daran erinnern.

Wenn Sie an einer Kontroverse interessiert sind, von der sowohl die Leute in meinem ursprünglichen Bereich als auch ich wissen, dass sie die Wahrheit sind, aber wenn Sie sich anhören, was hier geschrieben steht, werden Sie lernen, dieser Antwort sowohl zuzustimmen als auch nicht zuzustimmen Lesen Sie weiter:


Aber hier gibt es noch ein anderes Problem - Puristen. Sie werden gut formulierte Antworten und Ideologien hören, die vernünftig und völlig logisch sind. Tatsächlich ist daran nichts auszusetzen. Aber Sie müssen ihnen nicht folgen, tatsächlich könnten sie zu Ihrem Nachteil spielen.

Meine Freunde haben mit großen Systemen gearbeitet und sie lachen nur über Leute, die sich ein bisschen zu sehr für Konventionen und Muster interessieren, und aus gutem Grund würde ich es auch tun - ich kann meine Argumentation dafür aus meinem Hauptbereich der Datenanalyse finden. da ich kein so erfahrener Entwickler bin: Die meisten Dinge, die Sie für wichtig halten, spielen keine Rolle, und in diesem Sinne besteht eine starke Korrelation zu Ihrem Ego. Oft hat ein Individuum aufgrund seines Ego das Wissen erhalten, dass es höchstwahrscheinlich aufgrund seiner Vorurteile missverstanden wurde, die jetzt von einer Autorität verstärkt werden, von der er glaubt, dass sie gerade "das Gleiche gesagt hat, was ich getan habe". Dies ist eine sehr bekannte Falle, in die Sie niemals geraten sollten. Das bedeutet nicht, dass er es nicht richtig oder zum Wohle der Allgemeinheit einsetzt, aber oft versprechen diese Leute, dass alles, was sie sagen, der goldene Preis ist.

Also was kannst du tun?

Erklären Sie Ihren Code einem Kollegen und fragen Sie ihn, ob er aus allgemeiner Sicht sinnvoll ist.

Das ist alles was zählt. Natürlich hat jeder, der den Code eines anderen liest, immer ein Alt-Tab-Fest, um die Implementierung bestimmter Dinge zu sehen, aber das spielt keine Rolle, wenn jeder, der Ihren Code liest, das allgemeine Verständnis Ihres Systems hat und versteht, "warum Dinge passieren" "(wieder, ohne unbedingt zu wissen, vollständig" wie sie passieren "), dann bist du golden.

Ich sage nicht, mach weiter und schreibe Mistcode, der nicht performant ist oder nichts respektiert, aber ich sage:

1) Es ist okay zu vergessen. Mit der Zeit werden Sie besser darin, Code zu lesen, mit dem Sie arbeiten. Wenn der Code, den Sie lesen, erfordert, dass Sie die Implementierungen auf niedriger Ebene auf einem guten Niveau kennen, dann ist der Code schlecht geschrieben und spielt in das hinein, was ich zuvor gesagt habe: Versteht Sie ein Mitarbeiter?

2) Die Welt ist voller sehr intelligenter Menschen, die nicht sehr klug sind. Sie sind auch oftmals sehr emotional und neigen dazu, die Vorurteile von außen zu verstärken. Sie sind sehr gut darin, was sie tun, aber was sie als Akteure der Informationsverbreitung vergessen, ist: Ideen/Informationen, auch wenn sie von "Logik" unterstützt werden, haben den Kontext desjenigen, der sie sendet, was entscheidend ist, um zu verstehen, ob dies der Fall ist oder nicht Informationen sind auch für Sie nützlich. Was für Sie Sinn macht, könnte für andere Sinn machen, und sie würden es lieben, aber Informationen sollten nicht als absolut angesehen werden, und man sollte wiederum den Kontext, aus dem sie stammen, berücksichtigen oder zumindest versuchen, ihn herauszufinden, und ihn überprüfen eigener Kontext, um zu sehen, ob es übereinstimmt. Es ist wirklich dasselbe wie bei Milliardären, die uns diese "Erkenntnisse geben, um weiterzukommen" - es ist sicherlich leicht, die Dinge zu sagen, die sie sagen, aber schwieriger umzusetzen, natürlich ist dies ein dummes Beispiel, aber Sie haben die Idee.

Kurz gesagt: Schreiben Sie verständlichen Code und stellen Sie fest, dass es immer noch umstritten ist, wenn wir so viele Muster/Klassen und Raffinerien benötigen, wie manche sagen. Es gibt sehr kluge Leute auf beiden Seiten des Arguments und es sollte nur die Idee bekräftigen, alles, was für Ihr Team funktioniert, auf vernünftige Weise zu tun - bleiben Sie nicht bei kleinen Details, die keine Rolle spielen, Sie werden es herausfinden Denken Sie später daran, dass Sie in einer äußerst wettbewerbsintensiven Welt leben, in der das Timing das Wichtigste ist:

Timing bei Start-up-Erfolg.

Weisen Sie Ihre Zeit und Ressourcen sinnvoll und gierig zu.


Hier ist eine Bearbeitung, 6 Monate später:

Es war eine verrückte Reise. Ich hätte nie gedacht, dass Sie durch Trennung/gute Benennung und Dokumentation grundsätzlich alles in Ihre Codebasis ein- und ausstecken können. Ich musste viel Code neu schreiben, um ihn mit den neuen Änderungen auf den neuesten Stand zu bringen, und ich habe in 2-3 Tagen einen guten Teil davon gemacht. Ich kann mit Sicherheit sagen, dass ich nicht überall SOLID wegen mangelndem Wissen oder Best Practices gefolgt bin und ich kann sagen, dass sie in meiner technischen Schuld sind, aber nicht viel. Separat, Name gut & Dokument, es wird Ihnen ermöglichen, Code in kürzester Zeit zu ändern, wenn Sie schließlich erkennen, wie dumm Sie waren.

Verstehen Sie mich nicht falsch: Wenn Sie Ihren Code eng gekoppelt schreiben, werden Sie große Schmerzen haben, unabhängig davon, ob Sie SOLID hassen oder nicht. Selbst das Verstehen und Anwenden auf einer Basisebene ermöglicht eine großartige Entkopplung, was ehrlich gesagt der Fall ist Das einzige, bei dem OOP wirklich hilft. OOP sollte sich auch mit der Wiederverwendung von Code befassen und dabei ) hier und da können Sie viele von Ihnen erstellte Objekte nicht wirklich wiederverwenden. Konzentrieren Sie sich also darauf, sicherzustellen, dass Ihr System gut getrennt ist. Sobald Sie die Reife erreicht haben, können Sie loslegen Angenommen, Onkel Bob kommt und übernimmt die Leitung Ihres Projekts. Er wird sagen: "Ok, das ist höllisch dumm, aber zumindest ist alles getrennt, gut benannt und dokumentiert, damit ich zumindest weiß, worum es geht" (hoffe ich). Für mich funktioniert es. Mein LOC ändert sich ständig, aber zum Zeitpunkt des Schreibens sind es 110.000 Codezeilen, 110.000 Codezeilen, die für eine einzelne Person harmonisch funktionieren.


Hier ist eine Bearbeitung eines 8-Monats-Codes, den ich überarbeite, 3 Monate später:

Alles macht Sinn. Ich kann jetzt das, was ich damals geschrieben habe, konzeptionell nehmen und den Code mit neuen Ideen neu schmieden, weil ich genau verstehe, was los ist und warum es wegen der Schaltpläne/guten Benennung und Kommentare funktioniert. Ich habe vor langer Zeit einen Code geschrieben, bei dem es mir egal war, ob ich gut benenne und so, und es ist schmerzhaft, durchzugehen. Ich denke jetzt darüber nach, was der nächste Schritt zur Erklärung meines Codes sein könnte.

12
coolpasta