Was siehst du zuerst an: den Code oder das Design?

Wenn Sie gerade ein neues Projekt kennengelernt haben, wonach suchen Sie als Erstes, um eine Vorstellung davon zu bekommen, wie es funktioniert?

Suchst du zuerst nach dem Design? Wenn es ein Design gibt, worauf achten Sie darin? Klassendiagramme oder Bereitstellungsdiagramme oder Sequenzdiagramme oder etwas anderes?

Oder gehst du direkt zum Code? Wenn ja, wie verstehen Sie das Zusammenspiel der verschiedenen Ebenen?

Ich beginne mit Code. Gegebenenfalls separate Designdokumente sind wahrscheinlich falsch oder falsch interpretiert. Also versuche ich zunächst, einen einfachen Fluss durch den Code zu verfolgen. Wenn es sich um eine Webanwendung handelt, kann es sich beispielsweise um eine Anfrage oder eine Abfolge von Anfragen handeln. Sobald ich das getan habe, habe ich eine Art Skelett, an dem ich mehr Verständnis haben kann. Dann gehe ich vielleicht zurück und lese Entwürfe oder andere Dokumentationen, aber zu diesem Zeitpunkt habe ich etwas Konkretes, mit dem ich sie in Beziehung setzen und mit dem ich sie validieren kann, damit ich Duff-Informationen erkennen kann. Oder ich lese einfach weiter Code oder Testfälle usw.

Ich würde auf einer höheren Ebene beginnen. Wenn es Benutzerdokumentationen gibt - Benutzerhandbuch oder Leitfaden. Andernfalls werfen Sie einen Blick auf die Anforderungsspezifikation, damit Sie eine Vorstellung davon haben, was die Software tun soll. Ich würde dann das Design anschauen und versuchen, es auf die Codedateien abzubilden. Hoffentlich sind diese in sinnvoller Weise in Ordner strukturiert. Ich würde dann einen Teil des Entwurfs auswählen und in die Dateien gehen, um dem Fluss des Codes zu folgen, ohne mich zu sehr in die Details zu vertiefen.

Ich beginne mit dem Einrichten eines Entwicklersystems. Ich benutze das dokumentierte Verfahren. Auf diese Weise kann die Katze sehen, inwieweit die Dokumentation mit der Realität übereinstimmt.

Es sagt mir auch, was die Abhängigkeiten sind. Das ist wichtig.

Jetzt, da ich ein Entwickler-Setup habe (und das Setup-Dokument im Laufe der Zeit mit Korrekturen auszeichne), erstelle ich eine Version. Am Ende stelle ich in dieser Phase Fragen.

Jetzt ist es fertig, ich mache die Einführungsübung aus dem Benutzerhandbuch. Das sagt mir ungefähr, was das System wirklich macht.

Jetzt habe ich eine teilweise Ahnung über das System, ich lese die Konstruktionsdokumente, von denen ich jetzt annähernd glaube, wie falsch die Dokumente bisher waren.

Sobald ich zur eigentlichen Dokumentation des Verhaltens komme, kann ich den Code untersuchen und sehen, was wirklich da ist. Sie reihen sich nie aneinander, aber ich weiß jetzt, wie viel ich glauben soll.

Dann schaue ich in der IDE-Ausgabe nach "todo" und "fixme" -Kommentaren. Dinge wie "Fix in Version 2.0" sind auch ein Hinweis.

Es geht also nur darum, die Richtigkeit zu lernen, und wie die Leute betonen, sind separate Designdokumente selten auf dem neuesten Stand oder korrekt, aber sie sagen Ihnen, was die Leute zu einem bestimmten Zeitpunkt gedacht haben. Und natürlich sind diese Leute wahrscheinlich nicht da, um zu verhören.

Ich bevorzuge es, mit dem Entwurf zu beginnen, um einen Überblick über das Projekt zu erhalten und zu versuchen, einige seiner Hauptmerkmale und / oder Strukturen zu verstehen, bevor ich mich mit den Details befasse.

Immer das Design. Mit dem Code lohnt es sich, die Schritte zur Einrichtung des Entwicklers durchzuarbeiten (Auschecken des Quellcodes, Erstellen des Projekts, Vornehmen erforderlicher Konfigurationsänderungen), aber es macht keinen Sinn, die Struktur einer Anwendung aus dem Code zu lernen. Das sagt Ihnen nur, was die Struktur ist, nicht, warum die Struktur ist oder was die anderen Entwickler die Höhepunkte und die schlechten Punkte der Architektur denken. Diese lernst du aus Whiteboard-Diagrammen und chattest mit den Entwicklern.

Für ein komplexes Stück Software würde ich es ungefähr so ​​angehen, als wäre es ein neues Entwicklungsprojekt. Beginnen Sie mit den großen Ideen - Vision, Kontext, Umfang, Interessengruppen. Lesen Sie einige Benutzerdokumentationen durch und machen Sie sich ein Bild von deren Verwendung. Wenn möglich (oder zutreffend), sollten Sie sich mit der Software vertraut machen. Schauen Sie sich dann die Anforderungen und die Konstruktionsdokumentation an, um eine Vorstellung davon zu bekommen, wie dies auf hohem Niveau funktioniert. Sprechen Sie mit den Designern, wenn sie noch da sind. Betrachten Sie die Systemarchitektur aus verschiedenen Perspektiven. Von dort aus können Sie sich mit der Kernfunktionalität befassen, sich Code ansehen und bei Bedarf zu den Anforderungen und dem Design zurückkehren. Führen Sie beim Betrachten von Code die Software aus, um sie in Aktion zu sehen. Stellen Sie währenddessen eine zusammenfassende Dokumentation zusammen, damit Sie später darauf zurückgreifen können - Sie besitzen Cliffs Notes. Verzweigen Sie sich, bis Sie eine ziemlich gute Vorstellung davon haben, wie alles funktioniert und zusammenpasst, aber konzentrieren Sie sich auf die Teile, mit denen Sie arbeiten werden. Inzwischen haben Sie ein umfassendes Verständnis des gesamten Systems oder zumindest der für Sie zutreffenden Teile.

Natürlich haben Sie in der realen Welt möglicherweise nicht die Zeit, dies alles durchzuarbeiten, bevor Sie anfangen müssen, sich die Hände schmutzig zu machen, insbesondere bei größeren Projekten. Aber so würde ich es machen, wenn es nach mir ginge.

Sie sollten zwischen dem Code selbst und allen Konstruktionsdokumenten hin und her arbeiten.

• Sie können mit Code oder Design beginnen, und es spielt keine Rolle. Lesen Sie den Code, bis Sie wirklich verwirrt sind, und lesen Sie dann die Designdokumente. Oder lesen Sie die Designdokumente, um ein umfassendes Bild zu erhalten. Sehen Sie sich dann den Code an, um zu sehen, wie er aussieht. Wiederholen Sie dies so lange, wie Sie mit dem Code arbeiten.

• Beachten Sie, dass Designdokumente fast immer veraltet und in vielerlei Hinsicht falsch sind. Solange Sie diese Punkte berücksichtigen, helfen Ihnen veraltete Dokumente dennoch, die Meinung des Autors zu einem früheren Zeitpunkt zu verstehen. Viele der wichtigen Themen und Bedenken werden weiterhin gültig sein, und Sie werden sehr wahrscheinlich schneller verstehen können, wie der Code dahin gelangt ist, wo er sich befindet, wenn Sie sogar ein datiertes Bild davon haben, wohin der Autor ursprünglich gegangen ist gehen.

• Erstellen Sie beim Durcharbeiten des Codes und des Entwurfs Ihre eigenen Dokumente, die Ihr heutiges Verständnis des Codes beschreiben. Vielleicht handelt es sich bei diesen Dokumenten um eine einfache Skizze oder zwei, vielleicht sind sie Aufzeichnungen in einem Wiki, vielleicht sind sie etwas anderes. Machen Sie sie nicht zu kompliziert: Keine 30-seitigen Word-Dokumente. Schreiben Sie einfach Ihre Ideen auf, um Ihr eigenes Denken zu verdeutlichen.

Dies hängt von der Art der Anwendung ab. Wenn es sich um eine datenzentrierte App handelt, beginne ich normalerweise mit dem Datenbankdesign. Wenn es eine Benutzeroberfläche hat, die Sie ausführen können (oder gute Bildschirmdesigns), können diese Ihnen auch eine gute Vorstellung davon geben, was die App sehr schnell macht (ich spreche hier höchstens ein paar Stunden). Danach fange ich an, mich mit Code zu befassen, und es wird sinnvoller, weil ich weiß, was die Anwendung tut.

Ich beginne mit der Konstruktionsdokumentation. Insbesondere die Spezifikation - die die Absicht der betrachteten Sache angibt.

Wenn möglich, schaue ich dann in Designnotizen und Dokumentationen nach, um einen allgemeinen Eindruck davon zu bekommen, wie es gemacht wurde, über den Denkprozess, den Stil und die Natur der Betroffenen.

Wenn möglich, spreche ich dann mit den Leuten, die daran gearbeitet haben - was macht es? Wie? Warum? Wo sind die Leichen begraben?

Es gibt eine Tendenz unter Entwicklern, in Code zu springen: "Lassen Sie mich Ihnen diesen Code zeigen". Das ist in Ordnung für sie, aber sie neigen dazu, meine Bedürfnisse zu missbrauchen - das heißt, die hohe Ebene zu verstehen, die den Low-Level-Sachen Kontext verleiht.

Es verbraucht große Mengen an Gehirnleistung, um kleine Codefragmente außerhalb des vollständigen Kontexts zu betrachten und alles Bedeutsame zu verstehen. Wenn es also möglich ist, die Entwickler dazu zu bringen, über PRINZIP, Struktur, Einheiten und Module zu sprechen, führt dies zu einer Wertschätzung der Aufgabe.

Nur dann lohnt es sich, in den Code einzusteigen.

Im großen Schema der Dinge ist das Betrachten des Codes das Betrachten einer Seite voller Nullen und Einsen. Es gibt eine Bedeutung, aber es dauert lange, bis man es herausfindet. Wenn Sie wissen, wo Sie suchen müssen und welche Teile von Bedeutung sind, können Sie den Suchbereich einschränken.

Alles, was gesagt wurde - wenn es kein Dokument, keine Leute und nur Code gibt - dann bleibt nichts anderes übrig, als sich den Code anzuschauen.

In diesem Fall versuche ich normalerweise nicht, es durch langsames, tiefes Lesen zu verstehen. Ich mache einen kurzen Durchgang und überfliege alles. Manchmal sind dies nur geöffnete Dateien und sitzen mit dem Drücken der Bild-ab-Taste. Sie können eine erstaunliche Wertschätzung für ein großes Bild erhalten, indem Sie dies tun. (In einigen Fällen führe ich sogar einen String-Dump für ausführbare Dateien durch und durchsuche diese nach Signaturen und Mustern. Dies war in den letzten etwa 20 Jahren erstaunlich fruchtbar.)

Ich beginne mit den Tests. Wenn die Komponententests und Integrationstests gut geschrieben sind, beschreiben sie die Anwendungsfälle. Wenn sie nicht gut oder gar nicht geschrieben sind (leider ist dies größtenteils der Fall), beginne ich mit Einstiegspunkten im Code und stimme diese mit dem Design überein.

Anschließend schreibe ich Tests für jeden Anwendungsfall, der anhand des Baums ermittelt wurde, den Sie nach der Untersuchung der Einstiegspunkte gefunden haben, um den Code zu untersuchen und mit Dienstprogrammen für die Codeabdeckung zu ermitteln, was mir fehlt. Diese Tests erklären mir genau, wie der Code funktioniert.

Ich versuche immer, etwas, das ich anschaue, aufzuwerten. Schreiben von Tests, Bereinigen von Code, Refactoring großer Funktionen (über 20 Zeilen).

Ich finde, dass das Erstellen von Dokumentation allein dem Code keinen wirklichen Wert hinzufügt, da er niemals mit dem Code interagiert.

Nun, was ist "das Design"? eine README? ein uml diagramm? Sie können ein Designdokument auf halbem Weg erstellen (und die meisten tun dies). Sie können nicht auf halbem Weg codieren

Jedes Design wird einfach eine Meinung sein , während der Code die Tatsache ist

Ich werde nur auf sekundäre Dokumente verweisen, wenn ich die Argumentation des Codes nicht verstehen kann

Das Lesen von Code ist eine wesentliche Fähigkeit für einen Entwickler. Sie können es genauso gut jetzt lernen, aber während Ihrer Karriere werden Sie sowieso nicht viele nützliche Dokumente sehen

Dann schaue ich mir README, TODO und Changelog des Entwicklers an. Wenn ich nicht verstehe, warum die Software geschrieben wurde, wie sie geschrieben wurde und wohin sie geht, benutze ich sie nicht.

Entwerfen Sie zuerst, dann codieren Sie, wenn Sie möchten, von oben nach unten, damit ich den Kontext auf jeder Ebene verstehe, auf der ich arbeiten muss.

Aber wenn ich eine ganz bestimmte Änderung vornehmen muss, z. B. einen Bericht oder eine Berechnung, schaue ich mir einfach den Code an.

Genauer gesagt ist mein "Design First" -Ansatz der folgende:

Ich beginne mit dem Domain-Modell, wenn es eines gibt, und wenn es keines gibt, erstelle ich zumindest ein Basis-Modell (ein guter Ausgangspunkt ist das Datenmodell). Es definiert das "Glosar" der Anwendung und die Beziehung zwischen den Objekten (Klassen).

Es zeigt an, "welche Objekte von der Anwendung behandelt werden".

Dann suche ich nach dem Anwendungsfallmodell, um herauszufinden, "welche Prozesse von der Anwendung ausgeführt werden", obwohl ich eine Prozesszuordnung bevorzuge, wenn dies eine ist, die Abfolgen von Prozessen zeigt.

Danach sollte ich ein schönes Bild der Anwendung haben und dann kann ich die Änderung entwerfen.

Die obige Antwort bezieht sich übrigens auf Geschäftsanwendungen.

Der Code lügt nicht. Auf jeden Fall eine gute Idee, sich zuerst einen Überblick über das Projekt zu verschaffen, um zu verstehen, was es tut. Wenn es jedoch Ihre Aufgabe ist, ein detailliertes Verständnis für die Funktionsweise des Projekts zu erlangen, ist das Betrachten von Code, zumindest für mich, das Betrachten eines Puzzles Stück für Stück, mit der Ausnahme, dass Sie mit jeder Klasse, die Sie betrachten, eine weitere hinzufügen Stück des Puzzles. Wenn der Code gut strukturiert ist, können Sie sehen, wie sich aus den Namen der Klassen ein Muster bildet, ohne auch nur zu untersuchen, was die Klasse tut. In vielen Fällen können Sie Hinweise und Hinweise aus dem Code erhalten, die Sie weiter unterstützen.

Schließlich erhalten Sie eine unmissverständliche Vorstellung davon, was das Programm leistet, ein vollständiges Puzzle. Die Dokumentation ist möglicherweise unvollständig oder ungenau, aber der Code lügt nie. All dies können Sie tun, ohne herauszufinden, was jede einzelne Methode tut. Nicht jeder kann auf diese Weise etwas über ein Projekt lernen, aber wenn Sie es oft tun, fällt es Ihnen leichter, ganz zu schweigen davon, dass Sie innerhalb weniger Stunden den Kern einer mittelgroßen Anwendung erhalten. Obwohl ich denke, es kommt alles auf den Geschmack.

1. Der funktionale Zweck der Anwendung
2. Der Funktionsumfang und Ablauf der Anwendung und seine Verknüpfung mit anderen Systemen des Kunden.

Nachdem ich den Code des kritischsten Moduls / Anwendungspunkts gesehen habe: den Code, kann ich die Güte des Entwurfs überprüfen.

Beispiel:

Sie müssen im Application Management einer Web-App über die Finanzberichterstattung arbeiten.

1. Ich frage und lese die Dokumentation über den Zweck: Welche Daten müssen gemeldet werden? Wer nutzt diese Anwendung?
2. Was sind die verknüpften Systeme? Gibt es eine Frist zum Empfangen oder Senden von Daten an jemanden? Wenn dieses System ausfällt, welche anderen Anwendungen sind beschädigt oder gestoppt, welche anderen Abteilungen sind beschädigt?

Nachdem ich den Code über die Nachricht gelesen habe, die Start- und Endanwendung (für wahrscheinliche Sperre in DB), den Masterprozess zur Erstellung von Daten, die gemeldet werden müssen usw. usw. (zum Beispiel bei der Speicherung von Gas handelt es sich beim Masterprozess um die Berechnung des Gasvorrats im Lagerbereich der Kunden mit Lieferung und Einspeisung; der sekundäre Prozess ist die Abrechnung über diese zuvor berechneten Daten)

Weder Code noch Design. Ich spreche gerne mit den Stakeholdern und Endanwendern und finde heraus, wie es aus ihrer Sicht funktioniert. Sobald ich ein Bild in meinem Kopf erstellen kann, schaue ich kurz auf das technische Design und dann auf den Code.

Ich werde zuerst mit Design und dann gleichzeitig mit Code arbeiten. Das ist sehr wichtig, weil jedes Projekt anders ist. Sie müssen einen Plan und einen umfassenden Prozessworkflow von A bis Z erstellen, bevor Sie gleichzeitig mit der Bearbeitung der Codes beginnen können. Jede getroffene Entscheidung muss dokumentiert werden, damit andere Teams (oder Sie selbst), die die Codes entwickeln, das neueste Update und die bestätigten Informationen erhalten.

Wenn es ein gutes High-Level-Designdokument gibt, verwende ich es. Es muss kurz und aktuell sein. Wenn es zu ausführlich oder veraltet ist, gehe ich zum Code.

Natürlich kommt es auf das Projekt an, nicht wahr? Ein äußerst komplexes oder facettenreiches Projekt wird möglicherweise besser durch Dokumentation angegangen (wenn die Dokumentation solide genug ist).

Ein einzelnes einfaches Modul oder eine einfache Anwendung wird meiner Meinung nach fast immer am besten auf Codeebene angesprochen.

Es gibt keine richtige Antwort für jede Situation!