👩🏽‍🤝‍👨🏿 📫 🤚 Wir verkaufen Architecture Refactoring an einen Kunden oder was ist das Problem der Entwickler 👩‍🍳 😘 🚱

Architektur- oder Design-Refactoring ist bei einem Projekt immer ein schmerzhaftes Problem. Die Vorteile des Refactorings liegen für uns technische Spezialisten auf der Hand, aber für den Kunden ist es oft schwierig, diese Idee zu verkaufen und zu begründen. Der Hauptgrund ist, dass wir technischen Spezialisten nicht wissen, wie sie mit dem Geschäft sprechen sollen.

Bild

Das Hauptproblem ist die Kommunikation zwischen Technikern und Menschen, die Geld verdienen. Sie sprechen verschiedene Sprachen, obwohl sie versuchen, die gleichen Probleme zu lösen.

Dieser Artikel ist eine Übersetzung des Originals aus dem Englischen: Architecture Refactoring und Design Refactoring . Wenn Sie Kollegen haben, die kein Russisch sprechen, können sie das Original auf meiner Bulg lesen.

Die Vorteile des Refactorings liegen bei allen technischen Fachleuten auf der Hand, aber oft können wir diese Idee nicht an das Unternehmen weitergeben. Warum passiert das? Wir überspringen einige kleine, aber sehr wichtige Schritte für das Geschäft.

Wir teilen den gesamten Prozess in 6 einfache, aber notwendige Schritte ein:

Ermitteln Sie die Ursache des Problems.
Entscheiden Sie, welche Änderungen vorgenommen werden müssen.
Begründung der Entscheidung
Machen Sie einen Refactoring-Plan
Roadmap erstellen
Präsentieren Sie Ihre Entscheidung

Finden Sie die Ursache des Problems

Dieser Schritt ist uns als technischer Spezialist vertraut. Betrachten Sie es mit realen Beispielen.

Der Build stürzt nach fast jedem Commit ab.

Dafür gibt es mehrere Gründe:

Anwendungskomponenten sind sehr eng miteinander verbunden und voneinander abhängig
Anwendungskomponenten sind nicht ordnungsgemäß isoliert
Fehlende Unit-Tests
Fehlende SDLC-Prozesse und CI / CD

Noch ein Beispiel. Die Anwendungsbereitstellung dauert lange, und es werden auch Leistungsprobleme beobachtet.

Die Hauptgründe können sein:

Eine monolithische Anwendung wächst schnell und ist für eine Anwendung zu groß geworden
Die Anwendung ist groß und verbraucht viel RAM und Prozessorleistung.
Die Anwendung ist komplex und nicht gut geschrieben

Entscheiden Sie, welche Änderungen vorgenommen werden müssen.

Der nächste Schritt ist etwas komplizierter, aber für Senior + Entwickler immer noch vertraut und unkompliziert. Wir sind alle gute technische Experten und wissen immer, was verbessert werden muss. Und in diesem Moment machen wir einen Fehler und rennen mit den Worten zum Kunden, lass es uns tun .

Aber wir sind intelligente Architekten und werden unseren Plan von 6 Schritten Schritt für Schritt befolgen.

Basierend auf dem vorherigen Beispiel mit einer monolithischen Anwendung sind die Lösungen offensichtlich. Teilen Sie eine große, komplexe Anwendung in kleinere, unabhängige Module auf. Dies sind die ersten Schritte zu einer serviceorientierten oder Microservice-Architektur.

Bild

Begründung der Entscheidung

Wir werden diesen Schritt in zwei Phasen unterteilen: technische und geschäftliche Begründung.

Die technische Begründung erscheint uns logisch. Teilen Sie den Monolithen in kleinere Dienste auf, wodurch wir Folgendes erhalten:

Unterschiedlichere Komponenten
Build-Probleme werden nicht so häufig sein
Kleine Dienste verbrauchen daher weniger RAM und Prozessorleistung - bessere Leistung
Separate Dienste können schneller und unabhängig voneinander bereitgestellt werden

Die Rechtfertigung aus geschäftlicher Sicht ist ein sehr wichtiger Schritt, den technische Experten oft vergessen. Sie müssen sich daran erinnern, was für das Geschäft wichtig ist. Das stimmt - es ist Geld .

Kurz gesagt: Wenn Refactoring dem Unternehmen nicht zugute kommt, macht es keinen Sinn, dies zu tun.

Anhand unseres Beispiels können Sie dem Kunden folgende Vorteile bieten:

Neue Funktionen werden schneller entwickelt
Die Qualität der Anwendung wird aufgrund geringerer Kosten für die Fehlerbehebung und eines zufriedenen Benutzers der Anwendung besser, was sich auch positiv auf das Geschäft auswirkt
Reduzierte Entwicklungs- und Bereitstellungskosten
Es ist einfacher, motivierte und erfahrene Fachkräfte zu finden, die bereit sind, mit dem Projekt zu arbeiten.

Refactoring-Plan

Der Plan sollte klar und detailliert sein. Jede Iteration sollte klar beschrieben und alle Architektur- und Designänderungen dokumentiert werden.

Bild

Erstellen Sie Ihren Plan. Sie müssen die folgenden Fragen beantworten:

Was ist der Zweck dieser Iteration?
Was ist der technische und geschäftliche Wert dieser Iteration?
Wie kann ich die Iterationszeit verkürzen?

Roadmap

Ein sehr wichtiger Schritt . Nehmen Sie sich die Zeit, dies zu tun, wenn Sie Refactoring wirklich an ein Unternehmen verkaufen möchten.

Jeder Manager und Geschäftsmann möchte die Antworten auf zwei Fragen wissen:

Wie viel wird es kosten?
Wie lange wird es dauern?

Versuchen Sie, das Refactoring in kleine Iterationen aufzuteilen. Jede Iteration sollte technischen und geschäftlichen Wert bringen. Es ist ziemlich schwierig, Refactoring jahrelang zu verkaufen und Millionen von Dollar ohne Zwischenergebnisse zu kosten.

Jede Iteration sollte Informationen über die Dauer und Anzahl der dafür benötigten Spezialisten enthalten. Diese Informationen helfen dem Manager, zwei grundlegende Fragen zu beantworten, die etwas höher gestellt werden.

Sammeln Sie Projektmetriken vor und nach dem Refactoring bei jeder Iteration. Auf diese Weise können Sie zeigen, welchen technischen und geschäftlichen Wert diese Iteration gebracht hat.

Ich präsentiere meine Entscheidung

Bevor Sie sich für das Unternehmen entscheiden, wenden Sie sich an Ihren direkten Vorgesetzten. Eine Seitenansicht ist immer gut, insbesondere wenn es sich um eine geschäftliche Seitenansicht handelt. Vielleicht hat Ihr Manager mehr Kontext und hilft Ihnen dabei, den Plan entsprechend den Erwartungen des Unternehmens zu ändern.

Sie müssen wissen, wie Sie die klassische Frage beantworten können.

Wenn Sie ein architektonisches Refactoring präsentieren, kann ein Unternehmen normalerweise danach fragen. Warum brauchen wir Refactoring? Letztes Jahr haben wir genug Geld für Architektur ausgegeben und jetzt haben wir wieder Probleme.

Es gibt eine klassische Antwort auf die klassische Frage. Diese architektonische Lösung war vor einem Jahr gut, aber das Geschäft wächst und verändert sich, und die Architektur muss sich damit ändern.

Tipp Nummer 2. Machen Sie Ihren Kunden nicht in Panik. Stellen Sie Informationen als dringend, aber nicht als Katastrophe bereit. Angenommen, Sie haben sechs Monate Zeit, um eine Umgestaltung vorzunehmen, aber Sie müssen heute damit beginnen.

Endlich . Versuchen Sie bei der Präsentation Ihrer Entscheidung, die Menschen zu erziehen, nicht die Schuld. Denken Sie daran, dass Sie, wenn Sie Menschen beschuldigen, auf Widerstand von ihnen stoßen. Sie sollten nach Wegen suchen, um Probleme zu lösen, nicht nach den Tätern.

Abschließend

Refactoring ist teuer und schwer an Unternehmen zu verkaufen
Architektonisches Refactoring ist nicht nur ein technisches Problem, es muss auch noch an ein Unternehmen verkauft werden
Denken Sie an die Vorteile des Refactorings für Ihr Unternehmen.
Es ist immer einfacher, kleine Umgestaltungen zu verkaufen, aber oft als große, aber einmal

Weitere Artikel zu Architektur und Architektur-Soft Skills finden Sie in der Originalressource.

Gutes Refactoring an alle!

Wir verkaufen Architecture Refactoring an einen Kunden oder was ist das Problem der Entwickler