Ich wurde gebeten, eine interne Webanwendung zu verbessern und zu pflegen, die von einer wichtigen Benutzergemeinschaft verwendet und genehmigt wird. Dies beinhaltet Leistungsverbesserungen und das Hinzufügen von Funktionen.
Leider ist der Code aufgebläht, manchmal sehr schlecht geschrieben und schwer zu lesen und zu ändern. Dies macht Änderungen viel schwieriger zu implementieren.
Trotz allem ist die Anwendung gut aussehend, nützlich und die Benutzer mögen es und wollen Änderungen.
Deshalb fühle ich mich wie ich getäuscht worden bin. Ist es wirklich besser, crappy Code für schnelleres großartiges Ergebnis und Ruhm zu schreiben, dann für großartige neue Projekte verlassen, die solch eine Menge von Problemen hinter sich lassen?
Ich habe schon viel über dieses Thema auf Coding Horror gelesen, aber ich würde gerne mehr von Leuten hier lesen, die diese traurige Realität erleben und wie sie damit umgehen. Ich muss wahrscheinlich auch etwas Mut bekommen;)
Da meine Hauptsprache nicht Englisch ist, können Sie diese Frage mit besserer Grammatik umschreiben.
Dies wird bei den meisten Programmierern passieren. Der erste Drang ist es neu zu schreiben. Der bessere Ansatz besteht darin, einfach das zu tun, was Sie tun sollen. Wenn Sie größere Umformatierungen vornehmen, werden Sie es sehr wahrscheinlich brechen.
Wenn die erforderlichen Änderungen einfach sind, sollten Sie sie mit so wenigen Änderungen wie möglich in dem Stil implementieren, in dem sie bereits geschrieben sind.
Wenn die Änderungen komplizierter sind, versuchen Sie, Ihre Änderungen an möglichst wenigen Stellen anzuwenden. Wenn Sie den Code im Laufe der Zeit aufräumen möchten, sollten Sie beginnen. Sei vorsichtig mit den Änderungen, die du machst, weil du Abhängigkeiten, die du nicht verstehst, leicht brechen kannst. Es ist meine persönliche Erfahrung, dass ich in der Regel neue Funktionen hinzufügen oder Änderungen implementieren kann, indem ich tatsächlich Code lösche und neu schreibe, was in einer bestimmten Routine oder Methode übrig ist.
Widerstehen Sie Ihrer Versuchung, alles neu zu schreiben. Betrachte es als Triage. Priorisieren Sie Änderungen, die Sie sehen möchten, und implementieren Sie sie, während Sie Änderungen implementieren, die angefordert werden. Vermeiden Sie Code, den Sie nicht ändern müssen. Zwingen Sie Ihre Benutzer nicht dazu, Probleme aufgrund von Änderungen zu behandeln, die Sie nur aufgrund der Ästhetik vornehmen.
Fast jeder Entwickler, der überall und zu irgendeinem Code, den er nicht geschrieben hat, möchte ihn neu schreiben, um die beschissenen Bits zu reparieren.
Widerstehen Sie Ihrem Drang, alles neu zu schreiben, reparieren Sie die zerbrochenen Teile. Gehen Sie mit Bits um, die nicht gepflegt werden können, wenn Sie sie pflegen müssen!
Schreiben Sie eine Testsuite für das Produkt, damit Sie sicherer sein können, dass Sie nichts kaputt machen.
Refaktorieren Sie dann die schlechtesten Bits des Codes oder die Bits, die Sie sowieso ändern müssen.
Aber: Denken Sie darüber nach, "wenn es nicht kaputt ist, reparieren Sie es nicht". Wenn ein Bereich funktioniert und Sie ihn nicht ändern müssen, überlegen Sie, ob die Risiken der Einführung von Problemen den Nutzen übersteigen "nett".
Und finde die ursprünglichen Entwickler und locke sie in eine dunkle Gasse :) Oder besser, lass sie die Änderungen machen
Ich habe für einige Projekte einen beschissenen Code geschrieben. Jedoch vernünftiger "schlechter" Code. Crappy-Code kann durch viele Gründe verursacht werden, nicht nur die Fähigkeiten der Person. (Nun, die meiste Zeit ist es wegen der Fähigkeiten)
Programmierer können sehr guten Code schreiben, wenn Sie genug Zeit und keinen Druck vom Geschäft haben. Aber die Geschäftsleute schätzen die gute Programmierung nicht, sondern die Funktionalität und das Aussehen. Ich denke, dass "crappy" Coder ein kluger Typ im Geschäft ist. Er hat einfach das Lösungsmodell entwickelt, die Software in kurzer Zeit zum Laufen gebracht und auch den Arbeitgeber glücklich gemacht !! Wenn der Programmierer es erneut schreiben sollte, kann er / sie es viel besser machen.
Erstens , Sie müssen sich davon überzeugen, zu schätzen, wie viele Sachen die frühen Programmierer durchgemacht hatten, das ist einer der Punkte, die Sie berücksichtigen sollten, wenn Sie ein reifer Entwickler sind oder nicht. Die meisten Leute Beschwerden und lachen sogar über die bestehenden Versionen, weil sie wissen, dass sie es besser machen können. Es ist, als ob man mit deiner Vorstellungskraft auf ein leeres Papier zeichne oder eine Kopie des bestehenden Gemäldes mache. Welcher ist schwieriger?
Zweitens , Schauen Sie sich den Code insgesamt an und finden Sie heraus, wo er verbessert werden kann. Vielleicht finden Sie etwas, das Sie falsch verstanden haben.
Drittens , Road-Map die Erweiterung, kann es aktuelle und zukünftige TODOs
enthaltenZuletzt , Beginnen Sie zu planen, wie es verbessert werden kann, wenn Sie es von Grund auf, neue Architektur usw. entwerfen, und es dem Management präsentieren, wenn es bereit und umfassend ist.
Jede Software hat einen Raum, um sich zu verbessern, deshalb wurden Sie eingestellt, um es zu verbessern.
Schlechter Code ist technische Schulden ; es kann weniger teuer sein zu schreiben, aber es wird viel teurer in der Wartung (es sei denn, Sie zahlen die Schulden durch Refactoring oder Neuschreiben zurück).
Sie erhalten vielleicht ein schnelleres Ergebnis und Ruhm, aber wenn Benutzer später Änderungen wünschen, müssen Sie fortwährend mehr Mühe darauf verwenden, sie zu tun (oder die unvermeidlichen Fehler zu beheben).
Ja, einige schlecht geschriebene Programme sind beliebt. Der Nachteil ist, dass solche Apps im Laufe der Zeit schwieriger zu verbessern sind (zum Beispiel in Bezug auf Skalierung, Hinzufügen neuer Funktionen, Bugfixing usw.).
Aber nein, es ist nicht gut, einen Müllcode zu schreiben. Es ist gut zu identifizieren, was Benutzer wollen, und ihnen eine gute Schnittstelle zu geben. und machen den Code leicht zu pflegen. Gelegentlich kann das bedeuten, dass die Benutzer besonders früh auf neue Funktionen warten müssen - aber auf lange Sicht werden Sie mehr erledigen können.
In Ihrem Fall schlage ich vor, dass Sie versuchen, sich ein wenig zu verbessern. Wenn du kannst, schneide einen Bereich aus und "repariere" ihn, und stelle sicher, dass er nie wieder in die "schlechten alten Zeiten" zurückkehrt. Dann schneide den nächsten Bereich aus. Irgendwann wirst du eine schön geschriebene App haben. Es kann länger dauern, das zu tun, als von Grund auf neu zu schreiben, aber Sie werden in der Lage sein, Benutzern Verbesserungen zu geben, und Sie werden mehr Vertrauen haben, dass es zu irgendeinem Zeitpunkt ein funktionierendes System ist.
Manchmal, wenn ein Programmierer zum ersten Mal ein altes Projekt aufruft und alle Klassen, Interfaces, Codemodule usw. sofort denkt, dass es "aufgebläht" ist. In der Tat könnte es nur eine sehr detaillierte Architektur haben, die auf den ersten Blick überwältigend sein kann. Wenn das Projekt keine Dokumentation enthält (z. B. ein Klassendiagramm), nehmen Sie sich etwas Zeit, um das zu skizzieren. Es hilft Ihnen nicht nur zu verstehen, wie das Projekt funktioniert, sondern hilft auch jedem, der hinter Ihnen folgt.
Das gilt auch für Aussagen wie "schwer zu lesen". Wenn Sie die Programmiersprache kennen, ist es nicht schwieriger zu lesen als jede andere Anwendung. Der Stil des ursprünglichen Programmierers mag sich von dem deines anderen unterscheiden, aber wenn die Anwendung funktioniert, dann tun sie nichts, was die Sprache ihnen nicht erlauben würde. Der Fluss kann schwierig zu folgen sein, aber das kann durch Skizzieren des Prozesses (z. B. ein Flussdiagramm) überwunden werden. Die meisten Manager werden Zeit für eine Lernkurve haben, um sich mit der Anwendung vertraut zu machen, bevor sie Änderungen vornehmen. Nehmen Sie sich Zeit, um einige Diagramme zu skizzieren. Sie (und der Programmierer, der Ihnen folgt) werden froh sein, dass Sie das getan haben.
Soweit "crappy code" geht, ist das sehr subjektiv. Ist es wirklich der Code (die Implementierung), der "crappy" oder das Design ist? Fehlen Designmuster? Eine Übernutzung oder schlechte Umsetzung von Designmustern? Oder haben sie wirklich solide Entwurfsmuster implementiert, aber du kennst sie einfach nicht genug, um sie zu erkennen?
Der Punkt ist, es kann überwältigend sein, wenn ein neues Projekt übergeben wird und es leicht ist, den ursprünglichen Programmierer für "Bloat", "crappy code", "schwer zu lesen und Änderungen vorzunehmen" usw. verantwortlich zu machen. Manchmal ist das so Das stimmt zwar, aber oft kann es daran liegen, dass der Programmierer das Design und die Architektur der Anwendung nicht versteht oder versteht, warum bestimmte Dinge so implementiert wurden, wie sie waren.
Stellen Sie sicher, dass Ihr Management und Ihre Benutzer wissen, dass der Code unter dem Gesichtspunkt der Veränderbarkeit eine unzureichende Qualität aufweist. Wenn Sie schätzen, wie viel Zeit Sie für die Implementierung neuer Funktionen benötigen, sollten Sie immer angeben, wie viel Zeit Sie benötigen, um den betroffenen Code zu bereinigen.
"Trotzdem ist die Anwendung gut aussehend, nützlich, und die Benutzer mögen es und wollen Änderungen"
Die Anwendung gibt den Kunden offensichtlich das, was sie wollen, klingt aber so, als ob sie die unerwartbare Stufe erreicht hätte.
Ich denke, es gibt nichts anderes, als unerbittlich umzubauen. Dies wird wahrscheinlich einfacher und weniger schmerzhaft sein, wenn Sie dem Druck widerstehen, nicht-triviale Funktionen gleichzeitig hinzuzufügen. Erklären Sie den Managern auf jeden Fall, dass die Software, obwohl sie gut ist, Gefahr läuft, sich in einen großen Haufen unhaltbarer Crude zu verwandeln.
Codeverbesserungen führen oft zu ein oder zwei eigenen Fehlern, aber Sie werden auf lange Sicht viel Hirnschaden ersparen. Holen Sie so viele zusätzliche Augäpfel wie Sie können, um beim Testen und Debuggen zu helfen, und halten Sie sich zuerst an die wirklich schlechten Bits.
Erwägen Sie die Einführung von Komponententests, wenn der vorherige Amtsinhaber dies noch nicht getan hat, damit Sie mehr Vertrauen haben, dass das Refactoring nichts gebrochen hat. Ich befürworte nicht die Philosophie "Wenn es nicht kaputt ist ...", denn dies wird Sie auf dem gleichen unbefriedigenden Karussell halten.
Mach dir keine Sorgen um dein Englisch, es hat für mich vollkommen Sinn gemacht und deine missliche Lage ist universell.
Tags und Links language-agnostic