Wie erklären Sie anderen die Trennung von Bedenken?

Stellen Sie sich vor, Sie haben ein Programm welches freigegeben 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 Sie ändern müssen
2. wie einfach es ist, Ä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 Sie erhalten positivere Antworten auf diese Fragen.

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 . Dies sollte weniger Code zum Ä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 sie vollständig verstehen zu müssen oder manipulieren Sie den Rest des Programms. 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 Schäden an nicht verwandten Funktionen vermeiden, indem Sie verhindern, dass Sie den Code ändern müssen, den sie aufrufen könnten. Wenn Ihre Funktionen verwechselt werden, können Sie versehentlich das Verhalten einer ändern, während Sie versuchen, eine andere zu ändern.
4. Wenn Ihre Architektur nicht mit technischen oder geschäftlichen Logikdetails übereinstimmt, ist es weniger wahrscheinlich, dass Änderungen an der Implementierung erforderlich sind neue architektonische Merkmale. 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.

Kommentare

• Ich finde es toll, dass Sie die Antwort fest in der finanziellen Realität verankert haben. Manager haben keine Entschuldigung, schlampig zu sein und dieses grundlegende Konzept zu ignorieren.

Schauen Sie sich ein Krankenhaus an und Denken Sie an all die verschiedenen Rollen, die bei der Versorgung eines Patienten eine Rolle spielen: Triage-Krankenschwestern, Ärzte, medizinische Assistenten, Techniker, Angestellte, Cafeteria usw.

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

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

Ich würde mir ansehen, wie er SoC in seinem Code / Design nicht angewendet hat, und daraus ein reales Beispiel machen, mit dem er sich identifizieren kann Das ist offensichtlich unerwünscht.

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

Ein Beispiel könnte ein HTML-Entwickler sein möchte HTML, CSS und Javascript in Separata trennen te Dateien. Auf diese Weise können Sie das Erscheinungsbild von etwas ändern, indem Sie einfach das CSS oder das Verhalten von etwas ändern, indem Sie die separat geladene Javascript-Datei ändern. Wenn Sie eine reaktionsfähige oder adaptive Site haben, funktioniert dieses Paradigma gut, da Sie je nach Ansichtsfenster oder Benutzeragent des Benutzers unterschiedliche CSS- oder Javascript-Dateien laden können. Wenn Sie jedoch den HTML-Code oder die Vorlage ändern, besteht die Möglichkeit, dass CSS oder Javascript beschädigt werden. Diese getrennten Bedenken können auch abhängig sein.

Ein anderer Ansatz besteht darin, all Ihr CSS-Javascript und HTML in einer Gruppe von Komponenten oder Modulen zu bündeln. Dies bedeutet, dass Sie Änderungen an einem Modul vornehmen können und dass dies keine Auswirkungen auf andere Komponenten oder Module auf der Seite haben sollte, auf der es ausgeführt wird und die nicht miteinander verbunden sind. Hier werden die CSS-, JS- und HTML-Dateien zu einer einzigen Komponente zusammengeführt, die Unit-getestet werden kann.Die Trennung von Bedenken erfolgt also in Form einzelner atomarer Komponenten, die einheitlich getestet werden können, anstatt Markup-, Styling- und Verhaltenselemente zu trennen. Dieser zweite Ansatz eignet sich besser zum Erstellen komplexerer Webanwendungen.

Bearbeiten. Da ich eine negative Antwort auf diesen Kommentar erhalten habe, dachte ich, ich würde ihn noch einmal besuchen und versuchen, einen Teil meiner POV zu qualifizieren. Leider ist jedes Feedback hier nicht besonders konstruktiv, aber ich habe an anderer Stelle eine interessante Diskussion gesehen, die sich mit React, der aktuellen Hot-Technologie in der Webentwicklung, einem Beispiel aus der Praxis, befasst und fragt, ob es die Trennung von Bedenken bricht oder insbesondere, ob es eines von ihnen bricht das Prinzip „s of Feather“ SOLID objektorientierte Entwurfsmethode.

Die technische JavaScript-Entwicklerperspektive

NO, because JSX is a view language. That"s one responsibility. BUT, this implies that the JS developer is self-enforcing SoC/SRP on his own architecture by not mixing ViewModel concerns in his JSX. This type of vigilance "in the wild" is highly suspect because JSX involves the full JavaScript dialect. 

Die UX / UI-Designerperspektive

YES, because JSX mixes Semantic Content (Model) with Behavior (Controller) YES, because the intrusion, specifically of JavaScript, into the Semantic Model makes it difficult or impossible for me to play my role and leverage my expertese and skills. 

Die Teamperspektive

NO, if both... Separate files are used for the View (JSX) and ViewModel (JS). Either there aren"t UI/UX/Designers involved, or they are productive working directly with JSX (not very common). YES, if either... Everything is in the same file, causing problems for version control or productive use of modern editors. Members of the team who are comfortable with HTML/CSS but less capable with JavaScript are excluded because of mixture or roles. 

https://hashnode.com/post/does-react-really-violate-separation-of-concern-by-putting-html-and-js-in-a-single-file-cil3bn5hj0011a65347rsdut0

Auf der Seite befindet sich auch ein Link zu einer interessanten Präsentation von Pete Hunt von Facebook, in der er über Komponenten und nicht über Vorlagen spricht und die Bedenken in der Sprachanwendung herausgreift und nicht Trennen von Bedenken des Frameworks, dh Vorlagen, CSS und Javascript usw.

In Bezug auf das Trennen Ihrer Bedenken in der Sprache Ihrer Anwendung kann dies die Verwendung verschiedener Muster umfassen, um Ihren Code in modulare Form zu trennen oder zu entkoppeln Das kann Unit-getestet werden usw.

Zusammenfassend kann die Trennung von Bedenken von Ihrer Rolle oder Sichtweise abhängen, wie an anderer Stelle erwähnt.

Kommentare

• Dies ‚ scheint nichts Wesentliches über Punkte zu bieten, die zuvor gemacht und erklärt wurden 7 Antworten
• Ich möchte nur darauf hinweisen, dass die Trennung von Bedenken je nach Kontext unterschiedliche Ansätze verfolgen kann. Dies kommt einer realen Situation in Seeschwalben des Software-Engineerings näher und ich möchte hervorheben, dass es verschiedene Ansätze gibt, die Sie bei der Arbeit an HTML-Seiten verfolgen können, die auf den ersten Blick widersprüchlich erscheinen können.