"Mit dem Handbuch kann ich meinen Legacy-Code nicht überarbeiten!" Gemeinsame Situation? Schrecklich nervig. Die meisten Entwickler sehen sich früher oder später einem Manager gegenüber, der überhaupt nicht daran interessiert ist, das zu verbessern, was bereits fertig ist. Sie müssen entweder etwas Neues implementieren oder das Feuer dringend löschen oder einen Fehler beheben ... Im Allgemeinen werden sie immer einen Grund finden, das Refactoring der laufenden Codebasis zu verschieben.
Und selbst wenn Sie versuchen, ihnen die Vorteile eines ordentlichen Codes zu erklären, verstehen sie entweder nicht oder wollen es nicht verstehen. Sie haben nur Kosten und Fristen im Kopf und niemand kümmert sich um Qualität. Und es stellt sich heraus, dass Sie absolut machtlos sind, etwas gegen technische Schulden zu unternehmen, die sich immer noch ansammeln. Programmierer arbeiten für prod und prod - für ungeduldige Benutzeranforderungen. Niemand wird für das Refactoring bezahlen. Die Situation sieht hoffnungslos aus.
In einer solchen Situation packen viele intelligente Entwickler einfach ihre Sachen und verlassen das Unternehmen. Und sehr bald sind die Türen aufgrund des Umsatzes in der Abteilung nicht mehr geschlossen: Einige gehen, andere kommen ...
Manager sind keine Programmierer
Die Lösung des Problems besteht darin, den Managern mitzuteilen, welche Auswirkungen eine schlechte Codequalität auf das Unternehmen hat. Letztendlich zielen die Aktivitäten des Unternehmens darauf ab, Geld zu verdienen. Ist eingetroffen. Dementsprechend sucht das Management nach den besten Möglichkeiten, um Kosten zu senken und Einnahmen zu steigern. Dies bedeutet, dass sie ihre Sprache sprechen müssen, um das Refactoring in ihren Augen zu rehabilitieren.
Ich habe zufällig sowohl als technischer Leiter als auch als Berater gearbeitet, daher habe ich viel Erfahrung in diesem Geschäft. Lassen Sie uns einige Vorlagen mit Ihnen teilen.
Fünf Argumente, die Sie geben können
1) "Refactoring wird dazu beitragen, die Volatilität der Grenzkosten pro Einheit der Softwarefunktionalität zu verringern."
Dies ist ein genaues Zitat aus den bemerkenswerten Leistungen von John. B. Rheinsberg auf einer Konferenz zum Thema "Wirtschaftlichkeit in der Softwareentwicklung". Warte, geh nicht! Alles, was hier gesagt wird, wissen Sie genau, es ist einfach in einem abstrakten, abstrusen Geist formuliert.
Lass uns in der richtigen Reihenfolge gehen:
- "Refactoring hilft zu reduzieren ..." - bisher ist alles in Ordnung
- "... Volatilität ..." - mit anderen Worten, Unvorhersehbarkeit
- "... Grenzkosten ..." - das heißt, wie viel Ressource benötigt wird, um eine weitere Einheit zu produzieren
- „… Pro Einheit Softwarefunktionalität“ ist eine Funktion, die für das Geschäft von Wert ist. Hurra! Geschäftswert ist genau das, was wir brauchen.
Alle fünf Argumente basieren auf der gleichen allgemeinen Idee der Übersetzung von einer Sprache in eine andere, die wir im Umgang mit Menschen weit entfernt von der IT-Sphäre oft vernachlässigen. Verwenden Sie keinen Slang, stützen Sie sich auf Konzepte aus Wirtschaft und Business - das ist die ganze geheime Zutat. Auf diese Weise können Sie schneller eine Verbindung zu Ihrem Management herstellen.
2) "Im letzten Monat wurden 63% der Entwicklungsressourcen für die Behebung von Problemen mit der Qualität des Produkts ausgegeben."
Ersetzen Sie hier Ihre Zahlen. Es geht darum, die Nachricht mit quantitativen Daten zu sichern. Technische Schulden können nicht anders, als sich auf Ihre täglichen Arbeitsprozesse auszuwirken. Kannst du das beweisen? Natürlich!
Hier sind einige Metriken, die Sie sich ansehen können:
- . ? ?
- -, , . , ? ?
- , . ? ?
Zeigen Sie dem Management genau, wo schlechte Codequalität für sie bedeutet. Besser noch, finden Sie einen Weg, diese Zahlen in Geldwerte umzuwandeln.
Ich war einmal bei einem Post-Mortem-Fehler, der hätte vermieden werden können, wenn die Datentypprüfung durchgeführt worden wäre. Der Code wurde in JavaScript geschrieben. Zu dieser Zeit gab es im Unternehmen eine Debatte darüber, ob auf TypeScript umgestellt werden sollte.
Die Entwickler, die verstanden hatten, was passiert war, waren nicht zu faul, um die Daten zu erheben, und konnten den Schaden einschätzen, den der Fehler für das Unternehmen verursachte. Es stellte sich heraus, dass der Käfer in den wenigen Monaten seines Bestehens eine Million kanadische Dollar von der Firma abgezogen hat. Million! Das allein hätte ausgereicht, um die Kosten für den Wechsel zu TypeScript auszugleichen.
Auf dieser Grundlage wurde beschlossen, die neuen Dienste in TypeScript zu implementieren, und für die wichtigsten sollten die Datentypen rückwirkend überprüft werden.
3) „Aus technischer Sicht haben wir an Krediten gearbeitet, um das Produkt schneller herauszubringen. Jetzt müssen wir einen Teil der Schulden abbezahlen, damit sich die Markteinführungszeit nicht verlängert. “
Nochmals: Wir sprechen die Sprache des Gesprächspartners. Metaphern können sehr effektiv sein, wenn Sie eine Nachricht übermitteln müssen: Sie verbinden unbekannte Konzepte mit vertrauten für den Hörer und helfen so, sie zu verstehen. Das Konzept des "Kredits" ist jedem Manager bekannt. Und "technische Schulden" selbst sind auch eine Metapher, die breite Verbreitung gefunden hat.
Oder stellen wir uns ein Unternehmen als Restaurant und eine Codebasis als Küchenbereich vor. Da sich schmutziges Geschirr ansammelt, wird es immer schwieriger, immer mehr Besucher zu bedienen. Die Mitarbeiter müssen Zeit haben, um das Geschirr zwischen den Mahlzeiten zu spülen.
4) "Wenn Sie 10% Ihrer Arbeitszeit in Codequalität investieren, sinkt Ihr Umsatz erheblich."
Bisher haben wir über die offensichtlichen Folgen einer schlechten Codequalität gesprochen. Aber es gibt eine heimtückische Sache, die leicht zu übersehen ist: Umsatz.
Unternehmen haben es heutzutage schwer, Entwickler, insbesondere talentierte, auf dem Laufenden zu halten. Wenn eine solche Person aufhört, Spaß an der Arbeit zu haben, wird es für sie nicht schwierig sein, ein anderes Angebot zu erhalten und einfach dorthin zu gehen, wo sie hinschauen, weg vom ewigen Chaos. Vielleicht suchen Sie selbst schon nach etwas Besserem ...
Und jetzt stellen wir uns eine Frage: Was kostet das Unternehmen, um einen zurückgetretenen Entwickler zu ersetzen? Es muss ein neuer Spezialist gefunden werden, der durch den Einstellungsprozess geführt und auf den neuesten Stand gebracht wird. Es kostet Investitionen, Zeit und verlangsamt das gesamte Team. Das Management würde es definitiv vorziehen, diese Art der Umbildung nicht jedes Jahr durchzuführen. Daher kann die Verringerung der Fließfähigkeit ein ernstes Argument sein. Allein die Tatsache, einen Plan zur Beseitigung technischer Schulden zu haben, wird das gesamte Team sofort motivieren.
5) "Wenn Sie 20% der Ressource in Refactoring investieren, halbiert sich FRT und der ROI wirkt sich positiv auf die Entwicklerproduktivität aus."
FRT ist die Reaktionszeit, eine wichtige Messgröße für die Benutzerunterstützung. Das Unternehmen ist bestrebt sicherzustellen, dass die Kunden mit allem zufrieden sind.
Hier machen wir folgendes:
- Auswahl von Metriken, die im technischen Support viel Gewicht haben;
- Wir finden einige Probleme, die regelmäßig auftreten und ein Eingreifen der Entwickler erfordern.
- Wir bieten einen Plan zur Reduzierung der Anzahl der Anrufe beim technischen Support an, indem die Grundursache beseitigt wird.
- Wenn diese Art von Problemen behoben wird, ist es weniger wahrscheinlich, dass Entwickler an Benutzerunterstützungsaufgaben beteiligt sind. Das heißt, sie werden mehr Zeit als für das Refactoring aufgewendet, was bedeutet, dass sich die Investition auszahlt - dieser sehr positive ROI.
Letztendlich entscheiden sie
Niemand kann damit streiten. Ich habe fünf Argumente angeführt, um die Leute davon zu überzeugen, wie wichtig es ist, technische Schulden abzubauen, aber jetzt denke ich, dass noch ein Ratschlag gegeben werden muss, bevor Sie an einem Manager arbeiten.
Refactor wie du gehst
Refactoring sollte nicht als separate Phase der Funktionsarbeit betrachtet werden. Schließlich können Sie immer noch nicht im Voraus vorhersagen, welche Funktionen in Zukunft implementiert werden. Dies bedeutet, dass Sie die Codebasis an neue Realitäten anpassen müssen, sobald diese verfügbar sind. Dies ist auch Teil der Arbeit, die erforderlich ist, um genau diesen materiellen Wert zu schaffen - jeder professionelle Entwickler wird dies bestätigen.
Die Regel funktioniert auch für Datenbanken mit Legacy-Code. Okay, du wirst sie bis morgen definitiv nicht in eine göttliche Form bringen. Und der Versuch, zwischendurch ein umfangreiches Refactoring durchzuführen, ist ebenfalls ein totes Problem. Aber mit diesem Ansatz wird sich zumindest die Situation nicht verschlechtern. Und wenn Sie mit lrgacy-Code arbeiten, müssen Sie sich nicht auf "gut", sondern auf "besser" konzentrieren.
Beheben Sie einen Fehler? Verbringen Sie eine zusätzliche Stunde damit, einen automatisierten Test zu schreiben. Sind Sie bereit, eine neue Funktion einzuführen? Nehmen Sie sich einen zusätzlichen Tag Zeit, um den Code zu bereinigen. Versuchen Sie, die Änderung Tag für Tag schmerzlos zu machen. Nach einigen Monaten werden Sie feststellen, dass diese Gewohnheit einen großen Einfluss auf Ihre Produktivität hatte. Weißt du, warum? Weil Refactoring dazu beiträgt, die Volatilität der Grenzkosten pro Einheit der Softwarefunktionalität zu verringern.