Kriterien für schlechtes Design
Das Leben funktioniert ganz einfach: Um schlau zu sein, muss man oft nur keine dummen Dinge tun. Das gilt auch für die Softwareentwicklung: Um etwas gut zu machen, muss man es in den meisten Fällen nur nicht schlecht machen.
Die meisten Programmierer haben Erfahrung mit Teilen des Systems gemacht, die schlecht entworfen wurden. Noch trauriger ist jedoch, dass die meisten von Ihnen die traurige Erfahrung machen müssen, dass sie die Urheber eines solchen Systems waren. Wir wollten das Beste, aber es hat wie immer geklappt.
Die meisten Entwickler streben nicht nach einer schlechten Architektur, und bei vielen Systemen kommt irgendwann der Punkt, an dem sie anfangen zu sagen, dass die Architektur schrecklich ist. Warum passiert das? War Architekturdesign von Anfang an schlecht oder ist es mit der Zeit schlecht geworden?
Die Wurzel dieses Problems ist das Fehlen einer Definition von „schlechtem“ Design.
Mir scheint, dass das Verständnis für die Qualität des Designs und die Gründe für seinen „Verfall“ die wichtigsten Eigenschaften eines jeden Programmierers sind. Wie in den meisten anderen Fällen geht es vor allem darum, das Problem zu identifizieren, und es wird eine Frage der Technologie sein, es zu lösen.
Definition von „schlechtem Design“
Wenn Sie sich entscheiden, vor einem anderen Programmierer mit Ihrem Code anzugeben, werden Sie höchstwahrscheinlich als Antwort lächerlich gemacht: „Wer macht das?“, „Warum ist das so?“ und „Ich würde die Dinge anders machen.“ Das passiert sehr oft.
Alle Menschen sind unterschiedlich, aber Sie schreiben dennoch den Code für Ihre Programmierkollegen. Daher benötigen Sie im Prozess der Entwicklung jeder Funktion immer eine Überprüfungsphase, in der sich andere Personen Ihren Code ansehen.
Aber auch wenn viele Dinge auf unterschiedliche Weise erledigt werden können, gibt es eine Reihe von Kriterien, über die sich alle Entwickler einig sind. Jeder Code, der seine Anforderungen erfüllt, aber dennoch eine (oder mehrere) Eigenschaften aufweist, ist schlechtes Design.
Schlechtes Design:
- Schwierig zu ändern, da jede Änderung zu viele andere Teile des Systems betrifft. ( Steifigkeit , Steifigkeit).
- Wenn Änderungen vorgenommen werden, brechen andere Teile des Systems unerwartet ab. ( Zerbrechlichkeit , Zerbrechlichkeit).
- Es ist schwierig, den Code in einer anderen Anwendung wiederzuverwenden, da es zu schwierig ist, ihn aus der aktuellen Anwendung herauszubekommen. ( Unbeweglichkeit , Unbeweglichkeit).
Und das Witzige daran ist, dass es fast unmöglich ist, einen Teil des Systems zu finden , der keine dieser Eigenschaften aufweist (d. h. flexibel, zuverlässig und wiederverwendbar ist), die Anforderungen erfüllt und gleichzeitig schlecht konstruiert ist .
Somit können wir anhand dieser drei Merkmale eindeutig feststellen, ob ein Design „schlecht“ oder „gut“ ist.
Ursachen für „schlechtes Design“
Was macht ein Design starr, spröde und unbeweglich? Starre gegenseitige Abhängigkeit der Module.
Ein Design ist starr , wenn es nicht einfach geändert werden kann. Diese Starrheit ist auf die Tatsache zurückzuführen, dass eine einzelne Änderung an einem Codeabschnitt in einem gewebten System zu kaskadierenden Änderungen in abhängigen Modulen führt. Dies geschieht immer, wenn eine Person am Code arbeitet.
Dies verkompliziert sofort den gesamten kommerziellen Entwicklungsprozess: Wenn die Anzahl der kaskadierenden Änderungen vom Designer oder Entwickler nicht vorhergesagt werden kann, ist es unmöglich, die Auswirkungen einer solchen Änderung abzuschätzen. Daher versuchen sie, solche Änderungen auf unbestimmte Zeit zu verschieben.
Und das wiederum macht die Kosten der Veränderung unvorhersehbar. Angesichts dieser Unsicherheit zögern Manager, Änderungen vorzunehmen, sodass das Design offiziell starr wird.
Irgendwann überschreitet Ihr Projekt den „Ereignishorizont“ und ist dazu verdammt, in das „Schwarze Loch“ der starren Architektur zu fallen.
Fragilität ist die Tendenz eines Systems, nach einer einzigen Änderung an mehreren Stellen zusammenzubrechen. Normalerweise treten neue Probleme an Orten auf, die konzeptionell keinen Bezug zum Ort der Veränderung haben. Eine solche Fragilität untergräbt ernsthaft das Vertrauen in die Gestaltung und Wartung des Systems.
Dies war normalerweise der Fall, wenn es keine privaten Methoden gab. Es reicht aus, alle Methoden öffentlich zu machen, und Sie werden dazu verdammt sein, den Anschein einer fragilen Architektur zu erwecken. Die Kapselung hilft dabei, dies auf der Mikroebene zu bewältigen. Auf der Makroebene benötigen Sie jedoch eine modulare Architektur.
Wenn ein Projekt eine fragile Architektur aufweist, können die Entwickler die Qualität des Produkts nicht garantieren.
Einfache Änderungen in einem Teil der Anwendung führen zu Fehlern in anderen Teilen, die nichts damit zu tun haben. Die Korrektur dieser Fehler führt zu noch mehr Problemen und der Begleitprozess wird zu einem berühmten Hund, der seinem eigenen Schwanz nachjagt.
Das Design ist unbeweglich , wenn die notwendigen Teile des Systems stark an andere unerwünschte Details gebunden sind. Zu viel eigener Code, eigene einzigartige Ansätze und Lösungen.
Erinnern Sie sich an den JUL-Logger, dessen Entwickler ohne guten Grund ihre eigenen Protokollierungsstufen entwickelten? Das ist einfach der Fall.
Um einem Designer eine Vorstellung davon zu geben, wie einfach es ist, ein vorhandenes Design wiederzuverwenden, reicht es aus, darüber nachzudenken, wie einfach die Verwendung in einer neuen Anwendung sein wird.
Wenn das Design eng miteinander verbunden ist, wird dieser Designer entsetzt sein über den Arbeitsaufwand, der erforderlich ist, um die erforderlichen Teile des Systems von den unnötigen Details zu trennen. In den meisten Fällen ist ein solches Design nicht wiederverwendbar, da die Kosten für die Trennung die Kosten für die Neuentwicklung übersteigen.
Relevanz
Alles ändert sich, aber alles bleibt gleich. (Chinesisches Sprichwort)
Oben wurden sehr gute Fragen aufgeworfen. Welche Gefahren bergen fragile und starre Systeme? Ja, denn der Prozess der Verwaltung eines solchen Projekts wird unvorhersehbar und unkontrollierbar. Und der Preis ist exorbitant.
Wie kann ein Manager die Einführung einer Funktion genehmigen oder nicht, wenn er nicht weiß, wie lange es tatsächlich dauern wird? Wie priorisiert man Aufgaben, wenn man den Zeitaufwand und die Komplexität ihrer Umsetzung nicht ausreichend einschätzen kann?
Und wie können Entwickler die gleichen technischen Schulden abbezahlen, wenn wir sie abbezahlen, und wir nicht verstehen können, wie viel wir abbezahlen werden, bis wir abbezahlt haben?
Auch Probleme bei der Wiederverwendung oder dem Testen von Code sind sehr relevant. Unit-Tests dienen nicht nur dazu, einige Annahmen über die zu testende Einheit zu testen, sondern auch zur Bestimmung des Grads ihrer Kohäsion und können als Indikator für die Wiederverwendung dienen.
Hier ist ein Zitat von Bob Martin für diesen Fall: „Um Ihren Code wiederzuverwenden, müssen Sie den Aufwand für die Wiederverwendung geringer gestalten als die Kosten für die Entwicklung von Grund auf . “ Sonst wird sich niemand um diese Angelegenheit kümmern.
Die Verwendung von Designprinzipien und -mustern dient einem Zweck: Design gut zu machen. Wenn der Einsatz Ihnen keinen Nutzen bringt (oder umgekehrt gegen die Grundsätze „guten Designs“ verstößt), dann stimmt etwas in Ihrem Wintergarten nicht und das Werkzeug wird möglicherweise für andere Zwecke verwendet.