So werden Sie ein besserer Ingenieur: Stahlfäden

Steel Threads sind ein leistungsstarker, aber unklarer Software-Design-Ansatz. Wenn Sie etwas über Stahlgewinde lernen, werden Sie ein besserer Ingenieur. Sie können sie nutzen, um häufige Probleme wie Integrationsschmerzen zu vermeiden. Und Sie können sie nutzen, um die Komplexität des Systemdesigns zu reduzieren.

So obskur, dass es 2013 aus Wikipedia gelöscht wurde

Wie unbekannt sind Stahlfäden? Das Konzept wurde 2013 aus Wikipedia gelöscht , weil „die Idee im Software-Engineering keine nennenswerte Rolle spielt und keine nennenswerte Berichterstattung aus namhaften Quellen erhalten hat.“ Lassen Sie uns die Berichterstattung erweitern und auch besprechen, warum dies ein so nützlicher Ansatz ist.

Was sind Stahlfäden?

Ein Stahlfaden ist ein sehr dünner Funktionsabschnitt, der sich durch ein Softwaresystem zieht. Sie werden als „Thread“ bezeichnet, weil sie sich durch die verschiedenen Teile des Softwaresystems ziehen und einen wichtigen Anwendungsfall implementieren.

Sie werden „Stahl“ genannt, weil der Faden eine solide Grundlage für spätere Verbesserungen bildet.

Mit einem Steel-Thread-Ansatz bauen Sie die dünnste mögliche Version, die die Grenzen des Systems überschreitet und einen wichtigen Anwendungsfall abdeckt.

Beispiel für einen konventionellen, problematischen Ansatz

Nehmen wir an, Sie erstellen einen neuen Dienst, um einen Teil Ihrer monolithischen Codebasis zu ersetzen. Der gebräuchlichste Weg, dies zu tun, wäre

1. Schauen Sie sich den alten Code an und ermitteln Sie die Anforderungen des neuen Systems.

   
   

2. Entwerfen und bauen Sie die APIs auf, die die von Ihnen benötigten Funktionen bereitstellen.

   
   

3. Gehen Sie in den alten Code und aktualisieren Sie die Referenzen, um die neuen APIs zu verwenden. Tun Sie es hinter einem Feature-Flag.

4. Mit dem Feature-Flag überschneiden.

   
   

5. Beheben Sie alle auftretenden Probleme, bis es funktioniert, und deaktivieren Sie bei Bedarf das Feature-Flag, um zum alten Codepfad zurückzukehren.

   
   

6. Wenn es stabil ist, entfernen Sie die alten Codepfade.

Klingt vernünftig, oder? Nun, das ist die gängigste Arbeitsweise von Softwareentwicklern, aber dieser Ansatz birgt viele Gefahren.

Welche Probleme würde ich bei diesem Projekt erwarten?

1. Es kann verlockend sein, den neuen Dienst unabhängig vom alten System aufzubauen. Schließlich könnte sich das Design purer anfühlen. Aber Sie führen auch deutlich mehr strukturelle Veränderungen ein, und zwar ohne jegliche Integration in das alte System. Dadurch verstärken sich die Integrationsschmerzen deutlich. Meine Erwartung wäre, dass alle Schätzungen für das Projekt unrealistisch sind. Und ich gehe davon aus, dass das Projekt nach Abschluss als gescheitert gilt, selbst wenn der daraus resultierende Dienst im Allgemeinen ein gutes Design aufweist.

   
   

2. Ich gehe davon aus, dass die Umstellung auf das neue System problematisch sein wird. Bei der Umstellung werden eine Reihe von Problemen aufgedeckt, die eine Rückkehr zu den alten Codepfaden oder intensive Arbeit an der Behebung von Problemen in der Endphase des Projekts erfordern.

Beides ist vermeidbar, wenn keine große Umstellung erfolgt. Beachten Sie, dass selbst die Reduzierung von mehr als einem Prozent des Datenverkehrs zum neuen Dienst mit einem Feature-Flag ein Cutover-Ansatz ist. Warum? Sie reduzieren den gesamten Verkehr um ein Prozent für alle Änderungen gleichzeitig.

Ich würde immer noch nicht erwarten, dass es gut läuft. Sie unternehmen zu große Schritte.

Beispiel für die Verwendung eines Stahlfadens

Vergleichen Sie diesen Ansatz mit der Vorgehensweise von Steel Thread.

1. Denken Sie an das neue System, das Sie aufbauen. Überlegen Sie sich einige eng gefasste Anwendungsfälle, die die Steel Threads des Systems darstellen – sie decken nützliche Funktionen im System ab, decken aber nicht alle Anwendungsfälle ab oder sind in gewisser Weise eingeschränkt.

   
   

2. Wählen Sie einen möglichst engen Ausgangsanwendungsfall, der einen gewissen Wert bietet. Beispielsweise könnten Sie eine API auswählen, von der Sie glauben, dass sie Teil des neuen Dienstes wäre.

   
   

3. Erstellen Sie die neue API in einem neuen Dienst.

   
   

4. Sorgen Sie dafür, dass es genau für diesen engen Anwendungsfall funktioniert. Für alle anderen Anwendungsfälle verwenden Sie den alten Codepfad. Bringen Sie es in die Produktion und in den vollen Einsatz. (Tipp: Sie können sogar sowohl den neuen als auch den alten Codepfad verwenden und vergleichen!)

   
   

5. Anschließend fügen Sie nach und nach die zusätzlichen Anwendungsfälle hinzu, bis Sie alle benötigten Funktionen auf den neuen Dienst übertragen haben. Jeder Anwendungsfall befindet sich in der Produktion.

   
   

6. Sobald Sie fertig sind, entfernen Sie den alten Code und die Funktionsflags. Dies ist überhaupt nicht riskant, da Sie bereits mit dem neuen System arbeiten.

Ist das nicht auch das „Würger“-Muster? Ja, aber dies kann auch für neue Projekte verwendet werden. Lesen Sie weiter für ein Greenfield-Beispiel.

Stahlfäden vermeiden Integrationsschmerzen und geben Ihnen mehr Selbstvertrauen

Integrationsschmerzen sind eine der größeren Ursachen für Last-Minute-Probleme in Projekten. Bei der Umstellung auf ein neues System treten immer unerwartete Probleme auf. Sie sollten bei allem, was eine Umstellung beinhaltet, misstrauisch sein. Machen Sie die Dinge in kleinen Schritten.

Steel Threads integrieren sich von Anfang an, sodass Sie sich nie mit großen Integrationsproblemen herumschlagen müssen. Stattdessen haben Sie die ganze Zeit über leichte Integrationsschmerzen.

Außerdem muss Ihr Dienst nie getestet werden, bevor er in Betrieb geht, da Sie ihn im Laufe der Zeit inkrementell getestet haben. Sie wissen, dass es Produktionslasten bewältigen kann. Sie haben die Netzwerklatenz bereits hinzugefügt und kennen daher die Auswirkungen.

Alle Überraschungen werden vorangetrieben und schrittweise gehandhabt, nur ein Teil der Art und Weise, wie Sie den Service schrittweise einführen.

Wichtig ist, dass Sie über ein funktionierendes, integriertes System verfügen und es bei der Arbeit am Laufen halten. Und Sie konkretisieren es im Laufe der Zeit.

Stahlgewinde können dabei helfen, Komplexität zu überwinden

Wenn Sie ein System entwerfen, ist die Komplexität sehr hoch. Die Erstellung einer Reihe von Anforderungen für das neue System kann ein herausforderndes Unterfangen sein.

Wenn Sie einen Steel-Thread-Ansatz verwenden, wählen Sie einige der Kernanforderungen aus und formulieren sie so, dass sie die Schichten des Systems durchdringen und Ihr Design in die Tat umsetzen. Es stellt eine Art Skelettstruktur für das gesamte System dar.

Die Umsetzung dieses Stahlfadens wird dann zum Grundgerüst, auf dem weitere Anforderungen aufgebaut werden können.

Somit sind Stahlfäden eine Teilmenge der Anforderungen eines Systems.

Stahlfäden können auch bei Greenfield-Arbeiten verwendet werden

Nehmen wir an, Sie implementieren einen Klon von Slack. Ihr anfänglicher Stahlfaden könnte etwa so aussehen:

„Jede nicht authentifizierte Person kann eine Nachricht in einem fest codierten #allgemeinen Raum in einem fest codierten Konto posten. Nachrichten bleiben auch bei Seitenaktualisierungen bestehen.“

Beachten Sie, wie begrenzt dieser anfängliche Stahlfaden ist. Es kümmert sich nicht um Authentifizierung, Benutzer oder Konten. Es kümmert sich um das Schreiben und Speichern von Nachrichten.

Ihr zweiter Steel Thread kann das System nützlicher machen. Sie könnten zum Beispiel einen Steel Thread haben, der es dem Verfasser der Nachricht ermöglicht, den Namen auszuwählen, unter dem er postet.

Dieser zweite Steel Thread hat eigentlich nicht viel gebracht. Sie haben immer noch keine Authentifizierung, keine Konten oder auch nur ein Konzept für einen Benutzer. Aber Sie haben einen Chatraum erstellt, der so gut funktioniert, dass Sie ihn nutzen können.

Beachten Sie außerdem, dass Sie den Stahlfaden nicht durch jeden Teil des Systems gezogen haben. Aber Sie haben die Konzepte von Benutzern und Konten gestrichen.

Stahlfäden sorgen für frühzeitiges Feedback

Beachten Sie, dass Sie in diesem Slack-Klon-Beispiel frühzeitig Feedback zu dem System erhalten, das Sie erstellen, auch wenn Sie noch nicht so viel erstellt haben. Dies ist ein weiterer wichtiger Grund für die Verwendung von Stahlfäden.

Nach nur diesen beiden Steel Threads könnte Ihr Team damit beginnen, den Chatroom ganztägig zu nutzen. Überlegen Sie, wie viel Ihr Team durch die Nutzung Ihres Systems lernen wird. Es ist ein funktionierendes System.

Vergleichen Sie das mit dem, was Sie gelernt hätten, indem Sie die Benutzer- und Kontosysteme aufgebaut, alles angeschlossen und schließlich einen Chatroom eingerichtet hätten.

Beginnen Sie mit Stahlfäden

Stahlfäden sind oft ein guter Ausgangspunkt für die Gestaltung Ihrer Projekte. Sie schaffen ein Gerüst für die weitere Arbeit. Sie nageln die Kernbestandteile des Systems fest, sodass es natürliche Orte gibt, an denen sie konkretisiert werden können.

Ich empfehle Ihnen, einen Ansatz mit Stahlgewinde auszuprobieren. Ich denke, Sie werden feststellen, dass es Ihre Projekte verändern kann. Teilen Sie mir Ihre Erfahrungen damit mit!

Stahlfäden stehen in engem Zusammenhang mit vertikalen Scheiben

Möglicherweise haben Sie schon einmal von dem Begriff „vertikales Schneiden“ gehört. Ich beschreibe das Konzept in meinem Beitrag zu Meilensteinen .

Steel Threads sind eine Software-Designtechnik, die dazu führt, dass Ihre Software in vertikalen Abschnitten bereitgestellt wird. Der Begriff wird üblicherweise zur Beschreibung der anfänglichen vertikalen Abschnitte eines Systems verwendet.

Es handelt sich um eng verwandte Konzepte, die jedoch nicht völlig gleich sind.

Ich habe auch gehört, dass Steel Threads als „Leuchtspurgeschosse“ bezeichnet werden.

Bild von Steen Jepsen von Pixabay

Diese Geschichte erschien ursprünglich unter: https://www.rubick.com/steel-threads/