Was sind technische Schulden und können Sie sie vermeiden?

Wenn Sie in der Softwareentwicklung tätig sind, müssen Sie sich irgendwann mit technischen Schulden auseinandersetzen. Um also die Frage im Titel zu beantworten… nein, Sie können es nicht vermeiden. Es gibt jedoch Schritte, die Sie unternehmen können, um die Auswirkungen zu minimieren und sicherzustellen, dass es nicht außer Kontrolle gerät. Zumindest zu schlecht.

Was sind technische Schulden?

Tech-Schulden, wie sie manchmal genannt werden, sind im Wesentlichen die Kosten, die Ihnen im Laufe der Zeit für einen unvollkommenen Code entstehen. Änderungen und Aktualisierungen des Quellcodes haben ihren Preis, ebenso wie das Hinzufügen eines neuen Mitglieds zum Entwicklerteam, das Hinzufügen einer neuen Funktion oder das Beheben von Fehlern und das Patchen von Exploits.

Wenn Ihr Projekt größer wird, die Codebasis wächst und mehr Leute an diesem Code arbeiten, werden ihre Stimmen und Stile hier und da kollidieren. Vielleicht haben Sie eine Frist und eine nicht ideale Lösung wird in den Quellcode gepatcht, um rechtzeitig fertig zu werden. Vielleicht fügen Sie eine Open-Source-Komponente hinzu, die Sie nicht vollständig verstehen, um ein Feature zu handhaben, anstatt es selbst zu programmieren. Oder Sie könnten Bibliotheken zwischen Versionen wechseln (z. B. von Backbone zu React), müssen aber trotzdem Leute unterstützen, die die Legacy-Codebasis für ihre Projekte verwenden.

Absolut keines dieser Dinge ist schlecht . Nicht auf eigene Faust. Vielleicht gar nicht. Aber zusammengenommen müssen die entstandenen technischen Schulden irgendwann in der Zukunft zurückgezahlt werden.

Irgendwann muss diese Open-Source-Komponente möglicherweise ersetzt (oder gegabelt) werden. Das wird Zeit und Geld kosten. In ferner Zukunft müssen Sie den gesamten Backbone-Code aus Ihrem Projekt entfernen und die Unterstützung älterer Benutzer einstellen. Wieder Zeit und Geld. Der Patch, den Sie gemacht haben, um eine Frist einzuhalten? Nun, es wird irgendwann rückgängig gemacht und braucht eine dauerhaftere Lösung. Zeit und Geld. Und Sie werden neue Mitglieder Ihres Teams haben, die für all dies den alten Code durchgehen und den Code und die Logik früherer Entwickler verstehen müssen. Zeit. Geld.

Du verstehst es.

Während technische Schulden ein abstrakter, oft metaphorischer Begriff sind, sind die Kosten für technische Schulden sehr real. Die Rückzahlung hat einen Geldwert, und Sie können die Zinsen, die Sie dafür zahlen, in Arbeitsstunden und Gehaltsabrechnungen verfolgen. Sie können es in der unteren Zeile jeder Softwareentwicklung sehen.

Können Sie Tech-Schulden vermeiden?

Wie ich schon sagte… nicht wirklich, nein. Sie werden in jedem Projekt, das Sie schreiben, technische Schulden anhäufen, wenn Sie nach seiner Veröffentlichung jemals auf den Code zurückgreifen. Wenn Sie jedoch die Arten der technischen Schulden aufschlüsseln, können Sie diese in Ihren Projekten minimieren und sogar berücksichtigen. Wenn Sie die Schulden im Voraus berücksichtigen, ist es nicht anders, als einen Autokredit oder eine Hypothek aufzunehmen. Sie schauen sich die Kosten, die Zinsen und die Vorteile an und entscheiden dann, ob Sie es bezahlen können/wollen.

Sehen wir uns einige der oben besprochenen Beispiele an und sehen wir, ob es eine Möglichkeit gibt, die Kosten zu vermeiden, zu minimieren oder zu absorbieren.

Berücksichtigung gezielter technischer Schulden

Wenn wir von zielgerichteter technischer Schuld sprechen, meinen wir, dass Ihr Team Entscheidungen getroffen hat, von denen Sie wissen, dass sie weder für die Sprache noch für die Art des Projekts, an dem Sie arbeiten, den sogenannten Best Practices entsprechen. Wir haben bereits erwähnt, dass Sie möglicherweise eine Frist einhalten müssen. Und vielleicht ist diese Frist hart und schnell. Vielleicht besteht eine Chance von 0%, dass es geändert oder verschoben wird.

In diesem Fall müssen Sie erwägen, einen Kredit aufzunehmen und technische Schulden aufzunehmen.

Du hast hier wirklich drei Möglichkeiten:

• Veröffentlichen Sie unfertige und fehlerhafte Software, aber Sie machen keine Zugeständnisse an Codeklarheit und Logik
• Ziehen Sie Funktionen, die Sie nicht perfektionieren können, aber veröffentlichen Sie, was Sie haben, das so gut wie möglich geschrieben ist
• Treffen Sie Entwicklungsentscheidungen, die „gut genug“ Code ausgeben, um alles zum Laufen zu bringen, aber wahrscheinlich später noch einmal angesprochen werden müssen

Die dritte Option ist hier oft diejenige, die die Leute wählen. Das geht in technische Schulden. Und daran ist nichts auszusetzen. Weil Sie sich dafür entschieden haben .

Rückzahlung des Darlehens für zweckgebundene Schulden

Stellen Sie sicher, dass Sie die Entscheidungen hinter der Entscheidung für diesen Weg in Ihrem Code dokumentieren. Machen Sie sich Notizen darüber, was Sie getan haben und was die ideale Lösung wäre. Und stellen Sie sicher, dass Sie zumindest einen Kommentar in den Quellcode einfügen, um anzugeben, wo diese Schuldenaufnahmelösung implementiert wurde (und wenn Sie wissen, betroffene Systeme in anderen Bereichen des Projekts). Wenn Sie diesen Schritt nicht unternehmen, kann das Hinzufügen zum Projekt (auch bei Bugfixes und Patches, ganz zu schweigen von neuen Funktionen oder einer erweiterten Codebasis) schrecklich verzögert werden, indem Sie eine Patchwork-Lösung finden, wenn Sie eine vollständige erwarten.

Auch hier könnte diese Patchwork-Lösung völlig in Ordnung sein und Ihnen nie wirkliche Probleme bereiten. Aber die technischen Schulden sind immer noch da und müssen berücksichtigt werden.

In Anbetracht der technischen Schulden des Legacy-Codes

Eine weitere häufige Art von technischer Schuld ist eine, die WordPress derzeit häufig anhäuft. WordPress kann auf PHP 5.x laufen. Das neueste Update teilt den Benutzern jedoch mit, dass es mindestens PHP 5.6 sein muss. Bis Ende 2019 benötigt der WP Core PHP 7.x. Durch das Hochschieben der Anforderungen muss jedoch viel alter Code aktualisiert werden. Denn es gibt immer noch PHP 5.x-Code in Plugins, Themes und Core selbst.

Ganz zu schweigen vom neuen Blockeditor. Es ist in JavaScript geschrieben. Reagiere konkret. Das ist nichts in der Nähe von PHP. Tatsächlich wird ein Großteil des WordPress-Kerns nach und nach in JavaScript umgeschrieben. Aber all das muss JS auch ergänzen und mit dem PHP auskommen. Es ist großartig, sich mit neuen Technologien zu befassen, und es ist notwendig, neue Versionsanforderungen zu übernehmen. Aber damit zahlen Sie Zinsen für die unvermeidlichen technischen Schulden, die Ihnen durch das längere Bestehen dieser Software entstehen.

Die Schulden von Legacy Code zurückzahlen

Dies ist etwas schwierig, weil es keine gute Möglichkeit gibt, es zu tun. Sie könnten die nukleare Option wählen und in der neuen Sprache/dem neuen Framework/der neuen Version von Grund auf neu schreiben (schauen Sie sich an, was wir zwischen Divi 2 und Divi 3.0 gemacht haben, von Backbone.js zu React). Dies behebt das Problem der Schulden jedoch immer noch nicht vollständig, da Sie immer noch Leute haben, die die alte Bibliothek verwenden. Irgendwann müssen Sie die Unterstützung für die Legacy-Codebasis einstellen. Das ist so etwas wie die Rückzahlung des Kredits. Bis du den nächsten rausnehmen musst.

Wenn dies keine Option (oder die beste Idee für Sie) ist, können Sie sicherstellen, dass Sie sich nicht auf sprach- oder versionspezifische Funktionen verlassen. Frontend-Entwickler müssen sich ständig damit auseinandersetzen, da einige Browser brandneue Funktionen schnell unterstützen, während andere (Microsoft Edge/IE, Hustenhusten) dies möglicherweise nie übernehmen. Sie können Ihre Projekte zukunftssicher machen, indem Sie sich an die Grundlagen halten, was wiederum dazu führt, dass die Anzahl der Änderungen, die beim Upgrade oder Refactoring berücksichtigt werden müssen, geringer ist als sonst.

Berücksichtigung mehrerer Entwickler im Laufe der Zeit

Dies ist eine Art von Technologieschulden, die große Teams im Laufe der Zeit stärker anhäufen als kleine Entwicklerteams. Aber auch kleine müssen sich darum kümmern. Sie sehen, jeder Softwareentwickler schreibt Code anders. Sehr selten werden Sie zwei Entwickler haben, die dasselbe Problem mit genau demselben Code lösen. Sie können dieselbe Funktion ausführen und das Endergebnis kann dasselbe sein, aber der Code wird in der Stimme des Autors geschrieben (genauso wie Sie sehen können, wer hier Beiträge geschrieben hat, z. B. Jason, Nathan, Donjete und Ich habe alle unterschiedliche Stile). Code ist nicht anders.

Vor diesem Hintergrund kann die Logik manchmal auch unterschiedliche Stimmen haben. Was ein Entwickler denkt, ist völlig klar, ein anderer Entwickler wird sich das ansehen und keine Ahnung haben, warum der Code tut, was er tut. Dieses Problem wird wirklich problematisch, wenn der ursprüngliche Autor nicht mehr zur Verfügung steht. Die dadurch entstehenden technischen Schulden können katastrophal sein. Aber es gibt Möglichkeiten, damit umzugehen.

Die technischen Schulden der alten Entwickler zurückzahlen

Der einfachste Weg ist, die bestmöglichen Entwickler einzustellen und sie niemals Ihr Unternehmen verlassen zu lassen. Je.

Da dies nicht in 100 % der Fälle der Fall sein wird, kann die Rückzahlung dieser Schulden etwas einfacher erfolgen, als Sie vielleicht denken. Stellen Sie zunächst sicher, dass Sie Ihr Entwicklerteam darin schulen, ihren Code zu kommentieren. Und das gut zu kommentieren. Wann immer sie eine Entscheidung treffen, die von jemand anderem auch nur im Entferntesten als mehrdeutig angesehen werden könnte, lassen Sie sie notieren, warum sie es getan haben und wie die Funktion funktioniert.

Stellen Sie außerdem sicher, dass sich jeder Entwickler in Ihrem Team an einen Styleguide oder eine Reihe von Standards hält. Der WordPress Core verfügt über eine Reihe von Codierungsstandards, die Plugins, Themes und Core-Beiträge inline halten, damit alle anderen, die später kommen, keine Probleme damit haben. Airbnb hat einen Styleguide für React, der als branchenweiter inoffizieller Standard übernommen wurde. Sogar interne Styleguides und Standards halten Ihre Entwickler davon ab, alleine zu weit zu gehen, da diese Art von Commits nicht zusammengeführt werden, es sei denn, sie sind dem Schnupfen gewachsen.

Einpacken

Technische Schulden sind ein sehr reales Problem. Es ist auch eine sehr reale Ressource, wenn Sie wissen, wie man es verwaltet. Indem Sie entscheiden können, wann Sie Tech-Schulden aufnehmen und wie Sie diese zurückzahlen, kann Ihre Entwicklung schneller und reibungsloser als sonst möglich verlaufen. Und in Zeiten, in denen diese Last unvermeidlich ist, hoffen wir, dass wir Ihnen einige Ideen für Strategien gegeben haben, die Sie implementieren können, um die Wirkung zu verringern, als sie sonst sein könnte.

Wie gehen Sie mit technischen Schulden in Ihren Projekten und Entwicklungsteams um?

Beitragsbild des Artikels von Andrey Suslov/shutterstock.com