it-swarm-eu.dev

Wie erklären Sie anderen die Trennung von Bedenken?

Wenn Sie einen Kollegen hätten, der die Vorteile der Trennung von Bedenken nicht oder nicht ausreichend verstanden hätte, um sie in seiner täglichen Arbeit konsequent anzuwenden, wie würden Sie es ihnen erklären?

37
Marcie

Stellen Sie sich vor, Sie haben ein Programm, das veröffentlicht wurde. Ein Kunde kommt vorbei und bietet an, Sie für eine Verbesserung einer seiner Funktionen zu bezahlen. Um an das Geld zu kommen, müssen Sie Ihr Programm ändern, um die neue Funktion hinzuzufügen. Einige der Faktoren, die Ihre Gewinnspanne beeinflussen, sind:

  1. wie viel Code müssen Sie ändern?
  2. wie einfach es ist, die Änderungen vorzunehmen
  3. wie wahrscheinlich ist es, dass Sie vorhandene Funktionen, die von anderen Kunden verwendet werden, beschädigen
  4. wie oft können Sie Ihr vorhandenes Modell/Ihre vorhandene Architektur wiederverwenden?

Die Trennung von Bedenken hilft Ihnen, positivere Antworten auf diese Fragen zu erhalten.

  1. wenn der gesamte Code für ein bestimmtes Verhalten der Anwendung getrennt ist, müssen Sie nur den Code ändern, der direkt mit Ihrer neuen Funktion verknüpft ist. Welches sollte weniger Code zu ändern sein.
  2. wenn die Verhaltensweisen, an denen Sie interessiert sind, sauber vom Rest der Anwendung getrennt sind, ist es wahrscheinlicher, dass Sie eine neue Implementierung austauschen können, ohne den Rest des Programms vollständig verstehen oder manipulieren zu müssen. Es sollte auch einfacher sein herauszufinden, welchen Code Sie ändern müssen.
  3. Code, den Sie nicht ändern müssen, bricht weniger wahrscheinlich als Code, den Sie ändern. Wenn Sie also die Bedenken aufteilen, können Sie vermeiden, dass nicht verwandte Funktionen beschädigt werden, indem Sie verhindern, dass Sie den Code ändern müssen, den sie aufrufen könnten. Wenn Ihre Funktionen verwechselt werden, können Sie das Verhalten einer Funktion versehentlich ändern, während Sie versuchen, eine andere zu ändern.
  4. Wenn Ihre Architektur unabhängig von technischen oder geschäftlichen Logikdetails ist, ist es weniger wahrscheinlich, dass Änderungen an der Implementierung neue Architekturfunktionen erfordern. Wenn Ihre Hauptdomänenlogik beispielsweise datenbankunabhängig ist, sollte die Unterstützung einer neuen Datenbank so einfach sein wie das Austauschen einer neuen Implementierung der Persistenzschicht.
53
flamingpenguin

Schauen Sie sich ein Krankenhaus an und denken Sie über die verschiedenen Rollen nach, die bei der Versorgung eines Patienten eine Rolle spielen: Triage-Krankenschwestern, Ärzte, Arzthelferinnen, Technikerinnen, Angestellte, Cafeteria usw.

Gibt es eine Person, die weiß, wie alle dieser Leute ihre Arbeit erledigen? Nein, denn es wäre überwältigend. Sie müssen die verschiedenen Verantwortlichkeiten in verschiedene Rollen aufteilen, und die Berührungspunkte zwischen diesen Rollen sind sehr spezifisch.

10
RationalGeek

Wenn er/sie in einem Büro arbeitet, nehmen Sie es als Beispiel, erklären Sie die Rolle der einzelnen Mitarbeiter in diesem Büro und fragen Sie ihn, was passieren würde, wenn diese Mitarbeiter nicht nach ihren Aufgaben aufgeteilt würden.

5

Ich würde mir ansehen, wie er es versäumt hat, SoC in seinem Code/Design anzuwenden, und daraus ein reales Beispiel machen, mit dem er sich identifizieren kann und das offensichtlich unerwünscht ist.

Wenn er beispielsweise eine Klasse hat, in der der Kunde mehrere Informationen liefern muss, die für diese Kunden nicht relevant sind, würde ich die Analogie einer Bäckerei verwenden, in der Sie Ihre eigenen Körner und Hefen mitbringen müssen, wenn Sie kaufen möchten ein Brot.