Dieser Artikel über technische Schulden hat einige gute Punkte, darunter:

An den "technischen Dingen" zu arbeiten funktioniert am besten, wenn es von Geschichten getrieben wird. Die Codebasis muss wahrscheinlich überall bearbeitet werden, aber die Auszahlung erfolgt nur dort, wo der Code aus benutzerbezogenen Gründen bearbeitet werden soll. Wenn keine Geschichten durch eine unübersichtliche Gegend gehen, ist die Arbeit daran größtenteils vergeudet.

Daher bevorzuge ich es, Geschichten wie gewohnt aufzunehmen (aber wahrscheinlich weniger) und der "Pfadfinder-Regel" zu folgen, den Campingplatz besser zu verlassen, als Sie es vorgefunden haben. Mit anderen Worten, wo immer uns die Geschichten hinführen, lassen Sie uns mehr Tests schreiben und aggressiver umgestalten.

Dieser Ansatz hat mindestens die folgenden Vorteile:

• behält den "vernünftigsten" Fluss von Geschichten bei;
• bietet Hilfe von allen Team-Talenten;
• sorgt dafür, dass das gesamte Team lernt, wie man Code sauber hält;
• fokussiert die Verbesserung genau dort, wo sie benötigt wird;
• verschwendet keine Verbesserung, die "möglicherweise" benötigt wird;

Ich habe gesehen, dass die Codequalität einen großen Einfluss auf die langfristige Produktivität hat. Daher bin ich der Überzeugung, dass technische Schulden beseitigt werden sollten. Ich denke, der obige Beitrag macht Sinn, aber ich bin mir nicht so sicher, was die letzten beiden Punkte angeht. Ich bin daran interessiert, echte Erfahrungen mit den Vorteilen der Reinigung von technischen Schulden zu machen, auch wenn es nicht um User Stories ging.

Welche positiven Vorteile haben Sie gesehen, wenn Sie Ihre Codebasis aufgeräumt und sich von technischen Schulden befreit haben? Mit welchen Methoden haben Sie die Arbeit erledigt?

Ich kann Ihnen ein Beispiel aus meiner Erfahrung geben.

Vor ungefähr 10 oder 12 Jahren habe ich eine Anwendung von einem Entwicklerteam geerbt, das das Unternehmen am Ende verlassen hat (zu lange, um hier reinzukommen ...). Das System war ein großes, selbst entwickeltes Middleware-Berichterstellungssystem. Es lief jede Woche abends und erzeugte ungefähr 2 Dutzend Excel-Berichte für leitende Angestellte eines Fortune 500-Unternehmens. Als ich es geerbt habe, hat es ungefähr 5-6 Stunden gedauert und in einer bestimmten Woche fielen mindestens 2 Nächte aus.

Ich war kein glücklicher Camper, dieses Durcheinander zu bekommen.

Zunächst wollte ich nur die Blutung stoppen und die Hauptursache für die Ausfälle beheben. Nachdem ich mich mit der Codebasis vertraut gemacht hatte, suchte ich nach Orten, an denen ich Verbesserungen vornehmen und Stabilität und Leistung hinzufügen konnte. In den letzten 2 Jahren habe ich viele, viele Änderungen am System vorgenommen. Wir haben dieses System vor ein paar Jahren eingestellt und zu diesem Zeitpunkt dauerte der gesamte Prozess 45 Minuten und hatte seit Jahren keine Probleme mehr.

Es wurde viel Arbeit in die Tilgung der technischen Schulden gesteckt, aber es hat sich gelohnt. Es war schön, mitten in der Nacht, in der das System ausfiel, keine Anrufe zu bekommen. Es war schön, im Büro des Monrings zu sein und nur gute Nachrichten in den Protokollen zu sehen.

(Nebenbei ... Nach ein paar Jahren traf ich einen der Hauptentwickler dieses Systems. Er fragte mich, wie es funktioniere und ich sagte ihm, wie schlimm das System sei. Er entschuldigte sich tatsächlich und sagte mir, er wisse, dass es sein würde eine Handvoll zur Unterstützung, nachdem er gegangen war und wünschte, er hätte einen besseren Job gemacht).

Ich habe die Erfahrung gemacht, dass die Vorteile der Codebereinigung am deutlichsten sichtbar sind, wenn ich Code dort pflegen muss, wo die Bereinigung nicht durchgeführt wurde. Wo die Bereinigung durchgeführt wurde, bestehen meine Änderungen darin, den Code zu lesen, die einen oder zwei Stellen zu finden, die geändert werden müssen, und von dort weiterzugehen. Wenn die Bereinigung noch nicht durchgeführt wurde, fügen Sie ein paar Mal einen ersten Schritt hinzu, in dem Sie den Code lesen und herausfinden, was der Autor (manchmal ich) gedacht hat, als er ihn geschrieben hat.

Die Beseitigung von technischen Schulden führt zu weniger technischem Support und einer besseren Grundlage für Verbesserungen

immer

Eine Erfahrung, die ich hatte, war, als ich ein Site Performance-Team bei meinem vorherigen Arbeitgeber leitete. Jede Nacht fiel die von meinem Team überwachte Website für einen Zeitraum von einer Stunde bis zu zwei Stunden unter die zulässigen Leistungsschwellen, da ein Bot schnell Informationen von der Website abräumte. Die Maßnahmen, die das Team ergriffen hatte, bestanden darin, sich in ein manuelles Administrationssystem einzuloggen und die IP-Adressen zu blockieren, die die Probleme verursachten. Unnötig zu erwähnen, dass dies fast jede Nacht ein Mitglied des Teams Stunden Schlaf gekostet hat. Ich bemerkte, was passierte, und nahm den BlackBerry selbst für einige Tage in Anspruch, um zu sehen, wie schlimm es war, und gab meinem Team etwas Ruhe.

Nach ein paar Tagen ging ich einfach zum Geschäftsinhaber des Teams und ließ sie wissen, dass wir wahrscheinlich verlieren würden, wenn wir kein automatisiertes Blockierungssystem implementieren würden, so dass Bots eine viel schwierigere Zeit haben würden, die Leistung der Site zu beeinträchtigen Einige, wenn nicht alle Teammitglieder aufgrund von Müdigkeit und Burnout. Sie waren sich einig, und wir implementierten ein System, mit dem wir nachts schlafen konnten. Dem Geschäftsinhaber war klar, dass die Kosten für einige Tage oder eine Woche Entwicklung im Vergleich zu den Kosten für die Einstellung / Ausbildung neuer Ingenieure minimal waren.

In Bezug auf die letzten beiden Punkte: Ich verstehe, woher es kommt, wie in seinem ursprünglichen Beitrag erklärt :

Oder ist es möglich, einige Entwickler neu zu beauftragen, um diese technischen Angelegenheiten zu erledigen, während der Rest des Teams mit den benutzerorientierten Dingen weitermacht? Dies kann die Geschwindigkeit des Teams beeinflussen, aber was nun?

"Also was" ist gleichbedeutend: Der Product Owner und andere Geschäftsleute werden unglücklich. Und wenn Mama unglücklich ist, sind alle unglücklich.

Die Grenze zwischen dem, was getan werden muss und dem, was getan werden kann, ist jedoch ziemlich vage. User-faced ist sehr breit und umfasst die Leistung und das Auftreten von Fehlern. In einigen Fällen liegt das zugrunde liegende Problem der schlechten Leistung und des Auftretens von Fehlern jedoch tiefer im Code. Um es in seinen Worten auszudrücken: Eine Geschichte geht vielleicht nicht durch eine krumme Gegend, aber diese krumme Gegend kann einige üble Dinge verbergen, die die Geschichte auf dem aufgeräumten Weg daneben angreifen.

Dinge, die die Gesamtleistung nicht beeinflussen, sind weniger interessant zu bereinigen, aber man sollte den Einfluss dieser Punkte sehr sorgfältig abwägen. Meistens haben sie einen indirekten Einfluss, der beträchtlich sein kann.

Der größte Vorteil, den eine Organisation durch die Tilgung von technischen Schulden erhält, ist die Vermeidung von Zinseszinsen. In dem folgenden Blog-Eintrag ist ein Beispiel aufgeführt, das zeigt, wie sich der Kapitalbetrag für eine technische Schuld in nur fünf Jahren von 160.000 USD auf 430.000 USD erhöhte. Es würde einen Vollzeit-Programmierer brauchen, der sich ausschließlich mit der Bedienung dieser Schulden befasst. Das wird dazu beitragen, es für die Entscheidungsträger in die richtige Perspektive zu rücken!

Von blog.acrowire.com .