Verbesserung wirklich schlechter Systeme

Question

Wie würden Sie ein wirklich schlechtes System verbessern?

Lassen Sie mich erklären, was ich meine, bevor Sie die Erstellung von Unit-Tests und Refactoring empfehlen. Ich könnte diese Techniken anwenden, aber das wäre in diesem Fall sinnlos.

Eigentlich ist das System so kaputt, dass es nicht das tut, was es tun muss.

Zum Beispiel sollte das System zählen, wie viele Nachrichten es versendet. Meistens funktioniert das, aber in manchen Fällen "vergisst" es, den Wert des Nachrichtenzählers zu erhöhen. Das Problem ist, dass so viele andere Module mit ihren eigenen Workarounds auf diesem Zähler aufbauen, dass, wenn ich den Zähler korrigiere, das System als Ganzes schlechter werden würde, als es derzeit ist. Die Lösung könnte darin bestehen, alle Module zu modifizieren und ihre eigenen Korrekturen zu entfernen, aber bei über 150 Modulen würde das so viel Koordination erfordern, dass ich mir das nicht leisten kann.

Schlimmer noch, es gibt einige Probleme, die nicht im System selbst, sondern in den Köpfen der Menschen gelöst werden. Zum Beispiel kann das System nicht mehr als vier zusammenhängende Nachrichten in einer Nachrichtengruppe darstellen. Bei einigen Diensten sind fünf zusammenhängende Meldungen erforderlich. Die Buchhaltungsabteilung weiß um diese Einschränkung und zählt jedes Mal, wenn sie die Nachrichten für diese Dienste zählt, die Nachrichtengruppen und multipliziert sie mit 5/4, um die korrekte Anzahl der Nachrichten zu erhalten. Es gibt absolut keine Dokumentation über diese Abweichungen, und niemand weiß, wie viele solcher Dinge jetzt im System vorhanden sind.

Wie würden Sie also an der Verbesserung dieses Systems arbeiten? Welche Strategie würden Sie verfolgen?

Ein paar zusätzliche Dinge: Ich bin eine Ein-Mann-Armee, die daran arbeitet, so dass es keine akzeptable Antwort ist, genügend Leute einzustellen und das System neu zu entwerfen/umzugestalten. Und in ein paar Wochen oder Monaten sollte ich wirklich sichtbare Fortschritte machen, so dass es auch keine Option ist, das Refactoring in ein paar Jahren selbst durchzuführen.

Einige technische Details: Das System ist in Java und PHP geschrieben, aber ich glaube nicht, dass das wirklich wichtig ist. Es gibt zwei Datenbanken, eine Oracle- und eine PostgreSQL-Datenbank. Neben den bereits erwähnten Mängeln stinkt auch der Code selbst, er ist wirklich schlecht geschrieben und dokumentiert.

Zusätzliche Informationen:

Das Zählerproblem ist kein Synchronisationsproblem. Die Anweisungen counter++ werden in einigen Modulen hinzugefügt, in anderen Modulen jedoch nicht. Eine schnelle und schmutzige Lösung besteht darin, sie dort hinzuzufügen, wo sie fehlen. Die langfristige Lösung besteht darin, sie zu einer Art Aspekt für die Module zu machen, die sie benötigen, so dass es unmöglich ist, sie später zu vergessen. Ich habe keine Probleme damit, solche Dinge zu beheben, aber wenn ich diese Änderung vornehmen würde, würde ich über 10 andere Module zerstören.

Aktualisierung:

Ich habe die Antwort von Greg D. akzeptiert. Auch wenn mir die von Adam Bellaire besser gefällt, würde es mir nicht helfen, zu wissen, was ideal wäre zu wissen. Vielen Dank an alle für die Antworten.

Answer 1

1. Löschen Sie die Brände . Wenn es irgendwelche Probleme von kritischer Priorität gibt, was auch immer das sein mag, müssen Sie sich zuerst um sie kümmern. Hacken Sie es, wenn es sein muss, mit einer stinkenden Codebasis ist das in Ordnung. Sie wissen, dass Sie es in Zukunft verbessern werden. Dies ist Ihre Verkaufstechnik, die sich an denjenigen richtet, dem Sie Bericht erstatten.
2. Pflücken Sie die niedrig hängenden Früchte. Ich gehe davon aus, dass Sie relativ neu in dieser speziellen Software sind und dass Sie mit dieser Aufgabe neu betraut wurden. Finden Sie einige scheinbar einfache Probleme in einem verwandten Teilsystem des Codes, deren Lösung nicht mehr als ein oder zwei Tage pro Stück in Anspruch nehmen sollte, und beheben Sie sie. Dies kann ein Refactoring beinhalten, muss es aber nicht. Das Ziel ist es, sich mit dem System und mit dem Stil des ursprünglichen Autors vertraut zu machen. Es kann sein, dass Sie nicht viel Glück haben (einer der beiden Inkompetenten, die vor mir an meinem System gearbeitet haben, hat seine Kommentare immer mit vier Satzzeichen statt mit einem versehen, wodurch es sehr einfach war, zu unterscheiden, wer das jeweilige Codesegment geschrieben hat), aber Sie werden einen Einblick in die Schwächen des Autors bekommen, so dass Sie wissen, worauf Sie achten müssen. Ausgedehnte, enge Kopplung mit dem globalen Zustand vs. schlechtes Verständnis der Sprachwerkzeuge, zum Beispiel.
3. Setzen Sie sich ein großes Ziel. Wenn Ihre Erfahrung mit meiner übereinstimmt, werden Sie sich immer öfter in einem bestimmten Stück Spaghetti-Code wiederfinden, je öfter Sie den vorherigen Schritt ausführen. Dies ist der erste Knoten, den Sie entwirren müssen. Mit der Erfahrung, die Sie beim Verstehen der Komponente gewonnen haben, und dem Wissen darüber, was der ursprüngliche Autor wahrscheinlich falsch gemacht hat (und worauf Sie daher achten müssen), können Sie damit beginnen, ein besseres Modell für diese Teilmenge des Systems zu entwerfen. Machen Sie sich keine Sorgen, wenn Sie noch einige unordentliche Schnittstellen pflegen müssen, um die Funktionalität aufrechtzuerhalten, gehen Sie einfach Schritt für Schritt vor.

Einschäumen, ausspülen, wiederholen! :)

Wenn Sie Zeit haben, sollten Sie in Erwägung ziehen, Unit-Tests für Ihr neues Modell eine Ebene unterhalb der Schnittstellen mit dem Rest des Systems hinzuzufügen. Gravieren Sie die schlechten Schnittstellen nicht in den Code über Tests, die sie verwenden, Sie werden sie in einer zukünftigen Iteration ändern.

Zu den von Ihnen angesprochenen Themen:

Wenn Sie auf eine Situation stoßen, in der die Benutzer manuell arbeiten, mit den Nutzern sprechen sie zu ändern. Vergewissern Sie sich, dass sie die Änderung akzeptieren, wenn Sie sie anbieten, bevor Sie die Zeit dafür aufwenden. Wenn sie die Änderung nicht wollen, ist es Ihre Aufgabe, das kaputte Verhalten beizubehalten.

Wenn man auf eine fehlerhafte Komponente stößt, die von mehreren anderen Komponenten umgangen wurde, befürworte ich die Technik der parallelen Komponenten. Erstellen Sie einen Zähler, der so funktioniert wie der vorhandene sollte Arbeit. Bieten Sie eine ähnliche (oder, wenn möglich, identische) Schnittstelle an und fügen Sie die neue Komponente in die Codebasis ein. Wenn Sie auf externe Komponenten stoßen, die mit der defekten Komponente arbeiten, versuchen Sie, die alte Komponente durch die neue zu ersetzen. Ähnliche Schnittstellen erleichtern die Portierung des Codes, und die alte Komponente ist noch vorhanden, wenn die neue ausfällt. Entfernen Sie die alte Komponente erst, wenn Sie es können.

Answer 2

Was wird gerade jetzt von Ihnen verlangt? Werden Sie gebeten, Funktionen zu implementieren oder Fehler zu beheben? Weiß man überhaupt, was Sie tun sollen?

Wenn Sie nicht über die Arbeitskräfte, die Zeit oder die Ressourcen verfügen, um das System als Ganzes zu "reparieren", dann können Sie nur Wasser schöpfen. Sie sagen, Sie sollten in der Lage sein, in ein paar Monaten "sichtbare Fortschritte" zu machen. Nun, wenn das System so schlecht ist, wie Sie es beschrieben haben, könnten Sie das System sogar noch verschlimmern. Unter dem Druck, etwas Spürbares zu tun, werden Sie einfach Code hinzufügen und das System noch unübersichtlicher machen.

Irgendwann muss man refaktorisieren. Daran führt kein Weg vorbei. Wenn Sie einen Weg zum Refactoring finden können, der für Ihre Endbenutzer sichtbar ist, das wäre ideal auch wenn es 6-9 Monate oder ein Jahr dauert, anstatt "ein paar Monate". Aber wenn Sie das nicht können, dann müssen Sie eine Entscheidung treffen:

• Refaktorieren Sie, und riskieren Sie, trotz Ihrer Bemühungen als "nichts erreicht" angesehen zu werden
• Refaktorieren Sie nicht, erreichen Sie "sichtbare" Ziele und machen Sie das System noch unübersichtlicher und schwieriger, um es eines Tages zu refaktorieren. (Vielleicht nachdem Sie einen besseren Job gefunden haben und hoffen, dass der nächste Entwickler nie herausfinden kann, wo Sie wohnen).

Welche davon für Sie persönlich am vorteilhaftesten ist, hängt von der Kultur Ihres Unternehmens ab. Werden sie eines Tages beschließen, mehr Entwickler einzustellen oder dieses System vollständig durch ein anderes Produkt zu ersetzen?

Umgekehrt, wenn Ihre Bemühungen, "Dinge zu reparieren", tatsächlich andere Dinge kaputt machen, werden sie dann Verständnis für die Ungeheuerlichkeit aufbringen, die Sie im Alleingang in Angriff nehmen sollen?

Hier gibt es keine einfachen Antworten, tut mir leid. Sie müssen Ihre einzigartige, individuelle Situation beurteilen.

Answer 3

Dies ist ein ganzes Buch, das im Grunde sagen, Unit-Test und Refactor, aber mit mehr praktische Ratschläge, wie man es tun

http://ecx.images-amazon.com/images/I/51RCXGPXQ8L._SL500_AA240_.jpg

http://www.amazon.com/Working-Effectively-Legacy-Robert-Martin/dp/0131177052

Answer 4

Sie öffnen das Verzeichnis, das dieses System enthält, mit dem Windows Explorer. Dann drücken Sie Strg-A und anschließend die Umschalttaste-Entfernen. Das klingt nach einer Verbesserung in Ihrem Fall.

Aber im Ernst: Der Zähler klingt, als hätte er Probleme mit der Thread-Sicherheit. Ich würde eine Sperre um die steigenden Funktionen setzen.

Und was den Rest des Systems betrifft, so können Sie das Unmögliche nicht tun, also versuchen Sie, das Mögliche zu tun. Sie müssen Ihr System von zwei Fronten aus angreifen. Kümmern Sie sich zuerst um die sichtbaren Probleme, damit Sie Fortschritte erzielen können. Gleichzeitig sollten Sie sich um die eher infrastrukturellen Probleme kümmern, damit Sie eine Chance haben, die Sache eines Tages tatsächlich zu beheben.

Viel Glück, und möge die Quelle mit Ihnen sein.

Answer 5

Wählen Sie einen Bereich aus, dessen Überarbeitung mittelschwer sein würde. Erstellen Sie ein Skelett des ursprünglichen Codes, das nur die Methodensignaturen der vorhandenen Methoden enthält; vielleicht verwenden Sie sogar eine Schnittstelle. Dann fangen Sie an zu hacken. Sie können sogar die "neuen" Methoden auf die alten verweisen lassen, bis Sie zu ihnen gelangen.

Dann: Testen, testen, testen. Da es keine Unit-Tests gibt, verwenden Sie vielleicht einfach die guten altmodischen Voice-Activated-Unit-Tests (Leute)? Oder schreiben Sie Ihre eigenen Tests, wie Sie gehen.

Dokumentieren Sie Ihre Fortschritte in einer Art Repository, einschließlich Frustrationen und Fragen, so dass der nächste arme Trottel, der das Projekt bekommt, nicht an der gleichen Stelle wie Sie steht :).

Sobald Sie den ersten Teil erledigt haben, machen Sie mit dem nächsten weiter. Der Schlüssel liegt darin, auf schrittweisen Fortschritten aufzubauen. Deshalb sollten Sie nicht mit dem schwierigsten Teil beginnen, weil Sie sich sonst zu leicht demoralisieren lassen.

Joel hat eine Reihe von Artikeln über Rewriting/Refactoring:

http://www.joelonsoftware.com/articles/fog0000000069.html

http://www.joelonsoftware.com/articles/fog0000000348.html