Krautkanal.com

Veröffentlicht am 2016-06-02 20:18:33 in /prog/

/prog/ 8921: Fragezeichenmödchen

vickyshits Avatar
vickyshits:#8921

Wie geht Bernd mit einem neuen Projekt um, das auf Weichware von jemand anderem basiert, die Spezifikation zu der Geschichte >300 Seiten beträgt und Bernd weder vom Standard noch von die fremde Weichware durchblickt. Wie am besten anfangen?

Alle Funktionen nacheinander angucken und hoffen, dass man irgendwann einen roten Faden entdeckt?

chanpory Avatar
chanpory:#8922

-vom, Selbstsäge

nehemiasec Avatar
nehemiasec:#8923

Bevor Verwirrung aufkommt, IDF solls um Bernds beste Methoden gehen sich irgendwo in was neues reinzufuchsen.

necodymiconer Avatar
necodymiconer:#8924

Aufgrund jahrelanger Erfahrungen mit verschiedenen Kollegen, externen Mitarbeitern, Coaches und anderen wichtigen Experten habe ich festgestellt, dass diese folgende Best Practice die beliebteste Vorgehensweise für solche Fälle ist:

- Niemals zugeben, dass man nicht durchblickt.
- Verschwende deine Zeit nicht mit ewigem Codelesen und Einarbeitung, das ist anstrengend und langweilig.
- Durchkämme den Code stattdessen für ein paar Minuten, und picke ein paar Schwachstellen heraus, egal wie trivial sie sind.
- Vereinbare eine Projektbesprechung mit allen Verantwortlichen (am besten High Level, die wenig von Code verstehen), oder warte bis zur nächsten ab.
- Präsentiere nun deine Erkenntnisse über den katastrophalen Zustand der Codequalität. Alles ist unübersichtlich, uneinheitlich, die von dir nun rausgepickten Codestellen sind absolut typisch, und noch harmlose (!) Beispiele für das destaströse Werk des verantwortlichen Entwicklers.
- Es folgt nun ein 30 Minuten Monolog darüber, wie wichtig Codequalität ist, und wie sehr das Projekt dadurch gefährdet ist.
- Da das Projekt eine schlechte Qualität hat, schlecht skaliert, nicht state of the art ist, kann es nur durch eine Neuentwicklung, am besten unter Zuhilfenahme von Technologie X (hier einssetzen, womit du dich besonders gut auskennst), gerettet werden.

kinday Avatar
kinday:#8927

>>8924
Der Pfosten war unterhaltsam, da Bernd tatsächlich schon mal seinen Chef überzeugen konnte einen externen Ranzcode wegzuwerfen und komplett von Grund auf neu zu entwickeln.

starburst1977 Avatar
starburst1977:#8928

Ich war mal genauso hilflos vor großen Codebasen. Inzwischen habe ich keine Angst mehr, stattdessen ein paar nützliche Regeln:
- die größte Quellcodedatei ist meistens ein guter Anfang - man entwirft den Code nicht so, dass es eine Datei mit dominierender Größe gibt, daher ist es wahrscheinlich die, wo die meisten interessanten Dinge angebaut wurden.
- Wenn Callbacks und virtuelle Funktionen die Struktur verschleiern hilft der Debugger. Ich benutze nicht gerne Debugger, um Code zu "verstehen", aber hier kann er manchmal viele Stunden sparen.
- Datenstrukturen sind viel aufschlussreicher als Code
- man findet manchmal ein paar haarsträubende Fehler oder Anzeichen von Inkompetenz, aber meistens hilft es einem mehr weiter, diese als Ausrutscher zu betrachten, als ab da zu denken "hier waren Irre am Werk und der ganze Code ist offensichtlich Müll".

Eine 300-Seiten-Spec hatte ich noch die, ob die gut ist? Wenn ja - super! Wenn nicht - besser als nichts... Eine richtig übel schlechte Spec hatte ich noch nie, meine letzte die ich gelesen habe war sogar ziemlich gut, war von einem Schweizer Medizintechnikhersteller, da wundert einen das nicht so sehr.

sgaurav_baghel Avatar
sgaurav_baghel:#8934

1. Das Wichtigste am Anfang ist IMHO, die Fachlichkeit zu verstehen. Bester Einstieg über Use-Case- und Klassendiagramme. Zur Not gehen auch ein Überblick über Datenbanktabellen und deren Beziehungen.
2. Hoffen, dass übliche Vorgehensweisen, Konventionen und Design Patterns angewendet wurden (die jeweils für die Technologie gelten, die in dem Projekt angewendet wird), so daß du plausible Vermutungen anstellen kannst, welcher Code wo wie stattfindet/abgelegt/benannt ist.
3. Sich dummstellen und die gesame Anwendung/alle Funktionen einfach mal komplett aus Anwendersicht ausführen, rumklicken, durchprobieren.
4. Vielleicht exemplarisch eine einzelne, nicht zu komplexe Funktionalität rausgreifen, und die im Code mal durch alle Anwendungsschichten hindurch betrachten, und/oder debuggen.

motionthinks Avatar
motionthinks:#8936

>>8921
Den ganzen Code muss man gar nicht verstehen. Es reicht aus, eine Aufgabe zu bekommen, eine Stelle im Code zu finden, und deinen eigenen Code darein zu schreiben, so dass die gestellte Aufgabe erledigt wird.

javorszky Avatar
javorszky:#9122

>>8936
Sagte der Wordpress-Programmierkrepierer.

lanceguyatt Avatar
lanceguyatt:#9123

>>8924
traurig weil es vermutlich wirklich funktioniert.
Und wahrscheinlich sogar völlig unabhängig von der Qualität der Drittsoftware.

orkuncaylar Avatar
orkuncaylar:#9127

Ein paar Monate später kann OP behaupten, dass er sich erfolgreich in einen Teil reingefuchst hat. Vielleicht wird eines Tages doch dieses Programmiererfühl in mir aufkommen.

Neuste Fäden in diesem Brett: