Gibt es ein Anti-Pattern für historisch gewachsene Software? [geschlossen]

Gibt es ein Anti-Pattern, das ein historisch gewachsenes Softwaresystem beschreibt, bei dem mehrere Entwickler dem System gerade neue Funktionen hinzugefügt haben, aber niemand wirklich ein Auge auf die Gesamtarchitektur hat und auch keine Umgestaltungen vorgenommen wurden?

Ich denke, dies passiert, wenn das Management / der Kunde ständig nach neuen Funktionen fragt und niemand jemals etwas überarbeitet, sondern nur das hinzufügt, was andere Entwickler zuvor getan haben.

Ein Grund könnte auch sein, dass der Entwickler nur mit dem Softwaresystem überfordert ist und nicht wirklich versteht, wie es derzeit funktioniert, und dann seinen Code ganz am Ende hinzufügt / klebt (anstatt den Code umzugestalten und zu ändern).

Mit der Zeit wird es immer schwieriger, das System zu warten.

(Ich frage mich, ob es Bilder für diese Art von Anti-Pattern gibt, um dies keinem Programmierer klarer zu machen - wie ein Auto, das durch Hinzufügen von immer mehr Funktionen ohne Berücksichtigung des Gesamtdesigns gebaut wurde. Als ob jemand das Bedürfnis hätte, sich abzuschleppen Anhänger während der Rückwärtsfahrt und dann schweißt ein Ingenieur einfach eine Anhängerkupplung an die Vorderseite des Autos.

Sie beziehen sich auf technische Schulden .

Wir alle haben technische Schulden in den Produkten, die wir im Laufe der Zeit entwickeln. Refactoring ist eine der weit verbreiteten und wirksamen Möglichkeiten, um diese technischen Schulden zu reduzieren, obwohl viele Unternehmen ihre technischen Schulden nie abbezahlen. Diese Unternehmen neigen dazu, ihre Software in den kommenden Jahren als äußerst instabil zu empfinden, und die technischen Schulden werden so grausam, dass Sie sie nicht schrittweise abbezahlen können, da es zu lange dauern würde, sie auf diese Weise abzuzahlen.

Technische Schulden haben die Bezeichnung, weil sie dem gleichen Schuldenverhalten folgen. Sie erhalten die Schulden, und solange Sie weiterhin Geld ausgeben (Funktionen erstellen) und diese Schulden nicht abbezahlen, wird sie nur wachsen. Ähnlich wie bei Schulden kommt man bei zu großen Schulden an Punkte, an denen man sie möglicherweise vollständig mit gefährlichen Aufgaben wie vollständigen Umschreibungen löschen möchte. Ebenso wie die reale Verschuldung beeinträchtigt sie, da sie zu einem bestimmten Zeitpunkt anfällt, Ihre Fähigkeit, insgesamt Geld auszugeben (Features zu erstellen).

Nur um einen anderen Begriff in die Mischung zu werfen, bezieht sich Kohäsion darauf, wie gut ein System, Mikro auf den Linienpegel oder Makro auf den Systempegel, zusammenpasst. Bei einem System mit hohem Zusammenhalt passen alle Teile sehr gut zusammen und sehen so aus, als hätte ein Ingenieur alles geschrieben. Ihre obige Bezugnahme auf jemanden, der nur seinen Code ans Ende klebt, würde den Zusammenhalt dieses Systems verletzen.

Technische Schulden verwalten

Es gibt viele Möglichkeiten, technische Schulden zu verwalten. Wie bei echten Schulden ist es jedoch am besten, diese häufig zurückzuzahlen. Leider ist es wie bei einer echten Verschuldung gelegentlich besser, kurzfristig mehr zu erwirtschaften, wenn beispielsweise die Markteinführungszeit für ein Feature Ihren Umsatz verdoppeln oder verdreifachen kann. Der knifflige Teil besteht darin, diese konkurrierenden Prioritäten abzuwägen und herauszufinden , wann sich der ROI der Schulden für das gegebene Feature nicht lohnt.

Manchmal lohnt es sich also, die Schulden für einen kurzen Zeitraum aufzubauen, aber das ist selten der Fall, und wie bei allen Schulden gilt: Je kürzer der Zeitraum, desto besser. Wenn Sie also (möglichst schnell ) technische Schulden angehäuft haben, müssen Sie diese zurückzahlen. Dies sind die gängigen Ansätze:

• Refactoring
  • Auf diese Weise können Sie Code-Teile, die erst während oder nach Abschluss der Implementierung als fehlerhaft erkannt wurden, an die richtige Stelle verschieben (oder auch an eine korrektere Stelle).
• Umschreiben
  • Das ist wie eine Insolvenz. Es wischt den Schiefer sauber, aber Sie beginnen mit nichts und haben jede Gelegenheit, die gleichen oder noch größere Fehler zu machen. Ein Ansatz mit hohem Risiko und hohem Ertrag für technische Schulden, aber manchmal ist dies Ihre einzige Option. Dies ist jedoch seltener der Fall, als viele Ihnen sagen werden.
• Architekturübersicht
  • Dies ist eher ein aktiver Ansatz zur Tilgung technischer Schulden. Dies geschieht, indem jemand mit der Autorität über die technischen Details beauftragt wird, eine Implementierung unabhängig von Projektplänen und -zeitplänen anzuhalten, um sicherzustellen, dass weniger technische Schulden anfallen.
• Code einfrieren
  • Das Einfrieren des Änderungscodes kann Ihnen Raum zum Atmen geben, in dem Ihre Schulden nicht steigen oder sinken. Dies gibt Ihnen Zeit, um Ihren Ansatz zur Reduzierung der technischen Schulden zu planen, in der Hoffnung, den höchsten ROI für Ihren Ansatz zu erzielen.
• Modularisierung
  • Dies ist wie ein Tier-2-Ansatz, der nur verfügbar ist, wenn Sie entweder die Architekturübersicht verwenden, um bereits ein modulares System zu haben , oder Refactoring, um zu einem zu wechseln. Wenn Sie ein modulares System haben, können Sie Schulden in ganzen Teilen des Systems auf isolierte Weise abbezahlen. Auf diese Weise können Sie tun partielle Wieder schreibt, teilweise Refactoring sowie die Minimierung der Rate technischen Schulden entstanden sind, weil die Isolierung der Schulden hält nur in jenen Bereichen , in denen die Merkmale in ging, als um das System zu Spread gegenüber .
• Automatisierte Tests
  • Automatisierte Tests können bei der Verwaltung Ihrer technischen Schulden hilfreich sein, da sie Ihnen helfen können, Problemstellen im System zu identifizieren, hoffentlich bevor die Schulden in diesen Bereichen sehr groß geworden sind, aber selbst dann, wenn sie Ingenieure auf diese gefährlichen Bereiche aufmerksam machen können vielleicht noch nicht realisiert. Sobald Sie automatisierte Tests haben, können Sie außerdem Dinge freier umgestalten, ohne sich Sorgen machen zu müssen, dass Sie zu viel kaputt machen. Nicht weil Entwickler nichts kaputt machen, sondern weil sie herausfinden, wann sie etwas kaputt machen. Wenn sie sich auf manuelle Tester in hoch verschuldeten Systemen verlassen, haben sie in der Regel eine schlechte Erfolgsbilanz bei der Suche nach Problemen.

Ihre Beschreibung passt zu Foote und Yoders Big Ball of Mud :

In den letzten Jahren haben eine Reihe von Autoren Muster vorgestellt, die Software-Architekturen auf hoher Ebene charakterisieren. In einer idealen Welt wäre jedes System ein Beispiel für ein oder mehrere solcher Muster auf hoher Ebene. Dies ist jedoch nicht so. Die Architektur, die in der Praxis tatsächlich vorherrscht, muss noch diskutiert werden: der BIG BALL OF MUD .

Ein BIG BALL OF MUD ist willkürlich aufgebaut, weitläufig, schlampig, Klebeband und Draht, Spaghetti-Code-Dschungel. Wir haben sie alle gesehen. Diese Systeme zeigen unverkennbare Anzeichen eines unregulierten Wachstums und eine wiederholte, zweckmäßige Reparatur. Informationen werden häufig zwischen entfernten Elementen des Systems ausgetauscht, häufig bis zu dem Punkt, an dem nahezu alle wichtigen Informationen globalisiert oder dupliziert werden. Die Gesamtstruktur des Systems war möglicherweise nie genau definiert. Wenn ja, könnte es bis zur Unkenntlichkeit erodiert sein. Programmierer mit einem Hauch architektonischer Sensibilität meiden diese Sumpfgebiete. Nur wer sich nicht um Architektur kümmert und vielleicht mit der Trägheit der alltäglichen Arbeit vertraut ist, die Löcher in diesen ausfallenden Deichen zu flicken, ist damit zufrieden, an solchen Systemen zu arbeiten ...

Warum wird aus einem System ein BIG BALL OF MUD? Manchmal entstehen aus THROWAWAY CODE große, hässliche Systeme . THROWAWAY-CODE ist ein schneller und unsauberer Code, der nur einmal verwendet und dann verworfen werden sollte. Trotz gelegentlicher Struktur und mangelhafter oder nicht vorhandener Dokumentation nimmt ein solcher Code jedoch oft ein Eigenleben an. Es funktioniert, warum also beheben? Wenn ein verwandtes Problem auftritt, besteht die schnellste Möglichkeit, es zu beheben, darin, diesen Arbeitscode zweckmäßig zu ändern, anstatt ein ordnungsgemäßes, allgemeines Programm von Grund auf zu entwerfen. Mit der Zeit erzeugt ein einfaches Wegwerfprogramm einen BIG BALL OF MUD.

Sogar Systeme mit genau definierten Architekturen sind anfällig für strukturelle Erosion. Der unerbittliche Ansturm sich ändernder Anforderungen, die ein erfolgreiches System stellt, kann seine Struktur allmählich untergraben. Systeme, die früher aufgeräumt waren, werden mit zunehmendem PIECEMEAL GROWTH immer größer, sodass sich Elemente des Systems unkontrolliert ausbreiten können.

Wenn eine solche Ausbreitung unvermindert anhält, kann die Struktur des Systems so stark beeinträchtigt werden, dass es aufgegeben werden muss. Wie bei einer verfallenden Nachbarschaft kommt es zu einer Abwärtsspirale. Da das System immer schwerer zu verstehen ist, wird die Wartung teurer und schwieriger. Gute Programmierer lehnen es ab, dort zu arbeiten. Investoren ziehen ihr Kapital ab. Und doch gibt es wie in den Stadtvierteln Möglichkeiten, diesen Niedergang zu vermeiden oder sogar umzukehren. Wie bei allem anderen im Universum erfordert das Gegenwirken gegen entropische Kräfte eine Investition von Energie. Software- Gentrifizierung ist keine Ausnahme. Der Weg, Entropie in Software zu stoppen, besteht darin, sie umzugestalten. Ein nachhaltiges Engagement für das Refactoring kann verhindern, dass ein System in einen BIG BALL OF MUD übergeht ...

• ... Einer der effektivsten Feinde des Schlamms ist der Sonnenschein. Indem Sie den verschachtelten Code einem Prüfpfeil unterwerfen, können Sie die Voraussetzungen für dessen Überarbeitung, Reparatur und Wiederherstellung schaffen. Code Reviews sind ein Mechanismus, mit dem man Code dem Tageslicht aussetzen kann.