Dieser Artikel wurde maschinell übersetzt.

Innovationen

Katastrophen Software: Recovery und Strategien zur Verhütung

Dino Esposito

 

Wie nachdrücklich, wie es klingen mag, hängt unser Leben Software. Als Benutzer verschiedener Dienste selbst wissen wir sehr gut, dass Software wie erwartet funktioniert wirklich unser Tag speichern kann. Aber Software ist weil es hat die Komplexität der realen Prozesse modellieren immer komplexer. IT-Manager, Architekten und Entwickler müssen mit fertig werden.

In diesem Artikel werde ich Practices überprüfen, mit deren Hilfe eine verschlechterte System beheben und zeigen Ihnen, Muster, die von der wachsenden unkontrolliert auf ein System verhindern können. Der Begriff "big Ball of Mud" (BBM) wurde vor Jahren geschaffen, um auf ein System, die weitgehend unstrukturierten und mit gepolsterten versteckten Abhängigkeiten zwischen Teilen, mit vielen Daten und Code Duplizierung und unklar Identifizierung der Ebenen und Anliegen verweisen – ein Spaghetti-Code Dschungel. Lesen Sie mehr über die BBM, empfehle ich eine ausgezeichnete Arbeit von Brian Foote und Joseph Yoder von der University of Illinois at Urbana-Champaign, die Sie, von herunterladen können http://bit.ly/nfPe2Y. In diesem Whitepaper verurteilen nicht die Autoren einen BBM als das Schlimmste jemals Problem; nur empfehlen Architekten und Entwickler bereit sein, das BBM Risiko ausgesetzt, und erfahren, wie es unter Kontrolle zu halten.

Die Dynamik der Software-Systeme

Vor 30 Jahren in den Beginn der Ära Software wurden Anwendungen sehr viel einfacher als heute schreiben. Wir hatten keine Notwendigkeit für Benutzeroberflächen. Wir hatten nicht viel über Ästhetik Sorgen machen, Distribution Skalierbarkeitsprobleme oder Bereitstellungsprobleme benötigt. Und last but not least, hatten wir viel weniger Geschäftslogik zu implementieren.

Zur Zeit Software-Entwicklung ernst genommen wurde und die kompetentesten beteiligt. Ziemlich erstaunlich musste in den frühen 1990er Jahren bereits die meisten Software-Entwicklung und Architektur Prinzipien und Mustern angeordnet. Wohl hat sehr wenig "seit erfunden wurde". Prinzipien wie die Trennung von Bedenken und Abhängigkeitsumkehr, waren nicht Paradigmen wie objektorientierte Programmierung (OOP) und Aspekt-Orientierung und Praktiken wie Entwerfen testbarer Anwendungen in den letzten Jahren entwickelt. Viele von ihnen neu entdeckt und von Architekten und Entwickler heute angewendet werden, aber sie bereits seit Jahrzehnten.

Aber Warum haben diese Grundsätze und Praktiken gelogen in einer Art Schwebezustand jahrelang? Kann es viele Gründe dafür, aber einem gemeinsamen Developer Refrain ist, "Es funktioniert, also Warum sollte ich es verbessern (und die Kosten dieser zusätzlichen Zeit verschwenden)?"

Unterschiedliche Dynamik der Java und Microsoft Welten

In der Mitte der 90er Jahre aufgefordert, das Aufkommen der Objektorientierung und Sprachen wie z. B. Java (mehr als C++) viele Unternehmen ihre Software, größere Blöcke der Geschäftslogik von Datenbanken und Mainframes verschieben neu strukturieren. Java-Entwickler hatte speziell im Unternehmensbereich, zur Bewältigung komplexer als die im rapid Application Development (RAD), in der Regel zugeordnete Visual Basic-Programmierung. Es ist nicht überraschend, dass dieser Aspekt-Orientierung, Dependency Injection Frameworks (z. B. Spring) und relationale und Objektzuordnungen (z. B. Ruhezustand) – ganz zu schweigen von eine lange Liste von Programmiertools (z. B. NUnit, Ant, Javadoc, Maven usw.) – in der Welt Java stammt. Sie waren Tools erstellt, die von Entwicklern für Entwickler, um die Auswirkungen der Komplexität zu glätten.

Zur gleichen Zeit war RAD in der Welt Visual Basic, der letzte Schrei. Visual Basic Half Unternehmen nice front-Ends über gespeicherte Prozeduren erstellen, wenn keine Mainframe-Code verwenden. Das Aufkommen von Web Services erstellt eine zusätzliche Fassade und gab Mainframe-Code der schöner Name "legacy-Dienste".

Die OOP versus RAD Debatte in den letzten 15 Jahre war eine angemessene Konflikte. Wenn Microsoft objektorientierte Features in Visual Basic eingeführt, war es wirklich schwer zu Entwickler warum in aller Welt erklären, dass diese seltsame Features so wichtig waren. Und nicht, sie tatsächlich den geringen Komplexität dieser dünnen Anwendungen gegeben.

Die.NET-Revolution

Die Version von Microsoft.NET Framework ist zu einem entscheidenden Zeitpunkt geschehen. Es geschah, als einige große Unternehmen, die zuvor für einen RAD-Ansatz entschieden hatte genug im Internet gesehen und hatte die Back-End-Systemen, die ALT genug, um eine Wiederherstellung unter Berücksichtigung der neuen Internet-bezogenen Geschäftsprozessen zu rechtfertigen. Zur gleichen Zeit gefunden dieser Unternehmen in der Microsoft-Plattform einen zuverlässigen, leistungsstarken und erweiterbaren Rahmen. Natürlich, dauerte es nur ein paar Jahren für.NET-Entwickler mit der gleichen riesigen Menge an Komplexität überschwemmt werden, dass Java Kollegen ein Jahrzehnt zuvor erlebt. Die meisten.NET-Entwickler wuchs jedoch mit RAD-Prinzipien und dem RAD Ansatz zur Entwicklung.

In einer RAD-Welt neigen Sie lieber Code, der tatsächlich funktioniert und Anwendungen erstellen, durch Hinzufügen von Blöcken, die größtenteils unabhängig sind. (Und wenn sie nicht wirklich unabhängig sind, Sie machen sie auf diese Weise durch Missbrauch-Code und die Duplizierung von Daten).

Das Problem ist nicht mit RAD als ein Programmierparadigma. Das eigentliche Problem, das wahrscheinlich zu den berüchtigten BBM führen, ist die Anwendung RAD (oder jede andere Paradigma) ohne Korrekturen, die das Wachstum der Anwendung und anschließende Multiplikation der Komplexität, halten können unter Kontrolle.

Deaktivieren Sie die Symptome von einem BBM

Es scheint ein Naturgesetz der programmieren, die jede Einheit von jeder Größe-Software (sei es einer Klasse, einer Ebene oder ein gesamtes System) beeinträchtigt. In ihrer vorgenannten Papier nennen Foote und Yoder es "strukturelle Erosion" der Software. Persönlich mag ich es nennen, dass die biologische Abbaubarkeit von Software. Als Software-Einheiten beibehalten oder geändert werden, werden sie schwieriger weiter beibehalten oder ändern. Unabhängig von dem Namen heutzutage ist es nur Bestandteil der Deal; kann nicht ignorieren, und möchten dazu nur Schaden.

Biologische Abbaubarkeit Software ist zum schrittweisen Wachstum der Projekte eng verbunden. Eine neue Anforderung in ein vorhandenes System integrieren – das war so konzipiert, ohne dass bestimmte – ist immer problematisch. Es bedeutet nicht, dass es nicht möglich oder sollte nicht, durchgeführt werden – es bedeutet nur, dass durch das Hinzufügen einer neuen Anforderung, Sie den Kontext ändern möchten. Eine einzelne Änderung nicht in der Regel haben dramatische Auswirkungen auf Architektur, aber wenn Sie einzelne Änderungen treten häufig auf, der Kontext des Systems im Laufe der Zeit ändert und morphs in etwas, das wahrscheinlich eine andere Architektur erfordert. Dieser Prozess wird auch als Anforderungen Codeänderungen bezeichnet.

Ebenso stückweise Wachstum ist Teil des Lieferumfangs und nicht bereit, zu bewältigen, ist eines der Deadly Sins of moderne Software-Architektur. Durch Hinzufügen von neue Anforderungen eine zu einem Zeitpunkt ohne das System als Ganzes bei jedem Schritt zu überdenken, erstellen Sie die idealen Voraussetzungen für eine BBM.

Welche gemeinsamen Symptome eindeutig sagen Ihnen, dass Sie ein bisschen zu viel Schlamm im Getriebe Ihres Systems haben? Ein BBM nicht über Nacht gebildet erhalten und nicht am Anfang so groß ist. Diese Symptome, die ich nicht beschreiben werde, Adressierung hilft zu verhindern, dass es groß größer werden.

Der erste Alarm klingelt, wenn in einer Klasse eine Änderung vornehmen und brechen den Code in ein anderes, anscheinend nicht verwandten Klasse am Ende. Dies ist die unangenehme Effekt starren Software, die sich durch gewisse Widerstände, die letztlich Regression bestimmt.

Eine zweite alarm klingelt, wenn Sie nicht bei dem Versuch, eine scheinbar wiederverwendbare Stück Code wiederverwenden. Wenn derselbe Code funktioniert, nachdem es in ein anderes Projekt verschoben wird, sind die wahrscheinlichsten Ursachen schwer zu findenden Abhängigkeiten oder eng verbundene Klassen. Diese sind auch die Hauptursachen von Software Steifigkeit.

Enge Kopplung ist vorteilhaft, da es Ihnen hilft, Code schneller schreiben und wird wahrscheinlich, dass Code schneller ausgeführt. Es machen nicht, den Code jedoch verwaltbar. In ein Projekt, das Stück für Stück (wie die große Mehrheit der heutigen Projekte wächst), ist die Wartbarkeit bei weitem Attributs primäre Software, die Sie berücksichtigen möchten.

Schließlich ein drittes klingelt alarm, wenn Sie möchten, wenden Sie ein Update auf eine Funktion, aber nicht überzeugt sind, in einen idealen Fix angewendet (oder nicht zu tun), so dass Sie auf noch eine andere Problemumgehung zurückgreifen.

Jedes System kann ein Vorkommen (oder sogar ein Paar) dieser Symptome zum Glück überleben. Die zugrunde liegenden Mechanismen sind jedoch ziemlich merkwürdige. Wenn Sie eines dieser Symptome übersehen haben, können Sie das Risiko, das System mehr kompliziert machen anfallen.

Zum Beispiel Betrachten wir das zweite Symptom (manchmal auch als Bewegungslosigkeit bezeichnet). Sie müssen ein neues Feature hinzufügen und Sie überzeugt ganz leicht anzupassen und wiederverwenden eine vorhandene Funktion zu. Sie versuchen, und es funktioniert nicht, da die Klasse, die Sie gehofft wiederverwendbar sein würde, in Wirklichkeit an andere eng verbunden ist. Die Alternative, die Sie haben, ist eine größere Anzahl von Funktionen in mehrere Module importieren. In solchen Fällen ist eine Lösung für gemeinsamen (aber naive) Code duplizieren, ohne jemals versucht, eine sauberere Wiederverwendung von Klassen. Vervielfältigung des Codes das Problem vorübergehend behoben, aber nur wächst die BBM.

Mögliche Ursachen für einen BBM

Es ist selten für einen einzelnen Entwickler eine BBM erstellen. Vielmehr eine BBM hat viele Ursachen, und häufig die primäre Ursache muss außerhalb der aktuellen Ebene der Entwicklung erforscht werden. Anspruchsvolle Manager sowie Kunden, die nicht wirklich was sie wollen wissen, vermitteln Entwickler unklar und mehrdeutige Informationen. Es sei denn, das Team hat viele Software-Entwicklung im Allgemeinen erleben und in der Domäne, das automatisch zu willkürlichen Entscheidungen sukzessive führt behoben durch Kompromisse und Problemumgehungen. Der Effekt ist, dass die Gesamtarchitektur bei ihrer Gründung geschwächt ist.

Alle Beteiligten in einem Softwareprojekt kann eine Menge ein BBM zu vermeiden und die dramatische Auswirkungen Glätten tun. Betrachten Sie die grundlegenden Schritte zu ergreifen, wenn Sie sich mitten in einem BBM.

Disaster Recovery-Strategie

Wenn Sie eine BBM gegenüberstehen, ist das ideelle, was zu tun einfach die Anwendung basierend auf Anforderungen überprüft und neue Architekturoptionen umschreiben. Komplett neu geschrieben und ist jedoch nie eine Option, die Sie zu berücksichtigen sind. Wie würden Sie den Schlamm Überleben?

Foote und Yoder die einzige vernünftige Option einführen, Sie in diesen Fällen haben, mithilfe eines Abbildes eindrucksvollen: Sweep Müll unter den Teppich und gehen mit Ihrem Leben. Aber ich denke, dass ich eine Wiederherstellungsstrategie für den Notfall Software in drei Schritten zusammenfassen können. Der erste Schritt wird jede neue Entwicklung beendet. Der zweite Schritt ist wunden Punkte (wenn nicht tiered) Ebenen isolieren und Anordnen von Tools, um Rückschritte in diesen Punkten zu messen. Schließlich Sie jede dieser Ebenen isoliertes Problem abholen und, mit äußerster Sorgfalt versuchen, diese für eine sauberere und lose gekoppelten Architektur umgestalten.

Die zweite, nachdem Sie die Entwicklung auf einem schlammigen Projekt beendet beginnen Sie denken, eine Reihe von relevanten Tests. Eingebettet in ein BBM, das letzte, was Sie denken, sind klassische Komponententests. In diesem Kontext relevanten Tests sind Art von Integrationstests, die mehrere Ebenen und manchmal Ebenen erstrecken. Diese Tests sind in erster Linie laufen langsam aber – viel wichtiger – sie wird nur langsam zu schreiben. Sie müssen (wahrscheinlich groß) Chunks Verhalten isolieren und ausblenden, hinter einer Fassade, die durch Tests geboten werden kann. Schreiben einer Fassade möglicherweise nicht leicht, aber es ist in der Regel mindestens möglich. Es ist hauptsächlich eine Frage der Zeit und Arbeit. Diese Tests sind eine große Hilfe für die nächsten Schritte, denn sie Ihnen ein automatisches Tool zur Regression zu messen bieten, wie Sie mit dem letzten Schritt fortfahren. Der letzte Schritt besteht aus der Projektmappenpaketdatei Umgestaltung arbeiten, in denen das erste Problem behandelt enge Kopplung ist.

Planen einer Strategie für eine BBM zu verhindern.

Vorbeugen ist immer vorzuziehen, Behandlung. Es gibt drei kardinaltugenden eines Teams, das zu eine Pattsituation BBM verhindern kann, die ich später eingehen werde. Angesichts der Tatsache, dass die meisten Projekte ein hohes Maß an Anforderungen Abwanderung heutzutage Leiden, ist die schrittweise Wachstum eine Tatsache, die nicht nur eine Möglichkeit. Um eine BBM zu verhindern, müssen Sie eine wirksame Strategie zur Bewältigung der schrittweisen Wachstum der Funktionalität verfügen.

Das Mantra des verwaltbar Software behauptet, dass perfekte moderner Software die Anforderungen von heute erfüllt und flexibel genug ist, um zukünftige Anforderungen gerecht zu werden. Die erste aufgrund der drei erwähnten ist Domäne. Wenn Sie einen echten Domain-Experten in Ihrem Team haben können, Sie brauchen mindestens eine Person mit einem tiefen Verständnis der Domäne, die wahrscheinlich macht Sie des neuen Domäne-Experte. Erfahrung gelangen Sie zum vernünftige Entscheidung über Features, die wahrscheinlich erforderlich und angefordert werden. Also, können Sie einfach im Voraus planen gleichzeitig den Grundsatz der YAGNI (Sie Ain't Gonna brauchen It) deutlich beachten.

Der Class-Responsibility-Collaboration (CRC) Karten-Ansatz half mir zum ersten Mal begegnete die Mechanik der Domänen besser zu verstehen. CRC-Karten, die mehr als eine Möglichkeit zu Lehren sich die Domäne als eine Art und Weise zu kommen mit einer passenden Entwurf angezeigt. Design, ist auf der anderen Seite nur, wenn durch den tatsächlichen Kunden überprüft. Anwendungsfälle – oder sogar einen Prototyp – intelligentere Optionen sind.

Der Prototyp kann ein Problem darstellen, weil Kunden so viel mag es möglicherweise, dass sie Sie zwingen anstelle von vorne anfangen mit einem neuen Design zu erweitern. Prototypen werden in der Regel mit Einweg Code absichtlich schnell und soll, als solche frei von Prinzipien und Mustern vorgenommen. Nicht nur mit Einweg-Code beginnen soll.

Der zweite Vorteil ist eine bessere Developer/Architect immer, lernen, strömten Prinzipien der Softwareentwicklung und gemeinsame best Practices. Die Herausforderung hier ist alles in lernen, wie man einfache Dinge korrekt in der Standardeinstellung führen. Zögern Sie nicht, der schnittstellenbasierten Programmierung und Dependency Injection. Überprüfen Sie jede Klasse gegen häufige OOP-Probleme. Richtigkeit über Code und statische Analyse zu gewährleisten. Wenn Sie nicht sicher über ein Feature wie funktioniert, machen es getestet werden, und Schreiben von Tests. Keep your Code lean and Mean, mit den meisten Methoden nicht mehr als ein paar Zeilen (mit Ausnahmen, natürlich). Wenn diese Praktiken Teil der Brust Tool werden, bleibt die BBM ein Stück weiter Weg von Ihrer Projekte.

Der dritte Vorteil ist über das Verständnis der Lebensdauer des Projekts. Nicht jedes Projekt hat ein System aufbauen, die für Jahrzehnte dauert. Kurzlebige Projekte walten nicht die gleichen Design Sorgfalt lassen. Sie können schneller auf sie gehen und Pflege in machen ihnen zu arbeiten, bevor Sie diese Rechte vornehmen. In der Software, muss die Komplexität gesteuert, wo es wirklich existiert, nicht erstellt werden, wo es existiert nicht und soll nicht sein. Die Gefahr ist jedoch, wenn der anfängliche glaube, die das Projekt hatte eine kurze Zeit erstrecken durch überraschende Erfolg und Nachfrage und die Schaffung eines Marktes ungültig wird. Wenn die nachfolgende Version langsam geschieht, laufen Sie Gefahr eines Mitbewerbers Riß den Markt – oder Sie laufen Gefahr, eine BBM aufgrund der Geschäftsanforderungen wirklich enge (und verzweifelten) erstellen.

Software Projekt Disaster Recovery

Die BBM ist eine gemeinsame Antimusters, aber zu einem gewissen Grad, es ist ein Attribut, das auf nahezu jedem Software-Projekt angewendet werden kann. Es stammt aus mit der falschen Tools komplexe Komplexität. In diesem Artikel, die ich verwendet eines Ausdrucks – Disaster Recovery – das ist beliebt in IT. Das Mantra von Experten für Disaster Recovery, jedoch kann auch auf Softwareprojekte angewendet werden: Investitionen in Prävention mehr als im Recovery ausgegebene Dollar Wert sind. Rush an Ihren Manager Office noch heute!

Dino Esposito ist der Autor von "Programming Microsoft ASP.NET MVC"(Microsoft Press, 2010) und Mitautor von"Microsoft.NET: Architekturanwendungen für das Unternehmen "(Microsoft Press, 2008). Esposito lebt in Italien und ist ein weltweitgefragter Referent bei Branchenveranstaltungen. Folgen ihm auf Twitter bei twitter.com/despos.

Dank der folgenden technischen Experten für die Überprüfung dieses Artikels: Mircea Trofin