Verbesserung von wirklich schlechten Systemen
https://stackoverflow.com/questions/192464
-
08-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
Wie würden Sie ein wirklich schlechtes System verbessern?
Lassen Sie mich erklären, was ich meine, bevor Sie empfehlen, Unit -Tests und Refactoring zu erstellen. Ich könnte diese Techniken verwenden, aber das wäre in diesem Fall sinnlos.
Eigentlich ist das System so gebrochen, dass es nicht das tut, was es tun muss.
Zum Beispiel sollte das System zählen, wie viele Nachrichten es gesendet wird. Es funktioniert meistens, aber in einigen Fällen "vergisst" es, den Wert des Nachrichtenzählers zu erhöhen. Das Problem ist, dass so viele andere Module mit ihren eigenen Problemumgehungen auf diesem Zähler aufbauen, dass, wenn ich korrigiere, das System als Ganzes schlechter werden würde als derzeit. Die Lösung könnte darin bestehen, alle Module zu ändern und ihre eigenen Korrekturen zu entfernen, aber mit 150 Modulen, die so viel Koordination erfordern, dass ich sie mir nicht leisten kann.
Schlimmer noch, es gibt einige Probleme, die nicht im System selbst, sondern im Kopf der Menschen angemessen sind. Zum Beispiel kann das System nicht mehr als vier verwandte Nachrichten in einer Nachrichtengruppe darstellen. Einige Dienste würden fünf Nachrichten erfordern, die zusammen gruppiert sind. Die Buchhaltungsabteilung kennt diese Einschränkung und jedes Mal, wenn sie die Nachrichten für diese Dienste zählen, zählen sie die Nachrichtengruppen und multiplizieren Sie sie mit 5/4, um die richtige Anzahl der Nachrichten zu erhalten. Es gibt absolut keine Dokumentation zu diesen Abweichungen und niemand weiß, wie viele solche Dinge im System jetzt vorhanden sind.
Wie würden Sie anfangen, dieses System zu verbessern? Welche Strategie würden Sie folgen?
Ein paar zusätzliche Dinge: Ich bin eine Ein-Men-Arme-Army, die daran arbeitet, daher ist es keine akzeptable Antwort, genügend Männer einzustellen und das System neu zu gestalten/refaktor zu reportoren. Und in ein paar Wochen oder Monaten sollte ich wirklich einen sichtbaren Fortschritt zeigen, daher ist es keine Möglichkeit, das Refactoring in ein paar Jahren zu tun.
Einige technische Details: Das System ist in Java und PHP geschrieben, aber ich denke nicht, dass das wirklich wichtig ist. Es stehen zwei Datenbanken dahinter, ein Orakel und ein PostgreSQL. Neben den vor erwähnten Mängel ist auch der Code selbst riecht, er ist wirklich schlecht geschrieben und dokumentiert.
Zusätzliche Information:
Das Zählerproblem ist kein Synchronisationsproblem. Die Zähler ++ - Anweisungen werden einigen Modulen hinzugefügt und zu einigen anderen Modulen nicht hinzugefügt. Eine schnelle und schmutzige Lösung besteht darin, sie dort hinzuzufügen, wo sie fehlen. Die lange Lösung besteht darin, es zu einem Aspekt für die Module zu machen, die sie brauchen, und es unmöglich macht, 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 10 andere Module durchbrechen.
Aktualisieren:
Ich habe Greg Ds Antwort akzeptiert. Selbst wenn ich Adam Bellaires mehr mag, würde es mir nicht helfen, zu wissen, was ideal wäre. Vielen Dank für die Antworten.
Lösung
- Die Feuer löschen. Wenn es Probleme mit kritischer Priorität gibt, was auch immer sie sind, müssen Sie sie zuerst bewältigen. Hacken Sie es ein, wenn Sie müssen, mit einer stinkenden Codebasis ist es in Ordnung. Sie wissen, dass Sie es in Zukunft verbessern werden. Dies ist Ihre Verkaufstechnik, an die Sie sich anwenden, an wen Sie sich melden.
- Wählen Sie ein paar niedrig hängende Früchte. Ich gehe davon aus, dass Sie in dieser speziellen Software relativ neu sind und dass Sie neu aufgeteilt wurden, um damit umzugehen. Finden Sie einige scheinbar einfache Probleme in einem verwandten Subsystem des Codes, das nicht länger als ein oder zwei Tage dauern sollte, um sie pro Stück zu lösen und zu beheben. Dies kann das Refactoring beinhalten oder nicht. Ziel ist es, sich mit dem System und dem Stil des ursprünglichen Autors vertraut zu machen. Möglicherweise haben Sie nicht wirklich Glück (einer der beiden Inkompetenten, die vor mir an meinem System gearbeitet haben, hat seine Kommentare immer mit vier Interpunktionsmarken anstelle einer Interpunktionsmarke nach dem Fixiert gemacht, was es sehr einfach machte, zu unterscheiden, wer das jeweilige Codesegment geschrieben hat.), Aber Sie werden Einblicke in die Schwächen des Autors entwickeln, damit Sie wissen, worauf Sie achten müssen. Umfangreiche, enge Kopplung mit globalem Zustand im Vergleich zu einem schlechten Verständnis von Sprachwerkzeugen beispielsweise.
- Setzen Sie ein großes Ziel. Wenn Ihre Erfahrung mit meiner Erfahrung mit meinem entspricht, werden Sie sich in einem bestimmten Teil von Spaghetti -Code immer öfter befinden, wenn Sie den vorherigen Schritt ausführen. Dies ist der erste Knoten, den Sie entwirren müssen. Mit der Erfahrung, dass Sie die Komponente und das Wissen darüber verstanden haben, was der ursprüngliche Autor wahrscheinlich falsch gemacht hat (und daher, worauf Sie achten müssen), können Sie sich ein besseres Modell für diese Teilmenge des Systems vorstellen. Machen Sie sich keine Sorgen, wenn Sie immer noch einige unordentliche Schnittstellen beibehalten müssen, um die Funktionalität aufrechtzuerhalten. Machen Sie sie nur einen Schritt nach dem anderen.
Schaume, spülen, wiederholen! :)
Erwägen Sie, mit dem Rest des Systems Unit -Tests für Ihr neues Modell 1 -Stufe unter Ihren Schnittstellen hinzuzufügen. Gravieren Sie die schlechten Schnittstellen nicht in Code über Tests, die sie verwenden. Sie werden sie in einer zukünftigen Iteration ändern.
Ansprechen der jeweiligen Probleme, die Sie erwähnen:
Wenn Sie auf eine Situation stoßen, in der Benutzer manuell arbeiten, arbeiten Sie Sprechen Sie mit den Benutzern über das Ändern. Stellen Sie sicher, dass sie die Änderung akzeptieren, wenn Sie sie zur Verfügung stellen, bevor Sie die Zeit in sie sinken. Wenn sie die Änderung nicht wollen, ist es Ihre Aufgabe, das kaputte Verhalten aufrechtzuerhalten.
Wenn Sie auf eine fehlerhafte Komponente stoßen, die mehrere andere Komponenten herumgearbeitet haben, bin ich für eine parallele Komponenten -Technik. Erstellen Sie einen Zähler, der funktioniert, wie der vorhanden ist sollte Arbeit. Geben Sie eine ähnliche (oder, wenn auch praktische, identische) Schnittstelle an und schieben Sie die neue Komponente in die Codebasis. Wenn Sie externe Komponenten berühren, die um das zerbrochene arbeiten, versuchen Sie, die alte Komponente durch das neue zu ersetzen. Ähnliche Schnittstellen erleichtern die Portierung des Codes, und die alte Komponente ist immer noch zu tun, wenn der neue fehlschlägt. Entfernen Sie die alte Komponente erst, bis Sie können.
Andere Tipps
Was wird von dir gerade gefragt? Werden Sie gebeten, Funktionen zu implementieren oder Fehler zu beheben? Wissen sie überhaupt, was sie tun sollen?
Wenn Sie nicht über die Arbeitskräfte, Zeit oder Ressourcen verfügen, um das System als Ganzes zu "reparieren", können Sie nur noch Kaution Wasser haben. Sie sagen, Sie sollten in ein paar Monaten in der Lage sein, einige "sichtbare Fortschritte" zu erzielen. Nun, da das System so schlecht ist wie Sie beschrieben haben, können Sie das System tatsächlich verschlimmern. Unter dem Druck, etwas Auffälliges zu tun, fügen Sie einfach Code hinzu und machen das System noch verworren.
Sie müssen schließlich refaktor. Es gibt keinen Weg herum. Wenn Sie einen Weg finden können, um den Refactor für Ihre Endbenutzer sichtbar zu sein, ist es sichtbar. Das wäre ideal, auch wenn es 6-9 Monate oder ein Jahr statt "ein paar Monate" dauert. Aber wenn Sie nicht können, dann haben Sie die Wahl zu treffen:
- Refactor und Risiko, trotz Ihrer Bemühungen als "nichts zu erreichen" angesehen werden
- Nicht refaktor, "sichtbare" Ziele erreichen und das System eines Tages mehr verworren und schwieriger zu neu aufzunehmen. (Vielleicht, nachdem Sie einen besseren Job gefunden haben und hoffen, dass der nächste Entwickler mitkommt, kann nie herausfinden, wo Sie leben.)
Welches für Sie persönlich am vorteilhaft ist, hängt von der Kultur Ihres Unternehmens ab. Werden sie eines Tages entscheiden, mehr Entwickler einzustellen oder dieses System vollständig durch ein anderes Produkt zu ersetzen?
Wenn Sie umgekehrt, wenn Ihre Bemühungen, Dinge zu "reparieren", tatsächlich andere Dinge brechen, werden sie sich über die Monstrosität, die Sie im Alleingang angehen, verstehen?
Keine einfachen Antworten hier, sorry. Sie müssen basierend auf Ihrer einzigartigen individuellen Situation bewerten.
Dies ist ein ganzes Buch, das im Grunde genommen Einheitstest und Refaktor mithilfe von praktischeren Ratschlägen dazu sagt, wie es geht
http://ecx.images-amazon.com/images/i/51rcxgpxq8l._sl500_aa240_.jpg
http://www.amazon.com/working-effectivy-legacy-robert-martin/dp/0131177052
Sie öffnen das Verzeichnis, das dieses System mit Windows Explorer enthält. Drücken Sie dann Strg-A und schalten Sie dann die Delete. Das klingt nach einer Verbesserung in Ihrem Fall.
Im Ernst: Dieser Gegensatz klingt so, als hätte er Probleme mit Thread-Sicherheit. Ich würde ein Schloss um die zunehmenden Funktionen legen.
Und in Bezug auf den Rest des Systems können Sie das Unmögliche nicht tun. Versuchen Sie also, das Mögliche zu tun. Sie müssen Ihr System von zwei Fronten angreifen. Kümmere dich zuerst um die sichtbareren problematischeren Probleme, damit Sie Fortschritte zeigen können. Gleichzeitig sollten Sie sich mit den mehr infrastrukturellen Problemen befassen, damit Sie dieses Ding eines Tages tatsächlich beheben können.
Viel Glück und möge die Quelle mit Ihnen sein.
Wählen Sie einen Bereich aus, der mit mittlerer Schwierigkeit zu refaktor ist. Erstellen Sie ein Skelett des ursprünglichen Codes nur mit den Methodensignaturen der vorhandenen; Verwenden Sie vielleicht sogar eine Schnittstelle. Dann fangen Sie an, wegzuhacken. Sie können sogar die "neuen" Methoden auf die alten richten, bis Sie zu ihnen kommen.
Dann testen, testen, testen. Da es keine Unit-Tests gibt, verwenden Sie vielleicht nur gute, altmodische Voice-aktivierte Einheiten-Tests (Menschen)? Oder schreiben Sie Ihre eigenen Tests, während Sie gehen.
Dokumentieren Sie Ihren Fortschritt, wenn Sie in einer Art Repository gehen, einschließlich Frustrationen und Fragen, so dass der nächste arme Schmuck, der dieses Projekt erhält, nicht dort ist :).
Sobald Sie den ersten Teil erledigt haben, fahren Sie mit dem nächsten fort. Der Schlüssel ist, auf inkrementellen Fortschritten aufzubauen. Deshalb sollten Sie nicht mit dem schwierigsten Teil zuerst beginnen. Es wird zu einfach sein, demoralisiert zu werden.
Joel hat ein paar Artikel zum Umschreiben/Refactoring:
Ich arbeite seit fast drei Jahren mit einem Legacy -System mit den gleichen Eigenschaften, und es gibt keine Verknüpfungen, die mir bekannt sind.
Was mich an unserem Legacy -System am meisten stört, ist, dass ich einige Fehler nicht beheben darf, da viele andere Funktionen brechen könnten, wenn ich sie reparieren kann. Dies erfordert hässliche Problemumgehungen oder das Erstellen neuer Versionen alter Funktionen. Anrufe zu den alten Funktionen können dann durch den neuen Zeitpunkt (beim Testen) ersetzt werden.
Ich bin mir nicht sicher, was das Ziel Ihrer Aufgabe ist, aber ich rate Ihnen dringend, so wenig wie möglich vom Code zu berühren. Tun Sie nur, was Sie tun müssen.
Möglicherweise möchten Sie so viel wie möglich dokumentiert, indem Sie Personen interviewen. Dies ist eine große Aufgabe, da Sie nicht wissen, welche Fragen zu stellen sind und die Leute viele Details vergessen haben.
Ansonsten: Stellen Sie sicher, dass Sie bezahlt werden und genug moralische Unterstützung. Es wird weinen und Zähne knirschen ...
Nun, Sie müssen irgendwo anfangen, und es hört sich so an, als ob es Fehler gibt, die repariert werden müssen. Ich würde diese Fehler durcharbeiten, schnelle Sieg -Refactorings machen und alle möglichen Tests auf dem Weg geschrieben haben. Ich würde auch ein Werkzeug wie verwenden Sourcemonitor Um einige der "komplexesten" Code -Teile im System zu identifizieren und zu prüfen, ob ich ihr Design in irgendeiner Weise vereinfachen könnte. Letztendlich müssen Sie nur akzeptieren, dass dies ein langsamer Prozess sein wird, und kleine Schritte in Richtung eines besseren Systems machen.
Ich würde versuchen, einen Teil des Systems auszuwählen, der ziemlich schnell extrahiert und isoliert umkreist werden könnte. Auch wenn es nicht viel tut, können Sie ziemlich schnell den Fortschritt zeigen und nicht das Problem haben, sich direkt mit dem Legacy -Code zu verbinden.
Wenn Sie ein paar solcher Aufgaben ausfindig machen könnten, werden Sie Ihnen hoffentlich sehen, wie Sie sichtbare Fortschritte machen, und Sie könnten ein Argument für die Einstellung von mehr Menschen vorlegen, um die größeren Module neu zu schreiben. Wenn Teile des Systems auf gebrochenes Verhalten angewiesen sind, haben Sie nicht viel Wahl, sondern sich zu trennen, bevor Sie etwas beheben.
Hoffentlich können Sie nach und nach ein Team aufbauen, das das ganze Los neu schreiben kann.
All dies müsste mit einem anständigen Training Hand in Hand gehen, sonst bleiben die alten Gewohnheiten der Menschen, und Ihre Arbeit wird die Schuld bekommen, wenn die Dinge nicht wie erwartet funktionieren.
Viel Glück!
Aktivieren Sie alles, was derzeit existiert und Probleme hat, und schreiben neue, die richtig funktionieren. Dokumentieren Sie so viel wie möglich über das, was sich ändern wird, und setzen Sie große rote Blinkschilder überall auf diese Dokumentation.
Auf diese Weise können Sie Ihre vorhandenen Fehler (diejenigen, die für einen anderen Ort entschädigt werden) aufbewahren, ohne Ihren Fortschritt zu einem tatsächlichen Arbeitssystem zu verlangsamen.
