Monolithisches System VS viele unabhängige Module am Beispiel des Gleichnisses von Elefant und Weisen

    Dieser Artikel ist im Grunde eine kostenlose Nacherzählung eines Fragments von Eric Evans 'Buch „Object-Oriented Design“, in dem er getrennte Wege und begrenzten Kontext behandelt.

    Angenommen, es gibt die folgende Situation: Mehrere Entwicklungsgruppen arbeiten an demselben Projekt, lösen jedoch unterschiedliche Probleme. Das Projekt ist beispielsweise ein Chipdesigner, und das erste Team implementiert die Funktion zum Aufrufen des Chips, und das zweite berechnet die Kosten des Chips. Frage: Was ist besser zu tun? 1) Ermöglichen Sie beiden Teams, „in ihrem eigenen Saft zu kochen“ und zwei Module am Ausgang zu erhalten, deren Code sich praktisch nirgendwo überschneidet, oder 2) stellen Sie die Kommunikation zwischen den beiden Teams her, lassen Sie sie zusammenarbeiten und erhalten Sie einen einzigen Ausgang monolithisches System?Es gibt keine universelle Antwort auf diese Frage ("Ja" oder "Nein") und die Analogie mit dem Elefanten und den Weisen wird uns helfen, die Antwort in dieser Situation zu finden.




    Hier ist der Elefant ein komplexes Themengebiet, und die Weisen sind Programmierer.

    Sechs grauhaarige Weise kamen
    aus verschiedenen Ländern zusammen.
    Leider waren alle blind,
    aber er leuchtete mit seinen Gedanken.
    Sie erkunden den Elefantenauftritt
    in Hindustan.
    Einer streichelte die Seite des Elefanten.
    Zufrieden damit
    sagte er: "Die Wahrheit ist jetzt,
    wie göttlich sichtbar ist:
    Das Thema, das wir einen Elefanten nennen,
    bloße Wand!"
    Und er nahm den dritten Koffer in die Hand
    und rief: „Freunde!
    Unsere Frage ist viel einfacher.
    Da bin ich mir sicher!
    Dieser Elefant ist ein Lebewesen,
    nämlich eine Schlange! “
    Der vierte Weise packte
    eines der Beine des Elefanten
    und sagte vor allem: „Dies ist der Rüssel.
    Das Bild ist mir klar!
    Ein Elefant ist ein Baum, der blühen wird,
    wenn der Frühling kommt! “
    Inzwischen schaffte es der sechste von ihnen
    bis zum Schwanz.
    Und er lachte darüber, wie
    einfach die Wahrheit war.
    „Dein Elefant ist ein Seil. Wenn nicht,
    nähen Sie meinen Mund! "
    Und wie Sie wissen, sind die Weisen von
    Natur aus hartnäckig. Nachdem
    sie das Argument entfesselt hatten, erreichten sie
    kaum den Punkt der Repressalien.
    Aber niemand wusste die Wahrheit,
    obwohl er etwas recht hatte.

    Wenn ein Unterprogramm eines Teams von Programmierern (Weisen) mit einem bestimmten Teil eines Themenbereichs (mit den Füßen eines Elefanten) interagiert, muss es nicht den gesamten Themenbereich (Elefanten) als Ganzes kennen. Wenn sie diesen Teil des Themenbereichs vereinfachen und alles Überflüssige verwerfen (die Beine des Elefanten in Bäume verwandeln), erhalten sie gleichzeitig einen Code, den selbst jemand verstehen kann, der mit dem Themenbereich wenig vertraut ist (der nicht weiß, was der Elefant ist). Wenn der Themenbereich zu komplex ist und Sie versuchen, die Unermesslichkeit mit Ihrem inneren Blick zu erfassen, gerät der Programmierer in einen kognitiven Stupor und die Entwicklungsgeschwindigkeit sinkt um eine Größenordnung. Andererseits erschwert dieser Ansatz die Interaktion zwischen den einzelnen Teilen des Programms.

    Vergleichen Sie beide Ansätze. Die Vorteile großer Kontexte (monolithische Systeme):
    • Verschiedene Benutzeroperationen sind reibungsloser und natürlicher miteinander verbunden, wenn so viele verschiedene Objekte und Operationen wie möglich von einem einheitlichen Modell abgedeckt werden.
    • Es ist einfacher, ein verbundenes Modell als zwei verschiedene Modelle und die Anzeigeebene zwischen ihnen zu verstehen.
    • Die Übertragung zwischen zwei Modellen kann schwierig (oder sogar unmöglich) sein.
    • Die gemeinsame Sprache stimuliert eine klare Interaktion im Entwicklungsteam.

    Vorteile kleiner Kontexte (viele heterogene Module):
    • Die Kommunikationskosten zwischen Entwicklern werden reduziert (da selbst weniger Kommunikation stattfindet).
    • KONTINUIERLICHE INTEGRATION ist in kleinen Gruppen mit kleinen Codebasen einfacher durchzuführen.
    • In größeren Kontexten sind möglicherweise universellere und abstraktere Modelle erforderlich, die selten anzutreffende Entwicklerqualifikationen erfordern.
    • Kleine Modelle können auf spezielle Bedürfnisse zugeschnitten sein oder dem Jargon spezialisierter Benutzergruppen sowie hochspezialisierten Dialekten der UNIFIED LANGUAGE (UBIQUITOUS LANGUAGE) entsprechen.

    Es sollte auch beachtet werden, dass sich theoretisch eine Schlange, Bäume und ein Seil zu einem Elefanten entwickeln können. Wenn sich zum Beispiel die Spezifikation des Programms ändert und sich herausstellt, dass der Elefant laufen kann, können sich die Bäume durchaus in Beine verwandeln. Es ist jedoch nicht alles so einfach. Der Fall, in dem sich die Teile des Themenbereichs nirgendwo schneiden, ist idealisiert, in der Praxis ist dies höchstwahrscheinlich nicht der Fall. Angenommen, zwei Programmierteams arbeiten mit dem Rüssel eines Elefanten, aber das erste Team ist daran interessiert, dass der Rüssel die Eigenschaften eines Lebewesens besitzt und ihr Rüssel eine Schlange ist, und das zweite Team ist an der Fähigkeit des Rüssel interessiert, Wasser zu spritzen, und sie haben einen Rüssel - einen Wasserschlauch. Im Laufe der Zeit stellten beide Entwicklungsteams zufällig fest, dass die Schlange des ersten Teams und des zweiten Schlauchs dasselbe Phänomen beschreiben. Danach beschloss das zweite Team, den Schlauch durch eine Schlange zu ersetzen, die Wasser spuckt. Und dies erfordert ein zweiwöchiges Refactoring. Aus eigener Erfahrung werde ich sagen, dass Sie zwei Wochen lang niemand verstehen lassen wird, was passiert, wenn das Projekt nicht unter der Last der technischen Schulden versinkt, aber selbst dann werden Sie in diesen zwei Wochen dringlichere Probleme lösen, als einen Schlauch in eine spuckende Schlange zu verwandeln . Wenn Sie sich in der Realität der russischen Entwicklung zunächst nicht auf ein monolithisches Modell zubewegen, ist es für Sie fast unmöglich, zu diesem Modell zu wechseln, während es kein Problem ist, das monolithische Modell zu verlassen. anstatt einen Schlauch in eine spuckende Schlange zu verwandeln. Wenn Sie sich in der Realität der russischen Entwicklung zunächst nicht auf ein monolithisches Modell zubewegen, ist es für Sie fast unmöglich, zu diesem Modell zu wechseln, während es kein Problem ist, das monolithische Modell zu verlassen. anstatt einen Schlauch in eine spuckende Schlange zu verwandeln. Wenn Sie sich in der Realität der russischen Entwicklung zunächst nicht auf ein monolithisches Modell zubewegen, ist es für Sie fast unmöglich, zu diesem Modell zu wechseln, während es kein Problem ist, das monolithische Modell zu verlassen.
    Wenn Sie den Pfad vieler nicht verwandter Module gewählt haben, denken Sie an das folgende Sprichwort: „Wenn drei Programmierteams einen Compiler entwickeln, erhalten sie am Ausgang einen Drei-Durchlauf-Algorithmus.“ Vorsicht davor. Die Architektur des Programms sollte den Themenbereich widerspiegeln, nicht die interne Struktur Ihres Unternehmens!

    PS Dieser Artikel wurde als Antwort auf einen kleinen Holivar in diesem Artikel geboren . Wenn Beispiele aus dem wirklichen Leben interessant sind, empfehle ich, den Artikel Unkontrollierte Verletzung des Mehrebenenprinzips zu lesen .

    Jetzt auch beliebt: