懸念の分離を他の人にどのように説明しますか？

懸念の分離のメリットを理解していない同僚、または日常業務に一貫して適用できるほど十分に理解していない同僚がいた場合、どのように説明しますか？

リリースされたプログラムがあると想像してください。顧客がやって来て、その機能の1つに対する機能強化に対する支払いを申し出ます。お金を稼ぐには、プログラムを変更して新しい機能を追加する必要があります。利益率に影響を与えるものには次のものがあります。

1. 変更する必要があるコードの量
2. 変更を加えるのは簡単です
3. 他の顧客が使用している既存の機能を破壊する可能性
4. 既存のモデル/アーキテクチャをどれだけ再利用できますか

懸念を分離することで、これらの質問に対してより積極的な回答を得ることができます。

1. アプリケーションの特定の動作のコードがすべて分離されている場合、新しい機能に直接関連付けられているコードを変更するだけで済みます。変更するコードは少なくなります。
2. 関心のある動作がアプリケーションの他の部分からきちんと分離されている場合、プログラムの残りの部分を完全に理解したり操作したりすることなく、新しい実装にスワップできる可能性が高くなります。また、どのコードを変更する必要があるかを見つけやすくする必要があります。
3. 変更する必要のないコードは、変更するコードより破損する可能性が低くなります。そのため、懸念事項を分割することで、関連する機能が呼び出される可能性のあるコードを変更する必要がなくなるため、関連のない機能の破損を回避できます。機能が混在している場合、別の機能を変更しようとするときに、誤って機能を変更する可能性があります。
4. アーキテクチャが技術的またはビジネスロジックの詳細に依存しない場合、実装の変更に新しいアーキテクチャ機能が必要になる可能性は低くなります。たとえば、メインドメインロジックがデータベースに依存しない場合、新しいデータベースのサポートは、永続層の新しい実装での交換と同じくらい簡単である必要があります。

病院を見て、トリアージナース、医師、医療助手、技術者、事務職員、カフェテリアなど、患者へのケアの提供に関与するさまざまな役割をすべて考えてください。

それらのすべての人がどのように仕事を成し遂げるかを知っている人はいますか？いいえ、それは圧倒的だからです。彼らは異なる責任を明確な役割に分離する必要があり、それらの役割間のタッチポイントは非常に具体的です。

彼/彼女がオフィスで働いている場合、例としてそれを取り、そのオフィスの各スタッフの役割を説明し、それらのスタッフが彼らの仕事に従って分けられないならば、何が起こるか彼に尋ねますか？

私は彼がどのようにコード/デザインにSoCを適用できなかったかを見て、それを彼が関係できる実世界の例に変え、それは明らかに望ましくない。

たとえば、クライアントがクライアントに関係のないいくつかの情報を提供する必要があるクラスがある場合、購入したい場合は自分の穀物や酵母を持ち込む必要があるベーカリーのアナロジーを使用しますパン。

1つの例は、html開発者がhtml、css、およびjavascriptを個別のファイルに分離したい場合です。この方法では、CSSまたは何かの動作を変更するだけで、個別にロードされるjavascriptファイルを変更することで、何かのルックアンドフィールを変更できます。レスポンシブまたはアダプティブサイトがある場合、このパラダイムはうまく機能し、ユーザービューポートまたはユーザーエージェントに応じて異なるcssまたはjavascriptをロードできます。ただし、htmlまたはテンプレートを変更すると、cssまたはjavascriptが破損する可能性があります。これらの個別の懸念も依存する可能性があります。

別のアプローチは、すべてのcss javascriptとhtmlをコンポーネントまたはモジュールのグループにバンドルすることです。これは、1つのモジュールに変更を加えることができることを意味し、他のコンポーネントや、そのモジュールと並行して実行されるページ上の他のコンポーネントには影響を与えません。ここで、css、js、およびhtmlファイルは、単体テストが可能な単一のコンポーネントにマージされます。そのため、懸念の分離は、マークアップ、スタイル、および動作要素の分離ではなく、単体テストが可能な個々のアトミックコンポーネントの形で行われます。この2番目のアプローチは、より複雑なWebアプリケーションの作成により適しています。

編集。このコメントに対して否定的な反応を受け取ったので、私はそれを再訪して、私のpovのいくらかを修飾しようと思った。残念ながら、ここでのフィードバックは特に建設的なものではありませんが、React、Web開発の現在のホットテクノロジー、現実世界の例を見て、懸念の分離を壊すか、特にFeatherのSOLIDオブジェクト指向設計手法の原則。

技術的なJavaScript開発者の視点

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.

UX / UIデザイナーの視点

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.

チームの視点

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

また、このページにはFacebookのPete Huntからの興味深いプレゼンテーションへのリンクがあります。彼はテンプレートではなくコンポーネントについて語り、フレームワークの懸念、つまりテンプレート、css、javascriptを分離するのではなく、言語アプリケーションの懸念を分離します等

アプリケーションの言語で懸念事項を分離することに関しては、さまざまなパターンを使用して、コードを単体テストなどが可能なモジュール形式に分離または分離する必要があります。

要約すると、懸念を分離することは、他の場所で述べたように、あなたの役割や視点に依存する可能性があります。