wie arbeite ich mit komplexen Code?

[TheWorldDrown]

Als Junior Entwickler stoße ich immer wieder auf Code der:

• Bibliotheken einbindet die ich nicht kenne
• Klassen mit zahlreichen Vererbungen und Interfaces beinhaltet
• sehr viele Zeilen Code und Klassen im Projekt hat

Meine bisherigen Methoden sind:

• Programm Debuggen und versuchen Schritte nachzuvollziehen
• Methoden und Eigenschaften der Oberklassen ansehen
• Versuchen Entwurfsmuster im Code zu identifizieren

Meine Ergebnisse sind bisher recht bescheiden, was das verstehen von komplexen Code angeht.

Habt ihr Tipps für mich?

Bearbeitet 4. März 2020 von TheWorldDrown

[Saheeda]

Du kannst auch learning tests nutzen.

Das heißt, du schreibst einen Testfall, in dem du definierst, was nach deinem Verständnis des Codes passiert, wenn der Code ausgeführt wird. Ist der Test grün, stimmt deine Annahme. Solche Tests lösche ich vorm Commit wieder, aber es hilft, sich erstmal an den Code heranzutasten.

[TheGuy]

Refactoring, unit - tests schreiben, Design patterns erkennen und versuchen umzusetzten. Ja so ein legacy Code ist einfach und eine Qual

[treffnix]

vor 3 Minuten schrieb TheGuy:

Refactoring

Refactoring in Code, den man nicht versteht? Würde ich mir nicht zutrauen... Ich versuche erst zu verstehen, bevor ich anfange Änderungen vorzunehmen, daher rate ich von diesem Punkt ab.

[KeeperOfCoffee]

Das ist recht normal heute. Das ist Fluch und Segen zugleich. Es gibt heutzutage für extrem viele Probleme fertige Lösungen. Es spricht auch nichts dagegen diese zu nutzen, statt das Rad das tausendste Mal neu zu erfinden. 

Die Zeiten, in denen man alles von Grund auf schreibt, sind vorbei. Viel Code wird heutzutage einfach generiert. Teilweise wird hier auch schon ML einbezogen.

Heutzutage ist muss man eher die Lösung für Problem X finden, anstatt die Lösung für Problem X komplett neu zu programmieren. Du hast Problem Y...gut dann mal nachsehen ob es für Poblem Y bereits Tools gibt, die einem das Leben erleichtern. 

Du musst auch nicht jeden Part einer Bibliothek, die du einbeziehst, kennen und verstehen wie sie etwas machst ... wichtiger wäre zu wissen wie du sie nutzt und damit arbeitest. Bis du jeden Punkt der Bibliothek oder des Framework kennst wird eine neue Version released und du beginnst von neuem....

Desweiteren musst du nicht ein komplettes Framework verstehen. Es gibt heutzutage so viele Felder in der Entwicklung, so viele Frameworks ... viele zu viele Informationen für eine Einzelperson.

[PacWhite]

Schließe mich meinem Vorredner an. Es ist immer wieder eine Qual wenn meine Mitarbeiter versuchen das Rad neuzumeißeln, es ist keine Schande Code weiter zu nutzen und auch alle Senior Developer, DevOps, FullStack Dev's u.s.w nutzen fertige Codeschnipsel aus Stackoverflow, warum auch nicht, Spart deiner Firma arbeit und Zeit was wiederum Geld spart. 

Um schweren Code zu verstehen wenn zum beispiel MVVMs, MVCs und Co verwendet wurden hilft sich in die Doku einzulesen der jeweiligen Frameworks. Es hilft auch mit dem zugrundeliegenden Framework sich einmal auseinanderzusetzen. Sobald man das in einer Testapplikation verstanden hat versteht man auch den Code des anderen leichter. (Heißt nicht das du ALLES darin verstehen musst. Man sollte nur in seinem Kopf den logischen Gedanken des Frameworks ablegen.)

Du wirst keinen Senior Dev finden der von MVC auf MVVM umsteigt und sofort sagt "Jep, ich versteh das auf Anhieb."

Ich versteh es heute ja noch nicht mal und mach es seit 20 Jahren. 

#NeuHierUndGibtErstmalSenfAb.
 

[Whiz-zarD]

vor 1 Stunde schrieb KeeperOfCoffee:

Heutzutage ist muss man eher die Lösung für Problem X finden, anstatt die Lösung für Problem X komplett neu zu programmieren. Du hast Problem Y...gut dann mal nachsehen ob es für Poblem Y bereits Tools gibt, die einem das Leben erleichtern. 

Das kann man aber auch nicht so pauschal sagen. Es mag zwar vielleicht für Problem X eine Lösung geben aber man muss immer abwägen, ob ich mich jetzt von einem Dritten abhängig mache oder nicht. Die Lösung mag heute noch laufen aber wie sieht es morgen aus? Wird das Tool/Framework/Whatever auch morgen noch weiterentwickelt oder stellen sie die Entwicklung ein, weil sie keinen Bock mehr darauf haben? Und wenn es Open Source ist, wie groß ist die Community dahinter? Ich finde, man sollte mit Drittbibliotheken schon etwas vorsichtig sein und schon etwas sparsam damit sein oder sie so abstrahieren, sodass man auch andere Bibliotheken als Alternative einsetzen könnte. 

vor einer Stunde schrieb PacWhite:

Schließe mich meinem Vorredner an. Es ist immer wieder eine Qual wenn meine Mitarbeiter versuchen das Rad neuzumeißeln, es ist keine Schande Code weiter zu nutzen und auch alle Senior Developer, DevOps, FullStack Dev's u.s.w nutzen fertige Codeschnipsel aus Stackoverflow, warum auch nicht, Spart deiner Firma arbeit und Zeit was wiederum Geld spart. 

Auch hier muss ich ein bisschen widersprechen. Ja, ich schaue auch oft bei Stackoverflow nach aber ich kopiere nicht blind irgendwelche Codeschnipsel. Man sollte schon verstehen, was da passiert und sollte die Schnipsel auf eigene Anforderungen anpassen. Ich hab schon bei einer Firma gearbeitet, die blind die Schnipsel kopierte und keiner sie verstand, wenn sie nicht so funktionierten, wie es eigentlich gedacht war. Die Firma gibt es nicht mehr.

vor einer Stunde schrieb PacWhite:

Um schweren Code zu verstehen wenn zum beispiel MVVMs, MVCs und Co verwendet wurden hilft sich in die Doku einzulesen der jeweiligen Frameworks. Es hilft auch mit dem zugrundeliegenden Framework sich einmal auseinanderzusetzen.

Ist zwar alles schön und gut aber viele Firmen haben dennoch ein eigenes Framework, um gewisse Arbeitsabläufe einfacher zu machen oder zu abstrahieren. Häufig sind diese Frameworks dann nicht dokumentiert und dann bleibt einem nichts anderes übrig, als durch den Code zu wühlen oder Mitarbeiter zu fragen.

vor 32 Minuten schrieb Saheeda:

Das heißt, du schreibst einen Testfall, in dem du definierst, was nach deinem Verständnis des Codes passiert, wenn der Code ausgeführt wird. Ist der Test grün, stimmt deine Annahme. Solche Tests lösche ich vorm Commit wieder, aber es hilft, sich erstmal an den Code heranzutasten.

Dafür muss der Code aber auch testbar sein. Vor allem bei Legacy Code muss dies nicht unbedingt der Fall sein aber wenn man gerade neu in der Firma ist und den Code nicht kennt, beißt sich die Katze in den eigenen Schwanz. Woher will man denn wissen, was man testen möchte, wenn man nicht mal die Architektur und Struktur der Anwendung kennt? Wo will man denn z.B. bei einer Anwendung mit über Tausend Klassen anfangen? Der erste Schritt ist also immer, sich durch den Code zu wühlen. Wir haben für jeden Mitarbeiter eine interne Schulung, um den Mitarbeiter grob zu erklären, wie die Architektur funktioniert und zeigen denen schon die gängigsten Schritte. Also Daten aus der Datenbank holen, etc. Der Rest kommt dann mit zunehmender Erfahrung.

[Defneqon]

Falls deine Plattform/Technologie eine Art Konsole bietet (also quasi eine Laufzeitumgebung, auf der du  Statements direkt an den Compiler/Interpreter schicken kannst), benutze sie. Dadurch habe ich in meiner neuen Firma schnell nicht nur die hier verwendete Sprache sondern auch häufig benutzte Klassen (also quasi das Firmenframework) (kennen-) gelernt. 

Code-Schnipsel eignen sich hervorragend, um sie direkt auf einer Konsole zu testen. Speziell für objektorientierte Sprachen gehts damit kaum einfacher: Einfach Klassen so erzeugen, Methoden, die man nicht versteht, auf diesen ausführen und das Ergebnis analysieren.

Und: Mitarbeiter fragen. Selbst wenn damit nervst. Immer fragen. Mitarbeiter, die bereits 5+ Jahre da sind, sind eh die besten Quellen für Wissen.

 

EDIT: Lass dich nicht abschrecken von eventuellem "Overhead" (so nenne ich das jetzt mal...). Wenn eine Klasse von zig Interfaces oder anderen Klassen erbt, muss das nicht unbedingt gleich heißen, dass jede Funktionalität auch tatsächlich verwendet wird... Es gibt ja meistens einen Grund, warum eine Klasse gebaut wird, und dieser Grund wird eben in dieser Klasse ausdefiniert... meiner Erfahrung zufolge würde ich sagen, dass gefühlt nur ein Bruchteil der Eltern-Klassen gebraucht wird. Oft stehen hinter vielen Vererbungshierarchien auch einfach Conventions, nach dem Motto "Bei uns im Unternehmen, wenn wir hier neue Klassen bauen, erben die bitte standardmäßig von den und diesen Klassen... weil falls man Funktion/Methode/Prozedur X für Zweck Y braucht, hat man das schon drin."

Bearbeitet 4. März 2020 von Defneqon

[KeeperOfCoffee]

Natürlich müssen die Bibliotheken entsprechende Reichweite und Support aus der Community haben. Man muss das halt abwägen. Wenn ich z.B. ein Modul erstellen würde, welches zum Teil auch CSVs lesen soll, dann würde ich nicht groß selbst eine CSV Klasse schreiben, sondern würden einfach https://www.nuget.org/packages/CsvHelper/ nehmen (war jetz das erste bei nuget). Bei einigen Millionen Downloads und Updates alle paar Monate kann man sowas relativ mit guten Gewissen nutzen.  

Codeschnipsel sind wirklich ein Fluch meiner Meinung nach. Gibt so viele Leute die Mist auf StackOverFlow posten. Und es gibt auch viele Leute, die Code verwenden, der 2012 dort gepostet wurde ... obwohl es inzwischen viel bessere Mittel gibt.

vor 1 Stunde schrieb Whiz-zarD:

Ist zwar alles schön und gut aber viele Firmen haben dennoch ein eigenes Framework,

Firmeninterne Frameworks die nicht dokumentiert werden sind die Hölle. Vor allem, wenn dann einige Personen gehen, die diese Frameworks erstellt haben. Als ich meine Ausbildung gemacht habe konnte ich schon etwas coden (extrem schlecht...aber ich konnte den Code zuminderst lesen) .... aber da es ein firmeninterne Framework war konnte ich gefühlt ein  Jahr kaum was machen, als ständig Fragen zu stellen. Selbst einige Profis sind an vielen Stellen immer gescheitert. Im Nachhinein frage ich mich echt, ob sowas es echt wert ist.