Methoden zum Debuggen von Code (Alptraumsituation)

Ich werde häufig mit dem Debuggen einer Anwendung in meinem Job beauftragt. Es ist eine BI-Anwendung, die wir für Unternehmen bereitstellen, einschließlich einer Testumgebung und einer Produktionsumgebung. Ich frage mich, ob es Apps / Tools / Methoden gibt, die die Leute basierend auf diesen Einschränkungen vorschlagen können:

1. Der Debugger kann nicht auf Client-Sites oder lokal verwendet werden, da die Software von benutzerdefinierten Drittanbieteranwendungen abhängt, für die wir keine Testumgebungen haben. (BEARBEITEN: um fair zu sein, ist es in einigen Fällen möglich, lokal zu debuggen. Wenn wir nur den Kerncode verwenden. Ein Großteil des problematischen Codes befindet sich in einer DLL, die die Kommunikation mit Drittanbietern einschließt: Sockets, Prozesspipes, Seifenanrufe, Benutzerdefinierte Logik, die das Verhalten des Kerncodes ändert. In der Regel schreiben wir während einer Implementierung oder Erweiterung für einen Client neuen Code in diesen Bereich.)

2. In unseren Apps erfolgt praktisch keine Protokollierung. Es gibt keine Komponententests.

3. Die Versionskontrolle verfügt nur über eine Version der vollständigen Lösung (unter Verwendung von Source Safe 2005). Es ist also nicht möglich, eine frühere Version der gesamten Lösung zu erhalten, sondern nur einzelne Dateien. (Es sei denn, jemand kennt sich damit aus).

4. Kann nicht lokal reproduziert werden, kann häufig nicht in der Testumgebung reproduziert werden (hohe Wahrscheinlichkeit, dass Test und Produktion nicht dieselbe Version sind).

5. Es besteht eine hohe Wahrscheinlichkeit, dass sich die vom Client verwendete Version von der auf source safe unterscheidet. Dies liegt daran, dass einzelne Dateien aktualisiert werden, die eine benutzerdefinierte Logik für diesen bestimmten Client enthalten. Oft geschieht eine Aktualisierung einer Binärdatei, die Änderungen an mehreren anderen Binärdateien erfordert. Wenn jedoch ein Commit durchgeführt wird, hat niemand Aufzeichnungen oder Kenntnisse darüber. Ein etwas häufiger Fehler, den ich sehe, ist, dass die Funktion / Methode nicht gefunden wurde oder dass in einer Client-Umgebung zu viele / zu wenige Parameter angegeben wurden.

6. Dies ist eine .net VB-Lösung

7. Kann keine Software auf Client-Sites installieren, kann aber lokal

8. Unsere Anwendung ist extrem anpassbar, aber leider ist die Anpassungslogik über alle Klassen und Dateien verteilt, vom Front-End bis zur Datenschicht, einschließlich kundenspezifischer Änderungen an der Datenbank auf Client-Basis.

9. Der Code enthält praktisch keine Kommentare. Es gibt keine Dokumentation zur Architektur. Keine Dokumentation über die API. Das einzige, was wir haben, sind Hunderte von E-Mail-Ketten, die etwas erklären, was los ist. Die einzigen Leute, die den Code kennen, sind diejenigen, die ihn ursprünglich geschrieben haben, aber sie sind nicht länger Entwickler, so dass sie sich nicht so sehr darauf einlassen.

Und bevor du es sagst ... ja, ich weiß; Ich will mich auch erschießen. Es hilft nicht, dass es Spaghetti-Code, Hunderte von Compiler-Warnungen und einen kaputten Polymorphismus gibt, der WIRKLICH behoben werden sollte, aber ich kann nicht mitreden.

Die häufigsten Fehler, auf die ich stoße, sind Nullreferenzfehler, ungültige Umwandlungen und fehlende Funktionen / Funktionssignaturinkongruenzen. Manchmal habe ich Glück und die Ereignisanzeige protokolliert die Klassen-, Methoden- und Ausnahmemeldung. Es ist nicht das hilfreichste, aber es ist immer noch etwas. Das Schlimmste sind die Fehler, die keine Spur haben, keine Wiederholungsschritte außer einem Screenshot und allgemeine Fehlermeldungen wie die oben genannten. Manchmal ist es nicht möglich herauszufinden, warum sie aufgetreten sind, nur um zu beten, dass die Umgebung nicht richtig konfiguriert ist und dass sie später verschwindet.

Ich weiß, das kommt ein bisschen scherzhaft rüber, und bis zu einem gewissen Grad ist es das auch. Aber ich bin verzweifelt nach Optionen. Gibt es andere Methoden / Tools, die ich verwenden kann?

Die Ratschläge von Robert Harvey sind wahrscheinlich die besten, aber da die Karriereberatung nicht zum Thema gehört, gebe ich die Antwort, die gegeben werden kann:

Sie befinden sich am Fuße eines sehr steilen Berges, der mit Brombeersträuchern, Schlamm und gereizten Bergziegen bewachsen ist. Es gibt keinen einfachen Weg nach oben. Wenn Sie an die Spitze wollen, müssen Sie sich Schritt für Schritt einen gewaltigen Aufstieg erzwingen.

Sie scheinen genau zu wissen, wie die Dinge funktionieren sollten . Wenn Ihnen sonst niemand weiterhilft (auch wenn Sie die Berufsberatung ignorieren), besteht Ihre einzige Wahl darin, diese Probleme selbst zu beheben.

Erstens, für alles, was heilig ist, besorgen Sie sich dieses Zeug in einem echten Versionskontrollsystem. Eigentlich alles andere als Source Safe, der als stinkender Müllhaufen bekannt ist. gitist kostenlos und kann relativ einfach eingerichtet werden. Sie können Probleme mit der fehlenden Versionskontrolle in der Vergangenheit nicht beheben, aber zumindest verhindern, dass das Problem in der Zukunft weiter besteht.

Schauen Sie sich als Nächstes die Protokollierung an. Suchen oder schreiben Sie im schlimmsten Fall ein Protokollierungssystem, und verwenden Sie es. Verwenden Sie eine, die auch auf den Client-Sites verwendet werden kann. Wenn also etwas schief geht, haben Sie zumindest etwas.

Und schreiben Sie Tests, zumindest für neue Änderungen, die Sie vornehmen.

Es gibt keine Zuckerbeschichtung: Es gibt hier keine Antwort, die nicht viel Arbeit erfordert oder dies als eine Frage der Karriere betrachtet.

1) Debugger kann nicht auf Client-Site verwendet werden ...

Das ist völlig normal.

... oder vor Ort

Das ist ein Problem.

2) In unseren Apps erfolgt praktisch keine Protokollierung.

Die Protokollierung ist das Produktions-Debugging.

Es gibt keine Komponententests.

Ach je. Alles zu gemein.

3) Versionskontrolle hat nur 1 Version der vollständigen Lösung

Dann verwenden Sie die Versionskontrolle nicht.

4) Kann nicht lokal reproduziert werden, kann häufig nicht in der Testumgebung reproduziert werden (hohe Wahrscheinlichkeit, dass Test und Produktion nicht dieselbe Version sind).

Daher werden die Fehler nur in der implementierten Clientumgebung angezeigt.

In diesem Fall müssen Sie disgnostic Protokollierung in dem Anwendungscode eingebettet , dass (a) Fallen und [vollständig] Aufzeichnungen [fatal] Fehler und (b) können „gewählt“ auf Nachfrage zusätzliche, kontinuierliche Diagnostik zu produzieren, sind nützlich in Problem (e) aufspüren.

5) Es besteht eine hohe Wahrscheinlichkeit, dass sich die vom Client verwendete Version von der auf source safe unterscheidet.

Auch hier verwenden Sie die Versionskontrolle nicht zu Ihrem Vorteil.

8) Unsere Anwendung ist extrem anpassbar

Das ist ziemlich typisch.

Die standortspezifischen Unterschiede sollten über die Versionskontrolle "Verzweigung" verwaltet werden.

9) Der Code enthält praktisch keine Kommentare.

Auch das ist nur allzu häufig, weil Entwickler "selbstdokumentierenden" Code schreiben, nicht wahr?
Oder zumindest Code, den sie an dem Tag verstehen, an dem sie ihn schreiben.

Es gibt keine Dokumentation zur Architektur.

Ach je.

Keine Dokumentation über die API.

Oh je, oh je.

Und bevor du es sagst ... ja, ich weiß; Ich will mich auch erschießen.

Nein; Sie wollen die Leute erschießen, die all dieses Zeug geschrieben haben, ein undokumentiertes, nicht zu wartendes Durcheinander geschaffen haben und dann zu neuen Weiden übergegangen sind, wobei das unbefangene Durcheinander hinter ihnen zurückgelassen wurde.

Die häufigsten Fehler, auf die ich stoße, sind Nullreferenzfehler, ungültige Umwandlungen und fehlende Funktionen / Funktionssignaturinkongruenzen.

Nullverweise und ungültige Umwandlungen sind Laufzeitfehler. Bis zu einem gewissen Grad sollten Sie sie erwarten, und die Tatsache, dass Sie sie erhalten, deutet häufig auf einen Mangel an defensiver Programmierung (oder einen Überschuss an Optimismus) durch die ursprünglichen Autoren hin.

Nicht übereinstimmende Funktionssignaturen sollten zu einem fehlerhaften Build führen . diese sollten "kaputte Builds" verursachen und es niemals aus der Tür schaffen!

Beginnen Sie mit der Protokollierung. Dies wird den größten Einfluss haben. Implementieren Sie ein Protokollierungsframework wie Log4Net oder ähnliches in die Codebasis. Starten Sie die Protokollierung der Code-Funktion.

Das Debuggen sollte lokal möglich sein. Wenn nicht, arbeiten Sie daran, die Symboldateien (PDBs) abzurufen, damit Sie in DLLs von Drittanbietern debuggen können, um ein vollständiges Bild der auftretenden Probleme zu erhalten. Tools wie WINDBG können erkennen, welche DLLs problematisch sind, wenn das System abstürzt. Jeder Server kann so konfiguriert werden, dass bei einem Absturz ein Speicherauszug erstellt wird. Es ist im Grunde genommen eine Momentaufnahme dessen, was vor sich ging, als das Problem auftrat. Man kann die Müllkippen vor Ort untersuchen, um Hinweise darauf zu finden, was passiert ist. Wenn das Debuggen nicht möglich ist, arbeiten Sie daran, dies zu ermöglichen. Dokumentieren Sie die zum Debuggen erforderlichen Schritte. Manchmal ist auf komplexen Systemen eine Menge Setup erforderlich, um ein vollständiges Debugging durchzuführen.

Fehlerverfolgung ... Wenn Sie keine verwenden, verwenden Sie eine. Dies geht Hand in Hand mit einem ordnungsgemäßen Versionskontrollsystem. Beginnen Sie grundsätzlich mit der Verfolgung von Fehlern und Überarbeitungen Ihres Codes. Beginnen Sie mit dem Aufbau einer Systemhistorie.

Statische Code-Analyse durchführen. Investieren Sie in ein Tool wie ReSharper. Es wird schnell auf alle möglichen Nullreferenzausnahmen und andere schlechte Codierungspraktiken hingewiesen. Es kann helfen, den Code mit nur wenigen Klicks in eine bessere Form zu bringen und mühsame Elemente wie Code-Formatierung, Benennung von Variablen usw. zu automatisieren.

Refactor- und Unit-Tests. Ich gehe davon aus, dass wahrscheinlich der größte Teil des geschriebenen Codes nicht sehr testbar ist, also würde ich nicht versuchen, Tests dafür hinzuzufügen. Beliebiger neuer Code, erstellen Sie ein Testprojekt und schreiben Sie Tests, sowohl für die Einheit als auch für die Integration. Wenn die Komponententests fehlschlagen, schlagen Sie den Build fehl. Wenn Sie also überarbeiten, sollten Tests durchgeführt werden. Eine Sache bei Tests ist, dass man einen Test schreiben kann, um eine beliebige Methode aufzurufen und in dieser Methode zu debuggen, ohne die gesamte Anwendung oder Codebasis zu laden. Dies ist hilfreich, um Probleme zu beheben.

Dokumentieren Sie jedes Stammeswissen nach Bedarf. Der Code sollte sich selbst dokumentieren, so dass Kommentare spärlich sind, aber viele Systeme haben "ungewöhnliche" Vorgehensweisen, weisen Sie auf die in einem codierenden WIKI oder einer anderen Art von informellem Repository enthaltenen hin. Überlegen Sie auch, welche Codierungsstandards und -praktiken verwendet werden sollen. Erzwingen Sie diese Standards über ein Toolset wie Resharper. Da der Großteil des Codes wahrscheinlich keinen Standards und Richtlinien entspricht, implementieren Sie die Standards für neuen Code, der geschrieben wurde.

Seit Ihrem neuen würde ich dies wie eine Dienstreise behandeln. 6 Monate bis 2 Jahre, und dann die Wahl treffen, um zu bleiben oder weiterzuziehen. Nehmen Sie sich die Befriedigung, etwas besser zu werden als am Vortag.

Erstens alle oben genannten ... dito.

Einige Heuristiken:

• Verwenden Sie die Quellcodeverwaltung auf Ihrem Entwicklungscomputer. Es ist das Beste, was ich je gemacht habe. Es ist kein Ersatz für die Versionskontrolle des Projekts, die wir haben. Es ist ein Tool, mit dem Sie furchtlos experimentieren, hacken, gleichzeitig und unabhängig arbeiten können. Ich kann besser mit der Versionskontrolle umgehen, weil ich die Freiheit habe, mutig zu sein, Fehler zu machen und zu lernen.
  • Was ist der Unterschied zwischen Git und Mecurial?
  • Git ist Mcgyver, Mecurial ist James Bond
• Wenn Sie Kommentare hinzufügen, priorisieren Sie die Elemente der öffentlichen Benutzeroberfläche, um die Vorteile von Intellisense zu nutzen. Tun Sie dies, während Sie während Ihrer Debug-Abenteuer entschlüsseln.
• Seien Sie beharrlich bei kleineren Umbauten. Früher oder später werden Sie für ein bestimmtes Stück Code eine kritische Masse erreichen, die große Umgestaltungen wie das DRYEN von redundantem Code über Klassen hinweg ermöglicht.
• Mischen Sie Code-Neuformatierung und tatsächliche Änderungen nicht in denselben Versionskontroll-Commits.
• SOLIDE Prinzipien
  • Ignorieren Sie niemals die einzelne Verantwortung. Gut gemacht, das ist der Weg zum Versprechen objektorientierter; MEINER BESCHEIDENEN MEINUNG NACH.
  • Ignoriere immer Open / Closed.
  • Wir reden hier nicht über neuen Code.
  • Das Erstellen von Schnittstellen ohne zielgerichtetes Design erschwert die Wartung.
• Refactoring
  • Es gibt eine Methodik . Kaufen Sie das Buch.
  • Refactoring: Verbessern des Designs von vorhandenem Code
• Einige Codedateien müssen vollständig neu formatiert, Variablen umbenannt usw. werden, bevor sie überhaupt das Debuggen versuchen. Scheuen Sie sich nicht, das Refactor-Menü von Visual Studio ohne Unit-Tests zu verwenden.
• Die einzige Dokumentation, die nicht verlegt werden kann, befindet sich in den Codedateien.
• Wenn Sie die Versionskontrolle erhalten, denken Sie über den VC-Plan nach. Und dokumentiere es! Und entwickeln Sie eine Namenskonvention für Branchen, Tags, die wichtige Softwareversionen und Meilensteine ​​hervorheben.
• Verwenden Sie eine gute Ausrüstung
  • Holen Sie sich einen Monitor, der sich dreht. Vertikal ist der Weg, um Code schnell zu lesen.
  • Externes Laufwerk für Backups, Tastatur mit den richtigen Tasten , Multifunktionsmaus. Mindestens 1 wirklich gutes USB-Laufwerk. Ich habe sogar meinen eigenen Herman Miller Stuhl .
  • Holen Sie sich sehr gute Vergleichssoftware. Ich bin zufrieden mit Beyond Compare .
• Üben Sie das Rubber Ducky Debugging
• Manchmal ist das Schlimmste, was passieren kann, dass sie dich nicht feuern.

Bearbeiten

Brownfield-Anwendungsentwicklung in .NET

Probieren Sie dieses Buch aus. Ein erstes Cover zum Durchlesen ist wahrscheinlich am besten. Dieses Buch hilft Ihnen dabei, das Gesamtbild, die Möglichkeiten und die Entwicklung strategischer und taktischer Angriffspläne zu überdenken.

Steck es raus

Bleib etwa 1,5 Jahre, wenn du kannst. lang genug, um zu wissen, ob Sie experimentelle Fortschritte machen. Sie werden wissen, ob Sie 4-mal 2 Jahre Erfahrung oder 6 Monate Erfahrung gesammelt haben.

Als "Junior mit 1/2-jähriger Erfahrung" bin ich besorgt, dass ein potenzieller Arbeitgeber dies als vorzeitige Rettung ansieht, weil Sie es nicht hacken konnten. Es ist eine Sache, zu sagen, dass Sie gelernt haben, dass z, y, x, einige Namen haben und ein paar Ärsche treten - aber Sie durften nicht zu Ihren Fähigkeiten beitragen; und ein anderer riskiert einfach, den Job, den Code, das Management usw. zur Erklärung abzulehnen.

Ich bin vielleicht nicht auf dieser Basis, aber meine "besten und schlechtesten Zeiten" waren meine ersten Aufgaben, die buchstäblich nicht zu verwaltender Code waren. Ich hatte einen großartigen Supervisor (alle anderen waren vom Management-In-Breeding-Programm), der mir den Raum gab, einige Schlüsselprogramme neu zu schreiben. Diese Erfahrung war Offenbarung.

Bearbeiten beenden

Ich würde sagen (5) ist diejenige, die Sie zuerst reparieren müssen. Wenn Sie nicht wissen, welcher Code in der Produktion ausgeführt wird, haben Sie keine sichere Möglichkeit, Probleme zu reproduzieren und zu beheben. Dies macht jede andere Änderung, die Sie vornehmen, gefährlich, da dies zu Problemen führen kann, die Sie nicht vorhersehen und nicht reproduzieren können.

Möglicherweise müssen Sie einige Nachforschungen anstellen und möglicherweise ein Reverse Engineering durchführen, um herauszufinden, welche Codeversion (en) und welche Bibliotheken bereitgestellt werden. (Und Sie benötigen ein konsistentes Build- und Bereitstellungssystem, um den gesamten bereitgestellten Code mit der zukünftigen Quellcodeverwaltung in Einklang zu bringen.)

Möglicherweise müssen Sie mehrere Testumgebungen erstellen, um die verschiedenen Bereitstellungen zu replizieren. (Die einfachste Lösung ist natürlich, einen neuen sauberen Build zu erstellen und ihn überall konsistent bereitzustellen, aber es hört sich so an, als wäre dies nicht möglich?)

Erst wenn Sie die genauen bereitgestellten Versionen kennen und über entsprechende Testumgebungen verfügen, sollten Sie versuchen, den Code zu reparieren / verbessern.

Ihre nächste Priorität sollte die Konsolidierung auf eine einzige Codebasis sein, die überall bereitgestellt werden kann. Klingt es so, als hätten Sie aufgrund von Anpassungen verschiedene Codeversionen bereitgestellt? Sie sollten zu einer einzigen Version konsolidieren und dann Konfigurationsschalter für die benutzerdefinierte Logik verwenden.

Danach können Sie damit beginnen, die Codebasis sorgfältig zu verbessern, um das Debuggen zu vereinfachen. Das Hinzufügen der Protokollierung ist wahrscheinlich die am wenigsten riskante Verbesserung.

Sie möchten möglicherweise automatisierte Tests hinzufügen, aber Unittests lassen sich häufig nur schwer zu einem Projekt hinzufügen, das ursprünglich nicht zum Testen entwickelt wurde. Stattdessen empfehle ich, mit automatisierten End-to-End-Integrationstests zu beginnen. Diese sind schwieriger einzurichten, erfordern jedoch keine Neugestaltung der Lösung und sind daher weniger riskant.

Abgesehen von den Problemen, die Sie in Ihrem Team haben, besteht die erste Lösung darin, den Code zu debuggen, der mit dem in der Produktion befindlichen Code übereinstimmt. Andernfalls könnten Sie einen Fehler verfolgen, der bereits in dem Code behoben wurde, den Sie in Ihrer "Quellcodeverwaltung" haben. Da dies .NET ist, können Sie die Produktions-Binärdateien leicht "dekompilieren", um den Code mit dem zu vergleichen, was Sie haben. Es ist keine leichte Aufgabe, aber wenn Sie erfolgreich sind, ist dies ein starkes Argument für ein besseres Versionsverwaltungs-Tool, das freigegebene Versionen markieren kann.