Wartungscode. Wie man Refactoring an ein Unternehmen „verkauft“

    Vor ein paar Tagen habe ich einen Artikel über die Hauptmerkmale des alten Codes geschrieben. Es gab jedoch zu wenig konkrete praktische Empfehlungen zum Leben in der alten Code-Umgebung.

    Heute werde ich versuchen, eine der häufigsten Fragen zu beantworten, die ich bei der Entwicklung von Systemen mit übermäßigem Erbe höre, und ich werde meine Ansicht darüber teilen, wie man Refactoring an ein Unternehmen „verkauft“.

    In diesem Artikel beschränke ich mich im Wesentlichen darauf, die Interaktionen mit dem Geschäft zu beschreiben, und gehe nicht auf technische Details ein (wie man Refactoring durchführt). Der Beitrag bezieht sich ausschließlich auf die persönliche, erfolgreiche und wenig erfahrene Erfahrung beim „Verkaufen“ und „Kaufen“ von Refactoring in verschiedenen Teams und in verschiedenen Unternehmen.

    Hintergrund


    Um genauer zu sein, stellen wir uns vor, dass wir ein Flaggschiffprodukt haben, das seit mehreren (manchmal zehn) Jahren in Betrieb ist und den Löwenanteil des Umsatzes des Unternehmens erwirtschaftet.

    Typischerweise werden ungefähr die folgenden Produkteigenschaften beobachtet:
    • „Plastilin-Architektur“ - Im Laufe der Lebensdauer des Produkts wurden zahlreiche zusätzliche Funktionen hinzugefügt, die in Eile hinzugefügt wurden. Dies führte dazu, dass die Logik des Systems gleichmäßig über den gesamten Code verteilt ist. An einigen Stellen gibt es "Hacks", mit denen Sie "etwas Seltsames" tun können, ohne die ursprüngliche Idee zu umgehen.
    • fehlende Komponententests - die derzeitige Logik wird von Tests nur wenig mehr als vollständig abgedeckt. "Weil wir im dritten Lebensjahr des Systems über Unit-Tests nachgedacht haben, aber es ist bereits unklar, wie und wo das System erstellt werden soll, und wir hatten nicht genügend Zeit für Tests."
    • Mangel an Fachleuten - Leute, die ursprünglich das Produkt geschrieben haben, sitzen entweder in der Position großer Manager, kündigen oder haben schon seit vielen Jahren vergessen, wie alles im Inneren angeordnet ist.

    Ich habe eine typische Situation beschrieben, in der es in verschiedenen Unternehmen eine Vielzahl von Produkten gibt. Darüber hinaus kann das Niveau der Entwickler, was typisch ist, sehr hoch sein. Es ist nur so, dass der Code von Jahr zu Jahr verwirrender wird.

    Es ist klar, dass früher oder später ein solcher Code überarbeitet werden muss. Aber wie bekommt man Zeit für diese Aufgabe in einem ständigen Fluss von Produktaufgaben? Darüber werden wir weiter unten sprechen.

    Oder vielleicht alles von Grund auf neu schreiben?


    Sie können davon träumen, aber es gibt nur sehr wenige Möglichkeiten, jemanden davon zu überzeugen. Wenn Sie es außerdem schaffen, das Management davon zu überzeugen, den alten Code zu verwerfen und alles erneut zu schreiben, bedeutet dies, dass entweder dieses Handbuch selbst nicht in der Lage ist, Risiken einzuschätzen, oder dass das Unternehmen so reich ist, dass es sich eine lange Zeit (manchmal mehrere Jahre) leisten kann. enthalten ein paralleles "strategisches" Team von Programmierern, die keinen aktuellen Gewinn bringen.

    Lesen Sie im Allgemeinen Joel Spolsky . Er sagt den Fall (obwohl Netscape laut offizieller Version immer noch mit kostenlosem IE vom Markt verdrängt wurde und nicht mit Verzögerungen bei Updates).

    Und noch etwas: Sie müssen verstehen, dass das Projekt „Alles von Grund auf neu schreiben“ Jahre dauern kann, aber Sie müssen sich zu diesem Zeitpunkt noch mit der Unterstützung des alten Codes befassen. Daher ist das, was unten steht, auf jeden Fall wichtig.

    Wie können Sie ein Unternehmen davon überzeugen, dass Refactoring noch erforderlich ist?

    Tipp 1. Verkaufen Sie Refactoring nicht an ein Unternehmen!


    Um zu verstehen, was ich meine, müssen wir uns an die klassische Definition von Fowler erinnern: Refactoring ist eine Änderung der internen Struktur von Software mit dem Ziel, das Verständnis ihrer Arbeit zu erleichtern und die Änderung zu vereinfachen, ohne das beobachtete Verhalten zu beeinträchtigen .

    Lassen Sie uns zwei Punkte beachten:
    • Ziel des Refactorings ist es, das Verständnis und die Änderung von Code zu vereinfachen - rein technisch, nicht geschäftlich
    • das Verhalten ändert sich nicht, dh das Ergebnis für das Geschäft ist nicht spürbar

    Dies bedeutet, dass bei einem erfolgreichen Refactoring keine Änderungen vorgenommen werden. Keine! Wenn es weniger erfolgreich ist, gibt es Fehler und Verhaltensunterschiede im Arbeitscode. Das heißt, Sie können nicht sagen, "wir haben 10 Fehler behoben und einen superschönen Trick implementiert". Man kann sagen: „Jetzt ist der Code schöner geworden und die Architektur ist einfacher und verständlicher. Nun ja, und ein paar Fehler sind aufgetaucht ... Aber wir werden sie beheben! "

    Stellen Sie sich jetzt vor, Sie wären am Geschäftssitz. Ein Team von teuren Spezialisten verbrachte viel Zeit mit der „Schönheitsberatung“, anstatt verständliche Funktionen zu entwickeln, die Anwendern und Geld bringen. Es ist dasselbe, als würde man das Auto einem Autoservice übergeben, es unverändert erhalten und eine Rechnung über 500 US-Dollar mit dem Hinweis "Wir haben Ihre Federung durchlaufen und können jetzt die Gestelle dreimal schneller wechseln." Vielleicht ist das erste Mal etwas zu erschließen, aber es sollte in einem Monat vergehen. Wenn es nicht funktioniert, werden wir es gegen eine geringe Gebühr reparieren. " Ich weiß nichts über dich, aber das würde mir nicht sehr gefallen.

    Im Allgemeinen lautet die erste Regel: Sie kaufen nur das, was für den Käufer interessant ist oder was Sie interessiert. Die Änderung des Codes an sich ist für Unternehmen nicht wertvoll und für niemanden außer für Entwickler interessant. Der Hauptfehler, den Sie machen können, ist daher zu sagen: "Sie müssen umgestalten, weil der Code schlecht ist und nichts klar ist."

    Was soll ich dann sagen?

    Tipp 2. Verkaufe Geschäftsmöglichkeiten und löse Probleme


    Ich denke, dass jeder von uns intuitiv versteht, dass Probleme mit schlechtem Code nicht nur zu Problemen für die Entwickler führen, die damit arbeiten, sondern auch zu bestimmten Problemen im Geschäftsleben. Wenn wir versuchen, dieses Verständnis zu formalisieren, kommen wir zu zwei gravierenden Problemen.

    Erstens ist dies ein instabiles Verhalten des Systems - seltsame Fehler, Leistungsprobleme, unvorhersehbares Verhalten, Datenverlust (dies ist wahrscheinlich das Schlimmste) und so weiter. Dies führt wiederum zu Unzufriedenheit der Benutzer, Ablehnung, schlechten Bewertungen und niedrigen Bewertungen bei mobilen Anwendungen. Im Allgemeinen wirkt es sich am unmittelbarsten auf den Gewinn aus.

    Zweitens ist es ein sehr langer Prozess, Änderungen vorzunehmen.. Das heißt, ab dem Moment, an dem ein Feature konzipiert wurde, bevor es im Code angezeigt wird, vergeht viel Zeit. Dies macht nicht nur den Entwicklungsprozess für das Produktteam langwierig und schmerzhaft, sondern ermöglicht es Ihnen auch nicht, viele Funktionen schnell anzuzeigen, mit einer großen Anzahl verschiedener Optionen zu experimentieren, Prototypänderungen schnell durchzuführen und den Benutzern ihre Reaktionen anzuzeigen. Darüber hinaus sind einige der Änderungen, die Sie vornehmen möchten, manchmal einfach nicht möglich, ohne das gesamte System gründlich nach Zahnrädern zu sortieren (und dies entspricht bereits dem, was wir als Refactoring bezeichnen).

    Daher ist es notwendig, sich mit der Idee des Refactorings in dem Moment auseinanderzusetzen, in dem mindestens eines dieser beiden Probleme offensichtlich wird. Wenn es jedoch noch keine Probleme gibt und Sie in einem dieser Bereiche eine potenzielle Gefahr sehen, können Sie im Voraus zur Arbeit kommen. Dann ist es jedoch notwendig, viel überzeugendere Argumente vorzubereiten.

    Daher sollte das Ziel des Refactorings nicht darin bestehen, die Struktur des Codes zu verbessern, sondern das System zu stabilisieren oder die Bereitstellung von Funktionen für Benutzer zu beschleunigen . Wenn sich dementsprechend die Anzahl der Fehler infolge von Umgestaltungen nicht verringerte und einfache Funktionen für jeweils zwei Monate hinzugefügt wurden, wurde die Zeit verschwendet, und aus geschäftlicher Sicht konnten Sie die Hauptaufgabe nicht bewältigen.

    Tipp 3. Sehen Sie sich die Geschäftsentwicklung an


    Wie oben bereits erwähnt, lautet die erste Argumentationsregel, die Werte des Gesprächspartners zu verstehen. In diesem Fall ist es sinnvoll, das Refactoring von der Seite des Unternehmens aus zu betrachten.

    Aus betriebswirtschaftlicher Sicht hat jedes Feature Entwicklungskosten und Implementierungsgewinn. Kosten bestehen aus mehreren Teilen. Erstens ist dies das Geld, das das Team für die Entwicklung von Funktionen ausgibt. Dies beinhaltet Entwicklergehälter, Steuern, Büromiete, Ausrüstung, Strom und so weiter. Weniger offensichtlich, aber nicht weniger wichtig sind die mit entgangenen Gewinnen verbundenen Kosten: Während der Entwicklung des aktuellen Features werden andere Funktionen, die kein Geld bringen und keine neuen Benutzer anlocken , nicht im Produkt angezeigt .

    Offensichtlich kann die Bedeutung eines Features leicht geschätzt werden, indem der geplante Gewinn daraus und die Kosten seiner Implementierung verglichen werden. Refactoring ist aus dieser Sicht eine Investition in ihrer reinsten Form. Ressourcen werden verschwendet, aber dadurch werden weder neue Benutzer noch neue Funktionen im Produkt angezeigt.

    Und Ihre Hauptaufgabe - zeigen Geschäft, warum in Refactoring investiert innerhalb eines angemessenen Zeitraums profitieren .

    Wie kann man diesen Vorteil zeigen?

    Tipp 4. Mit Zahlen arbeiten


    Um eine Entscheidung zum Refactoring zu treffen, muss ein Unternehmen erstens eine Schätzung der Arbeitskosten erhalten, die für die Durchführung anfallen (Sie tun dies höchstwahrscheinlich regelmäßig), und zweitens, um den Gewinn aus den Ergebnissen zu verstehen. Und das ist einer der schwierigen Momente. Egal, wie ich sagen möchte: „Wir haben viele Fehler“ oder „Wenn wir überarbeiten, können wir Zeit sparen, wenn wir weitere Änderungen vornehmen“, diese Wörter haben keine Bedeutung für das Geschäft.

    Um eine normale numerische Begründung zu erhalten, müssen Sie administrative Arbeiten ausführen. Zum Beispiel, um alle Fehler, die in der aktuellen Implementierung nicht in angemessener Zeit behoben werden können und die nach dem Refactoring behoben werden, in einer Liste zusammenzufassen. Eine komplexere und mühsamere Arbeit besteht darin, den Zeitaufwand für jede Änderung zu protokollieren und zu jeder Ziffer die Zeit hinzuzufügen, die diese Änderung nach dem Refactoring im System in Anspruch nehmen würde. Dies ist um eine Größenordnung komplizierter, aber die Ergebnisse sind viel greifbarer. Denn „die Änderung, mit der wir im letzten Monat X Mannstunden an Entwicklung einsparen und in Zukunft etwa die gleichen Einsparungen erzielen können“, klingt für ein Unternehmen verständlicher und überzeugender als die Notwendigkeit, „den Code in Ordnung zu bringen“.

    Es gibt noch einen anderen subtilen Punkt. Bei der Beurteilung geht es vor allem darum, eine Zukunft nicht zu verschönern, nicht heller zu gestalten, als es tatsächlich sein wird, und die Kosten für das Refactoring nicht zu unterschätzen. Nachdem Sie das begehrte „Gut“ für das Refactoring erhalten haben, sind Sie schließlich derjenige, der eine glänzende Zukunft versprochen und das Budget ausgegeben hat, und infolgedessen ...

    ... und infolgedessen hängt alles von Ihnen ab. Wenn Sie sicher sind, dass Refactoring dabei helfen kann, alte Fehler zu beheben, die Entwicklung zu beschleunigen, den Code sauberer und verständlicher zu gestalten und den Benutzer zufriedener zu machen, dann fahren Sie fort.

    Und viel Glück!

    Jetzt auch beliebt: