Tausende von Fehlern!

Ich wurde vor kurzem einem neuen Projekt zugewiesen. Nun, eigentlich ein altes Projekt, geschrieben in klassischem ASP. Jetzt wird eine neue Version der Anwendung in der neuesten Version von ASP.NET geschrieben, es wird jedoch nicht erwartet, dass es sich in Kürze um RTM handelt (voraussichtliches Veröffentlichungsdatum ist Januar 2017). Ich muss daher einige Wartungsarbeiten an der alten Anwendung durchführen, bis dies möglich ist verworfen.
Außerdem habe ich das Gefühl, dass nicht alle Kunden sofort auf das neue Programm umstellen werden, sodass diese Version wahrscheinlich noch eine Weile verfügbar sein wird.

Und das Problem ist, dass es voller Fehler ist. Teile davon stammen aus dem vorigen Jahrhundert, als es noch keine Webstandards gab, und der Quirks-Modus stört mich nicht wirklich, widthund heightAttribute anstelle von CSS, Tabellen, die für Layouts, Framesets usw. verwendet werden, aber oh, all diese Fehler! width="20px"überall onchange="javascript:...", und an jenen orten, an denen sie css benutzen style="width:20"und style="width=20px"alltäglich sind. Ganz zu schweigen von vielen Zeilen, in denen es Widersprüche widthund styleAttribute gibt. Usw.
Infolgedessen läuft die Webanwendung nur unter IE und nur im Kompatibilitätsmodus. Es ist klar, dass die Entwickler niemals die Gültigkeit von Code untersucht haben, nur wenn das Ergebnis so aussieht, wie es eigentlich aussehen sollte.

Und ich weiß nicht, wie ich damit umgehen soll. Ich finde es unmöglich, die Augen vor diesen Fehlern zu verschließen, während ich im Code nach anderen Fehlern suche.
Ich kann natürlich global suchen und ersetzen, um die meisten Probleme aus dem Weg zu räumen, aber das würde bedeuten, dass mein erstes Commit aus Tausenden geänderter ASP-Dateien besteht. Kann ich das machen?

Es hört sich so an, als würden Sie mehrere Dinge mit dem Begriff "Fehler" verwechseln.

• Legacy-HTML-Attribute
• Codierungsstil
• Codierungsfehler, die keine Fehler verursachen
• nicht gemeldete Bugs
• Fehler, die jetzt Features sind
• gemeldete Bugs
• gemeldete Fehler, die Sie beheben sollen

Auf einer Legacy-App, die ersetzt werden soll, sollte nur eine dieser Arten von Fehlern Sie betreffen. Der Letzte.

Ich würde so weit gehen zu sagen, dass Sie nicht einmal andere Dinge an einer Funktion, die Sie zur Fehlerbehebung verwenden, überarbeiten sollten, hauptsächlich aufgrund von:

• Fehler, die jetzt Features sind

Sie können dem Code entnehmen, wie er möglicherweise funktionieren sollte, aber noch nie funktioniert hat, aber alle Benutzer haben sich in den letzten 10 Jahren mit dem unbestimmt breiten Element verstanden, und sie werden sich nicht dafür bedanken, dass Sie ihn behoben haben.

Wenn Sie Ihr zynisches JFDI auf Vordermann bringen, werden Sie in der Lage sein, die Fehler schnell zu beheben, und das Team der neuen Version wird nicht in der Lage sein, mit den Funktionen der alten Versionen Schritt zu halten.

Dies wird Ihnen ein ironisches Lächeln schenken, wenn Sie Kunden einen Chrome-Plugin-IE6-Emulator empfehlen, damit sie die von ihnen geliebte Laufschrift-Funktion weiterhin nutzen können

Was Sie fragen, ist keine technische Frage, und niemand hier kann sie beantworten.

Sie arbeiten im Wartungsmodus an einer Software und stellen eine veraltete Technologie sowie eine große Anzahl von Unzulänglichkeiten und Inkonsistenzen fest. Sie fragen, was zu tun ist. Sollten Sie sich zum Beispiel mehr Mühe geben, es browserübergreifend kompatibel zu machen? Sollten Sie es an moderne Standards anpassen? Sollten Sie syntaktische Inkonsistenzen in der App beheben? Die Sache ist, das sind Geschäftsentscheidungen . Sie sollten Ihren Manager oder Produktbesitzer fragen, welche Probleme Sie lösen sollen und welche Prioritäten sie haben. Da bereits ein Projekt zum Umschreiben der App läuft, sind dem Management die aufgetretenen Probleme höchstwahrscheinlich bereits bekannt.

Wenn die App in wenigen Monaten vollständig ersetzt wird, ist dies wahrscheinlich möchten nur, dass Sie bestimmte kritische Probleme beheben und den Rest des Chaos in Ruhe lassen. Aber wir wissen es nicht.

Sie fragen, ob Sie einen umfassenden Such- und Ersetzungsvorgang in der Codebasis durchführen und dabei Tausende von Dateien ändern können. Natürlich kannst du. Die Frage ist, ob Sie sollten . Solche umfassenden Änderungen erfordern wahrscheinlich umfangreiche Tests, um sicherzustellen, dass nichts kaputt geht. Auch hier ist es eine Geschäftsentscheidung, wenn der Nutzen die Kosten in Bezug auf Zeit und Risiko überwiegt.

Wenn die Anwendung in 18 bis 24 Wochen ausgetauscht wird (zuzüglich der zu erwartenden Verzögerungen bei den oben genannten Schätzungen für die Dauer von 6 bis 8 Wochen), müssen Sie sich wirklich fragen, welchen Mehrwert Sie dem Unternehmen hinzufügen, indem Sie noch viel Arbeit investieren die alte Version.

Klar, wenn Sie einige Jahre lang nicht mehr mit der Unterstützung der Anwendung fertig sind, kann es sich auf lange Sicht lohnen, die technischen Schulden loszuwerden. Aber wenn sowieso alles weggeworfen wird, warum dann die Mühe machen? Fügen Sie einfach eine weitere Hackish-Korrektur hinzu, um Probleme zu beheben, die Sie nicht erwarten können, bis die neue Version veröffentlicht wird, und nennen Sie es einen Tag später.

Möglicherweise fragen Sie sich auch, was Sie für die Anwendung in der noch verbleibenden Zeit tun können . Wenn Sie jetzt wirklich langweilen und einfach besser haben nichts mit Ihrer Zeit zu tun Sie könnte es eine große Überholung geben und alle die Stil Probleme entfernen Sie erwähnt haben , aber es ist sehr wahrscheinlich , dass dies auf den ersten Pause mehr Dinge , als es beheben . Sie könnten in der Lage sein, diese neuen Probleme zu beseitigen, wenn Sie genug Zeit haben, aber Sie haben diese Zeit nicht.

Gründe, keine großen Änderungen vorzunehmen:

Erstens: Der Code verschwindet in ein paar Monaten. Wäre es die Zeit des Unternehmens wirklich wert, 5 Monate damit zu verbringen, ein System zu reparieren, das dann 1 Monat später weggeworfen wird? Vorsichtsmaßnahme: Systeme gehen selten verloren, wenn geplant ist, dass sie verloren gehen. Das Ersatzsystem kommt fast immer zu spät, es gibt Benutzer, die aus irgendeinem Grund kein Upgrade durchführen können usw. Dies ist jedoch ein komplexes Problem.

Zweitens: Wenn Sie viele Änderungen vornehmen, insbesondere das Suchen und Ersetzen in großen Mengen, führen Sie Fehler ein. Nicht Sie könnten Fehler einführen: Sie werden. Angenommen, Sie haben einen S & R durchgeführt und "width = 200" in "width: 200px" geändert. Befindet sich auf Ihren ASP-Seiten C # - oder VB-Code? Denn wenn Sie eine Variable mit dem Namen "width" hatten, die Sie auf 200 gesetzt haben, haben Sie sie einfach gebrochen. (Oder haben Sie im Übrigen darüber nachgedacht, S & R auf ASP-Seiten zu beschränken?) Oder wenn Sie "width: 200" in "width: 200px" geändert haben, was passiert, wenn sich im Code eine Stelle mit der Aufschrift "width: 200mm" befindet "? Jetzt heißt es "Breite: 200pxmm". Okay, nehmen wir an, Sie haben daran gedacht. Was ist, wenn es irgendwo eine ungültige Breitenspezifikation gibt, die natürlich ignoriert wird, und die jetzt recht gut angelegt ist? Du reparierst" die breite und es legt sich jetzt mit 200px an ... und das display ist durcheinander, weil 200px in der tat die falsche breite ist und es nur funktioniert hat weil dieser wert ignoriert wurde? Massen-S & Rs sind sehr gefährlich, weil Sie mit ziemlicher Sicherheit nicht jeden Ort studieren, den Sie ändern. Sie wissen wahrscheinlich nicht einmal, was Sie testen sollen.

Drei: Code, der "offensichtlich" falsch ist, kann tatsächlich das sein, was der Benutzer will. Ich habe viele Anforderungsspezifikationen gesehen, die offensichtlich falsches und verrücktes Verhalten verlangen ... und dann gehe ich zurück zu den Benutzern und frage, was sie WIRKLICH wollen, und es stellt sich heraus, dass sie dieses verrückte Verhalten wirklich wollen, denn das ist es wie ihr Geschäft funktioniert oder behördliche Vorschriften es verlangen oder was auch immer.

Auch wenn das Verhalten wirklich falsch ist, haben Benutzer es möglicherweise erwartet und arbeiten routinemäßig daran. Wenn Sie es beheben, können Sie die Problemumgehungen aufheben. Beispiel: Ich arbeite an einem System, in dem wir einen Ort haben, an dem Sie die Daten angeben, ab denen ein Verkauf für die Öffentlichkeit verfügbar ist. Beide Daten waren wirklich die Mitternacht, die an diesem Tag begann. Wenn Sie also "bis zum 30. Juli" sagten, bedeutete dies, dass sie mit dem Ende des Tages, dem 29. Juli, endete, dh eine Minute vor 00:01 Uhr, dem 30. Juli und nicht dem Ende des 30. Juli Einmal habe ich das behoben, aber ich konnte das nur tun, weil es weniger als ein halbes Dutzend Leute gab, die befugt waren, diesen Bildschirm zu verwenden, und ich konnte ihnen einfach sagen, dass ich es behoben hatte. Wenn es Hunderte von Benutzern gegeben hätte und sie alle inzwischen herausgefunden hätten, dass Sie wirklich einen Tag nach dem Durchgangsdatum angeben müssten, dann wäre mein "Fixing"

Ich kann natürlich global suchen und ersetzen, um die meisten Probleme aus dem Weg zu räumen, aber das würde bedeuten, dass mein erstes Commit aus Tausenden geänderter ASP-Dateien besteht. Kann ich das machen?

Ich verstehe nicht warum nicht. Ein Commit sollte konzeptionell eine Sache sein, aber ich sehe keinen Grund, warum ein globales Suchen und Ersetzen von style="width=20"bis style="width: 20px"konzeptionell nicht als "eine Sache" gelten würde. Und wenn es Ihnen helfen würde, besser zu schlafen, sparen Sie es, abgelenkt zu werden, wenn Sie andere Dinge reparieren und nichts vermasseln , warum nicht?

Ihr Problem besteht darin , Prioritäten zu setzen : Welche der Probleme sind Showstopper (in der Produktion)? Welches sind tickende Zeitbomben? Und was kann eine Weile länger bleiben (weil es funktioniert und das schon seit Jahren, auch irgendwie)?

Was ich in Ihrer Situation tun würde, wäre, Listen von Problemklassen zu erstellen , die ich mir gerne ansehen würde. Ersetzen style="width=(\d+)"durch style="width: \1px"(was wahrscheinlich durch ein globales Suchen / Ersetzen mit Regexp behoben werden kann - sorry, wenn meins nicht 100% ist) wäre eine Klasse, und wenn es nur ein einziges Vorkommen gibt, sollte es so sein. Für jede Kategorieliste eine Priorität (wie dringend ist dies zu tun) und eine Schätzung der Arbeit (wie lange wird es dauern, diese Kategorie zu tun).

Ihre Wartungsaufgaben werden ebenfalls in dieser Liste aufgeführt. Jetzt wenden Sie ein gewisses Maß an Management an, auch wenn nur Sie selbst, und Sie haben ein Tool, das Sie verwenden können, wenn Sie Zeit haben und nichts zu tun haben oder wenn Sie mit Ihrem Manager über die zu erledigende Arbeit verhandeln müssen (oder eine Anfrage stellen müssen) Zeit, um sich auf etwas einzulassen, dessen er sich vielleicht nicht bewusst ist). (Diese Art von Proaktivität kann Ihnen dabei helfen, auf Werbeaktionen aufmerksam zu werden, wenn dies richtig gemacht wird.)

Ich vermute, Sie programmieren gern, weil Sie zu einem gewissen Grad eine etwas perfektionistische Persönlichkeit haben. ABER in einem kommerziellen Umfeld müssen Sie erkennen, dass Perfekt der Feind des Guten ist (und Guten bringt Geld ein, Perfekt bringt möglicherweise nicht unbedingt spürbar mehr für eine ganze Menge Arbeit ein). Zuerst tun, was gebraucht wird, dann tun, was schön ist. Ja, das könnte Ihrem Getreide kein Ende setzen. Grinse und ertrage es und lass dir vielleicht ein Hobby machen, um deinen Perfektionismus zu üben und dich gesund zu halten ;-)