2009-05-02 4 views
4

Ich arbeite in einer 12 Jahre alten Codebasis, auf der ich der einzige Entwickler bin. Es gibt Zeiten, in denen ich eine kleine Änderung aufgrund einer Intuition (oder Quantensprung in der Logik ;-) machen werde.Machst du jemals einen Codewechsel und teste nur, anstatt zu versuchen, die Änderung, die du vorgenommen hast, vollständig zu verstehen?

Normalerweise versuche ich diese Änderung zu dekonstruieren und stelle sicher, dass ich den Code gründlich lese.

Allerdings manchmal (mehr und mehr in diesen Tagen) Ich nur testen und stellen Sie sicher, es hatte die Wirkung, die ich wollte. (Ich bin ein ziemlich gründlicher Tester und würde sogar testen, wenn ich den Code lese).

Dies funktioniert für mich und wir haben überraschend (im Vergleich zu den meisten Software, die ich sehe) nur wenige Fehler in die Wildnis entkommen.

Aber was ich frage mich ist, ob dies nur die "Kunst" Seite der Codierung ist. Ja, in einer idealen Welt würden Sie jedes Codebeispiel umfassend lesen, das Ihre Änderung geändert hat. Aber in der Praxis, wenn Sie sicher sind, dass es nur einen kleinen Codeabschnitt betrifft, ist dies eine gängige Praxis?

Ich kann natürlich sehen, wo dies ein katastrophaler Ansatz in den Händen eines armen Programmierer wäre. Aber dann habe ich Programmierer gesehen, die angeblich den Code lesen und Dinge links und rechts (in ihrem eigenen Code basierend, an denen sie nur gearbeitet haben).

Antwort

1

Ich bin höchstwahrscheinlich nicht das beabsichtigte Ziel dieser Frage, da ich erst seit ein paar Jahren ein professioneller Entwickler bin. Allerdings werde ich meine 2 Cent trotzdem werfen.

Ich mache das die ganze Zeit. Wenn ich unter einer engen Frist bin, bekomme ich den Code zuverlässig, egal ob ich das Ganze verstehe oder nicht.

Im Allgemeinen versuche ich mein Bestes, um später zurückzugehen und zu schauen, was ich tat - normalerweise an den Wochenenden - und den Code zu aktualisieren, um irgendwelche schlechten Entscheidungen mit dem kopierten/eingefügten Code zu reflektieren. Aber die Deadline ist König, vor allem, wenn es im Vertrag Strafen dafür gibt. Sie können jederzeit ein Update senden, das Probleme später behebt.

+0

Finden Sie oft, wenn Sie zurückkommen und diesen Code überprüfen, dass Sie einen Fehler verursachenden Nebeneffekt erzeugt haben (im Gegensatz zu nur hässlichem Code, der sauberer sein könnte). –

2

Manchmal ändern Code und Tests hilft Ihnen, den Code zu verstehen. Natürlich treten Sie immer auf gefährlichen Boden, wenn Sie Änderungen vornehmen, die Sie nicht verstehen. Ich denke, Ihr Erfolg basiert nicht nur auf Ihrer "Erfahrung", sondern auch auf der Stabilität des aktuellen Codes.
Sie können leicht Änderungen an gut geschriebenem Code vornehmen. Aber mit der Zeit wird diese Praxis Sie einholen.
Wenn Sie sich den Code ansehen und ihn nicht verstehen, ist es jetzt an der Zeit, ihn herauszufinden und zu dokumentieren. Andernfalls muss jeder andere Programmierer es herausfinden, wenn sie Änderungen vornehmen müssen. Besser, es einmal zu tun, es richtig zu machen und Zeit zu sparen & Ärger für alle in der Zukunft.

3

Sobald Sie Legacy-Code in eine doppelte Schutzdecke des Testens (gute Komponententests UND gute System-/Integrations-/Regressionstests, mit exzellenter Abdeckung von jeder der beiden Schichten) gewickelt, Vertrauen auf Tests, um Missverständnisse zu fangen ist ein wirksamer kurzfristiger taktischer Ansatz. Dies ist ein Teil dessen, was das Hinzufügen von Tests zu einer älteren Codebasis zu einer High-ROI-Strategie macht: Sie können dringende Fehlerbehebungen vornehmen oder schnell dringende Funktionen schneller hinzufügen, indem Sie vernünftiges Vertrauen in die Korrektheit von Änderungen ohne gründliches Verständnis der Feinheiten des bestehenden Codes.

Wie jedoch andere Antworten angedeutet, akkumulieren solche Änderungen technische Schulden; Wie bei jeder anderen Schuld, je früher Sie es auszahlen, desto besser werden Sie auf lange Sicht sein.In diesem Fall geht es beim "Auszahlen" nicht nur um die Dokumentation der Interna, sondern oft um eine Refactoring der Codebasis für Klarheit und Formbarkeit - wirklich gute Tests werden Ihnen dabei helfen, solche Refactorings ebenso vertrauensvoll zu machen tun für Bugfixes und Funktionserweiterungen des Legacy-Codes.

+0

+1 für die technische Schulden – ojblass

+0

+1 mehr für "technische Schulden". Es ist höchste Zeit, dass wir unsere eigenen Schlagworte (vor allem solche mit echter Bedeutung) geprägt haben –

0

Ständig!

0

Sie möchten, dass Ihr Code aus kleinen Teilen besteht, die einzeln getestet und verstanden werden können.

Jedes kleine Stück sollte eine Sache tun und es gut machen, ob das Stück eine Funktion ist, und Methode oder eine Klasse.

Sie wollen größere Stücke von Funktionalität aus diesen kleinen Stücken, so komponieren können, dass jede Zusammensetzung, egal wie komplex intern, einfach bleibt auf der Ebene der Abstraktion dieser Funktionalität.

Mit anderen Worten, selbst auf der hohen Ebene sollten wir noch in der Lage sein, komplexe Interna in einfachen externen Systemen zu beschreiben.

Das ist, was Andrew Koenig meint, wenn er sagt "Abstraktion ist selektive Ignoranz". Durch absichtlich Aufgeben Wissen von wie etwas wmay intern arbeiten, können wir betrachten nicht wie es funktioniert, aber was es tut.

Lassen Sie uns ein kurzes Beispiel geben. Am oberen Ende könnten wir sagen, "diese Klasse findet das kleinste int in einer Datenstruktur". Das sagt uns, was es tut, nicht wie es tut, und auf dieser hohen Ebene der Abstraktion, das ist alles, was uns interessiert.

Wir haben etwas, das etwas tut, und seine modulare, können wir es mit etwas anderes zu ersetzen, funktioniert das elbe, egal wie tut es. Das hat eine öffentliche Schnittstelle.

Jetzt auf einer niedrigeren Ebene, kann es sein, dass wie dies funktioniert ist, dass es intern ist ein Heap oder eine Warteschlange oder was auch immer.

Und diese Dinge können in Bezug auf Bäume oder selbstausgleichende Bäume oder sogar (suboptimal) eine verkettete Liste implementiert werden. Eine verkettete Liste wäre eine suboptimale Implementierung, aber solange sie das Gleiche tun würde, würden wir nicht wirklich caféen, denn wenn die Suboptimalität genug zurückkommt, um unser Programm zu verlangsamen, könnten wir es für eine bessere Implementierung auslagern mit der gleichen Schnittstelle.

Und diese Dinge sind in Bezug auf Baum Traversal implementiert (Pre-Order: immer in der Reihenfolge links, Eltern, rechts gehen). Und diese Dinge werden im Hinblick auf einfache Operationen auf Knoten implementiert.

Und hier ist der wichtige Teil: weil die Rest von out App keine Abhängigkeit von den Einbauten oder Nebenwirkungen dieses Moduls hat, die Swap aus einer schlechteren Implementierung für eine bessere ändert keines unserer anderen Code, es beschleunigt die Dinge insgesamt.

Jede Schicht kommuniziert nur mit den Schichten unmittelbar darüber und darunter, so dass jede Schicht ersetzt werden kann. Optisch sieht es wie Kreise in Kreisen innerhalb von Kreisen aus, nicht wie die Überlappung eines Venn-Diagramms.

Wenn Sie sich auf Intuition verlassen müssen, deutet das darauf hin, dass Ihr Code Nebeneffekte hat oder dass er übermäßig breite Schnittstellen zu anderen Modulen hat, oder anstelle von Schnittstellen überhaupt, anstatt aufgebauter Code zu sein von in sich geschlossenen, sich nicht überschneidenden Modulen, haben Sie Überschneidungen und Überschneidungen und fragilen Code. Dass du es nicht in Stücke zerlegt hast, die einfach genug sind, um es zu verstehen.

(Mist, es ist spät, und ich fürchte, dass ich diese Erklärung aufgeschlüsselt hätte besser. Ich komme wieder diese zu bearbeiten.)

3

Es hat sich einmal in eine Weile mit mir passiert. Ich möchte jedoch einen Punkt hervorheben, den eine andere Person in ihrem Kommentar erwähnt hat.

  • Welche Teile Sie auch verstehen, versuchen Sie es zu dokumentieren. Sie können sich selbst und andere viel Zeit sparen, wenn Sie das nächste Mal eine andere Änderung vornehmen.

Und für meine zwei Cent wert ...

  • Sie haben erwähnt, dass Sie ‚Test‘ Ihre Arbeit gegen den bisherigen Ergebnissen und vergleichen. Ich habe vor ein paar Jahren einen Typen gelesen, der versucht zu argumentieren, dass die wertvollste Sache, die ein Unternehmen besitzen kann, nicht der Code selbst ist, sondern die Tests (zB: JUnit). Er sagte, dass der Code während des gesamten Lebenszyklus einer Software oft geändert wird - von kleinen Korrekturen und Verbesserungen bis hin zu kompletten Umschreibungen. Mit Reife und Erfahrung verstehe ich, was er jetzt meint und versuche seinen Rat zu verwenden. Mit Testfällen können Sie beweisen, dass Ihre neue Arbeit funktioniert und nichts kaputt macht. Mein Punkt ist ... versuchen Sie, jeden möglichen Test zu speichern und wieder zu verwenden. Manche Programmierer neigen manchmal dazu, diese Tests zu verwerfen. Sie werden später sehr wertvoll werden, wenn andere Programmierer Änderungen vornehmen.

Glückliche Code ändern,

Jeach!

0

Nein, ich nie dies tun. Ich erwarte, dass mein Code zu 100% logisch und frei von Fehlern ist, und er wird von anderen Menschen noch jahrelang gelesen werden. Das gesamte Konzept, den Kontext meines Codes nicht vollständig zu verstehen, scheint gefährlich zu sein. Und lesen Code sollte der schnellste Weg sein, um den genauen Betrieb des Systems zu bestimmen. Wenn dies nicht der Fall ist, würde ich vorschlagen, dass etwas mit der Qualität des Codes nicht stimmt.

Während ich lese, lerne ich auch. Ich denke, dass es ein wichtiger Teil meiner professionellen Standards ist, neugierig zu sein auf das System, an dem ich arbeite. Mit dieser Neugierde kommt die Fähigkeit, das System zu entwickeln und zu verbessern. Wenn ich das nicht könnte, denke ich, dass die Entwicklung wirklich schnell langweilig wird.

0

Wenn Sie eine Methode ändern, sollten Sie sie gründlich testen, einschließlich der Methoden, die diese Methode aufrufen.

Verwandte Themen