Wie kann ich für die Reduzierung der technischen Schulden bezahlt werden?

Ich arbeite zurzeit für ein kleines Unternehmen, das nur wenige technisch komplizierte Produkte hat. Ich bin der einzige Entwickler für einen von ihnen. Vor ungefähr einem Jahr habe ich die Vorgängerversion des Produkts erhalten und angefangen, es zu "unterstützen".

Der Kunde spricht nur über neue Funktionen, den geschäftlichen Nutzen und andere dieser Art. Das Problem ist, dass der Code zwar in C # ist, aber ziemlich prozedural ist. Es gibt keine Abstraktionen, Klassen werden nur dort verwendet, wo Visual Studio sie benötigt - zum Beispiel Formulare. Die Implementierungen dieser Klassen sind wirklich schrecklich und der Code ist wirklich schwer zu pflegen.

Während des ganzen Jahres verbringe ich meine eigene Zeit mit Refactoring. In der neuesten Version gibt es hübsche Abstraktionen und so. Ich musste eine Reihe von Komponenten von Grund auf neu implementieren, und ich bin der Meinung, dass das Hinzufügen neuer Funktionen oder das Ändern des Verhaltens dieser Komponenten VIEL einfacher ist als bei anderen.

Das Problem ist, ich verbringe meine eigene Zeit. Ich mag die Ergebnisse sehr, aber ich mag es nicht, 12 Stunden am Tag zu arbeiten. Warst du jemals in einer ähnlichen Situation? Was soll ich probieren? Ich habe bereits versucht, darüber zu diskutieren, aber immer noch keinen Erfolg.

Ich habe nur Angst vor dem Moment, in dem wir uns für die Implementierung der neuen Funktion entscheiden, die viele Änderungen am Legacy-Code erfordert. Für den Kunden könnte das schockierend sein: Warum brauchen Sie 8 Stunden, um diese Symbole zu ändern? Dem Kunden ist es einfach egal, dass der Code 500 Stellen enthält, die ich ändern muss. Und ich sollte auch alle diese 500 Plätze zuerst finden.

Irgendwelche Ideen?

Schritt 1: Hören Sie auf, unbezahlte Überstunden zu leisten.

Sie haben Ihren Kunden und Manager bereits ein Jahr lang geschult, um zu glauben, dass die aktuelle Entwicklungsrate die zu erwartende ist. Dies ist einer der Gründe, warum sie nicht verstehen, warum eine "einfache" Sache einen ganzen Tag dauern kann. Sie müssen sie nicht als Geiseln nehmen und versuchen, das Projekt zu verletzen. Aber Sie müssen erklären, dass ihre Erwartungen zu hoch sind und Sie entweder einen anderen Entwickler oder mehr Zeit vor dem Abgabetermin benötigen. Weisen Sie Ihren Vorgesetzten ausdrücklich darauf hin, dass Sie unbezahlte Überstunden geleistet haben und planen, dies nicht so häufig zu tun. Selbst wenn Sie es auf 9 Stundentage verkürzen, wird der Unterschied bemerkt. Wenn Sie Ihr Vorgesetzter fragt, warum Sie Ihre Arbeit nicht erledigen, können Sie darauf hinweisen, dass Sie einen Punkt gemacht haben, um ihn zu warnen, dass dies der Fall wäre.

Schritt 2: Machen Sie sich Notizen

Nur weil Sie keine Zeit haben, die Arbeit zu erledigen, heißt das nicht, dass Sie es nicht einfacher machen können, wenn die Arbeit (hoffentlich) erledigt ist. Behalten Sie Ihre Ideen für die Korrektur des Codes im Auge und bringen Sie sie bei Besprechungen zur Sprache, damit andere sich Ihrer Bedenken bewusst werden. Irgendwann wirst du einen langsamen Fleck treffen oder die Leute werden anfangen zu verstehen, dass deine Bedenken Wert haben. Wenn diese Zeit gekommen ist, haben Sie bereits einige grundlegende Ideen, was zu tun ist, anstatt es trocken anzugehen, weil Sie sich eine Weile keinen Codeabschnitt mehr angesehen haben.

... der Code ist wirklich schwer zu pflegen.

Dies ist Ihr Weg ins Management. Zeigen Sie, dass die Kosten für "nur" das Beheben der Fehler und das Hinzufügen neuer Funktionen höher sind als die für das Umgestalten und Neuschreiben des Codes.

Wenn zum Beispiel mit dem aktuellen Code eine neue Funktion 2 Wochen zum Hinzufügen und dann eine erhebliche Zeit zum Verwalten benötigt (z. B. 1 Tag pro Woche), zeigen Sie, dass Sie mit dem Refactoring einer Woche die Entwicklung in 1 1/2 erledigen können Wochen, aber Sie werden die Wartung auf 1 Tag pro Monat (oder weniger) reduzieren. Diese Zahlen zeigen, dass das, was Sie tun, mittel- bis langfristig kostengünstig ist, auch wenn es kurzfristige Kosten gibt.

Das Unternehmen mag es zwar nicht, das Geld jetzt auszugeben, aber es wird sich herausstellen, dass die potenziellen Vorteile viel größer sind - dh Sie werden produktiver, indem Sie in kürzerer Zeit mehr Code generieren, und der Code wird eine bessere Qualität aufweisen.

Wenden Sie die Pfadfinder-Regel an : Lassen Sie den Code bei jeder Berührung etwas aufgeräumter (dh mit weniger technischen Schulden).

Lassen Sie bei allen Schätzungen, die Sie machen, etwas Zeit. Dann wird im Laufe der Zeit die technische Verschuldung auf magische Weise verschwinden und Sie werden dafür bezahlt.

Dieser Ansatz ist viel einfacher , als explizit zu schnitzen Zeit versucht (und damit Kunden / Manager zu überzeugen , Pay) für technische Schulden. Es gibt Ihnen ein viel besseres Gefühl von Professionalität und eine "gut gemachte Arbeit". Und schließlich werden sich Ihre Kunden und Manager langfristig dafür bedanken, auch wenn sie nicht ganz verstehen, wie es passiert ist .....

Dies ist mehr oder weniger die traurige Realität der Wartungsprogrammierung. Sie bleiben bei dem, was Sie zu warten haben, und wenn die Person, die die Rechnungen bezahlt, nicht für Änderungen zahlen möchte, die sie für ohne Nutzen hält, werden diese Änderungen in der Regel nicht durchgeführt.

Wenn Sie begründen möchten, dass diese Änderungen finanziert werden, führen Sie ein Protokoll aller Stellen, an denen Sie Änderungen vornehmen müssen, um selbst die einfachste Aktualisierung durchzuführen. Besprechen Sie dieses Protokoll nach einigen Änderungen mit Ihrem Manager. Wenn Sie es dokumentieren können, besteht die Möglichkeit (wenn auch sehr gering), dass die Person mit den Geldbeuteln merkt, dass es auf lange Sicht günstiger ist, den Code jetzt zu bereinigen, da dadurch zukünftige Änderungen billiger werden.

Ihre Verkaufschancen erhöhen sich, je länger dieses Produkt voraussichtlich in Gebrauch ist. Die Gewinnchancen erhöhen sich auch, wenn ein Produktfehler zu Problemen bei der Öffentlichkeitsarbeit für den Kunden führen oder ihn Geld kosten kann.

Wenn Sie dies nicht tun, lernen Sie, was Sie können, und wechseln Sie zu einer anderen Position mit weniger Wartung.

Sie müssen Ihrem Management zeigen, wie das Unternehmen davon profitiert, wenn das Produkt überarbeitet und auf andere Weise verbessert wird.

Es ist unwahrscheinlich, dass sich der Kunde darum kümmert, ob der Code schön oder hässlich ist, solange er funktioniert, und das Management ist nicht bereit, dem Kunden zu erklären, dass das, wofür er bereits bezahlt hat, schlecht entworfen und schlecht implementiert wurde. Gleichzeitig wird das Management nicht darauf aus sein, die Kosten für die Entwicklungszeit zu tragen, die das Produkt nicht in irgendeiner sichtbaren (abrechnungsfähigen) Weise verbessern.

Sie müssen also das Management davon überzeugen, dass die von Ihnen vorgeschlagenen Änderungen dem Unternehmen helfen:

• Zeigen Sie ihnen, dass Sie durch eine bessere Architektur neue Funktionen schneller hinzufügen können.
• Erklären Sie, dass sie sich auf dem aktuellen Weg in eine Ecke malen werden.
• Nennen Sie Beispiele für Änderungen, die im aktuellen System sehr teuer sind, bei besserem Design jedoch einfach und kostengünstig wären.
• Behalten Sie die Zeit im Auge, die Sie für die Pflege von altem Code aufgewendet haben, anstatt verkaufsfähige Funktionen hinzuzufügen. - Helfen Sie ihnen, bestehenden und zukünftigen Kunden zu erklären, dass die neue, modernisierte Architektur, obwohl das vorhandene System ziemlich gut war, viele großartige neue Verbesserungen, eine bessere Zuverlässigkeit usw. ermöglichen wird.
• Reduzieren Sie das mit den von Ihnen vorgeschlagenen Änderungen verbundene Risiko. Manager sind risikoavers und umfassende Änderungen an einem vorhandenen System scheinen von Natur aus riskant zu sein.
  • Priorisieren Sie die Modernisierung der verschiedenen Komponenten nach Kosten und Nutzen und stellen Sie sicher, dass das Management mit Ihren Prioritäten übereinstimmt.
  • Verwenden Sie Komponententests, um sicherzustellen, dass modernisierte Komponenten mit dem verbleibenden Legacy-Code kompatibel sind.
• Verfolgen Sie den Fortschritt der Modernisierung. Zeigen Sie Ihre Vorteile so bald wie möglich, aber erinnern Sie alle Beteiligten daran, dass noch mehr Arbeit zu tun ist.

Sie werden es vielleicht nicht bemerken, aber Johnny Cash hat die Refactoring-Bewegung vorhergesagt und einen Song über den besten Weg geschrieben, eine große bestehende Codebasis umzugestalten.

Natürlich musste er es in eine Automobilmetapher einwickeln, damit sein Publikum sich darauf beziehen konnte.

"Stück für Stück" - Johnny Cash

Es sieht so aus, als ob Sie dem Kunden die Zeit in Rechnung stellen könnten, die die Änderung in Anspruch nehmen sollte , und auf lange Sicht immer noch WEGWEISEND voraus sind.

Wenn Sie Spaß daran haben, den Code zu bereinigen (und es scheint, als würden Sie es zumindest ein wenig tun), dann machen Sie weiter, aber brennen Sie sich nicht daran aus. Das nützt Ihnen, Ihrem Unternehmen oder Ihren anderen Kunden nichts.

Stellen Sie sicher, dass Ihr Management und jeder, der mit dem Kunden zusammenarbeitet, weiß, dass der Code nicht in der besten Form ist, damit er eine fundierte Entscheidung treffen kann. Wenn sie sich der Probleme mit dem Code nicht bewusst sind, können sie ihre Arbeit nicht erledigen.

Vergessen Sie nicht, dass die Anwendung des Kunden eine gewisse technische Verschuldung aufweist. Wahrscheinlich wurde ihnen ein leichter Rabatt in Rechnung gestellt. Möglicherweise wurden sie nicht darauf aufmerksam gemacht, aber genau das passiert, wenn Sie das niedrigste Gebot abgeben.

Sie müssen sich entscheiden, ob sie den vollen Preis für die Funktionsänderungen zahlen oder auf sie verzichten möchten. Es ist ihre Wahl. Sie können sie die Entscheidung treffen lassen oder kostenlos weiterarbeiten. Sie können versuchen, die durchgeführten Aufräumarbeiten zu erwähnen, und einen kleinen Rabatt für die durchgeführten Arbeiten gewähren. Wieder ist es ihre Wahl.

Ich gehe das so an, indem ich Ihren Vorgesetzten zunächst das Konzept der technischen Verschuldung erkläre, um sicherzustellen, dass sie es bekommen. Gehen Sie unter dem Strich aus betriebswirtschaftlicher Sicht vor. Jedes Mal, wenn eine neue Funktion angefordert wird, wirkt sich die im Produkt aufgebaute technische Verschuldung auf Ihre Effizienz aus. Daher kostet jede Funktion aufgrund dieser Verschuldung etwas mehr.

Sobald sie verstanden haben, wovon Sie sprechen, versuchen Sie, für einen Teil Ihrer Zeit zu verhandeln, um die technischen Schulden zu reduzieren. In meinem Unternehmen war es uns einigermaßen gelungen, für 10% der Zeit jedes Entwicklers eine Petition einzureichen, um den technischen Schuldenabbau voranzutreiben.

Wenn Sie etwas Zeit haben, um daran zu arbeiten, stellen Sie sicher, dass Sie es tatsächlich benutzen (und machen Sie nicht nur 10% Überstunden, sondern bleiben Sie bei Ihren Waffen). Erstellen Sie einen Katalog mit technischen Schuldtiteln, priorisieren Sie diese und beginnen Sie mit dem Herausarbeiten. Sie müssen den Elefanten einen Bissen nach dem anderen essen.

Und vergessen Sie nicht, bessere Werkzeuge einzubeziehen. Resharper ist ein großartiges Refactoring-Tool, das sich in Visual Studio integrieren lässt.