関心の分離のメリットを理解していない、または日常業務に一貫して適用するのに十分な理解がない同僚がいた場合、どのように説明しますか？
コメント
- ウィキペディアでいくつかの良い例を見つけました： en.wikipedia.org/wiki/Separation_of_concerns
回答
プログラムがあると想像してくださいこれがリリースされました。顧客がやって来て、その機能の1つを強化するためにあなたに支払うことを申し出ます。お金を稼ぐには、プログラムを変更して新しい機能を追加する必要があります。利益率に影響を与えるものには、次のようなものがあります。
- 変更する必要のあるコードの量
- 変更のしやすさ
- 他の顧客が使用している既存の機能を壊す可能性がどの程度あるか
- 既存のモデル/アーキテクチャをどれだけ再利用できるか
関心の分離はこれらの質問に対するより肯定的な回答を得ることができます。
- アプリケーションの特定の動作のすべてのコードが分離されている場合は、新しい機能に直接関連付けられているコードを変更するだけで済みます。 。変更するコードが少なくて済みます。
- 関心のある動作がアプリケーションの他の部分からきちんと分離されている場合、完全に理解していなくても新しい実装に交換できる可能性が高くなります。またはプログラムの残りの部分を操作します。また、変更する必要のあるコードを見つけるのも簡単です。
- 変更する必要のないコードは、変更するコードよりも破損する可能性が低くなります。したがって、懸念事項を分割すると、呼び出される可能性のあるコードを変更する必要がなくなるため、無関係な機能の破損を回避できます。機能が混同されている場合、別の機能を変更しようとしているときに、誤って1つの動作を変更する可能性があります。
- アーキテクチャが技術的またはビジネスロジックの詳細にとらわれない場合、実装の変更が必要になる可能性は低くなります。新しいアーキテクチャ機能。たとえば、メインドメインロジックがデータベースに依存しない場合、新しいデータベースのサポートは、永続層の新しい実装で交換するのと同じくらい簡単である必要があります。
コメント
- あなたが答えを金融の現実にしっかりと固定してくれたことを嬉しく思います。マネージャーはだらしなく、この基本的な概念を無視する言い訳はありません。
回答
病院を見て、トリアージ看護師、医師、医療助手、技術者、事務職員、カフェテリアなど、患者へのケアの提供に関係するさまざまな役割のすべてについて考えてください。
方法を知っている人はいますか
em>それらの人々のすべては彼らの仕事を成し遂げますか？いいえ、それは圧倒されるからです。さまざまな責任を個別の役割に分ける必要があり、それらの役割間のタッチポイントは非常に具体的です。
回答
彼が/彼女はオフィスで働いており、例として、そのオフィスでの各スタッフの役割を説明し、それらのスタッフが仕事に応じて分割されていない場合はどうなるかを尋ねます。
回答
彼がコード/デザインにSoCを適用できなかった理由を見て、それを実際の例に変えて、それは明らかに望ましくありません。
たとえば、クライアントがそれらのクライアントに関係のないいくつかの情報を提供する必要があるクラスがある場合、私はあなたが持っているパン屋のアナロジーを使用しますパンを購入したい場合は、自分の穀物と酵母を持参してください。
回答
1つの例として、HTML開発者が挙げられます。 html、css、javascriptをseparaに分離したいteファイル。このようにして、cssを変更するだけで何かのルックアンドフィールを変更したり、個別にロードされたjavascriptファイルを変更して何かの動作を変更したりできます。レスポンシブサイトまたはアダプティブサイトがある場合、このパラダイムはうまく機能し、ユーザーのビューポートまたはユーザーエージェントに応じて異なるcssまたはjavascriptをロードできます。ただし、htmlまたはテンプレートを変更すると、cssまたはjavascriptのいずれかが破損する可能性があります。これらの個別の懸念も依存する可能性があります。
もう1つのアプローチは、すべてのcssjavascriptとhtmlをコンポーネントまたはモジュールのグループにバンドルすることです。これは、1つのモジュールに変更を加えることができ、そのモジュールが実行されているページ上の他のコンポーネントやモジュールに影響を与えてはならないことを意味します。ここで、css、js、およびhtmlファイルは、単体テストが可能な単一のコンポーネントにマージされます。したがって、関心の分離は、マークアップ、スタイリング、および動作要素の分離ではなく、単体テストが可能な個々の原子コンポーネントの形で行われます。この2番目のアプローチは、より複雑なWebアプリケーションの作成に適しています。
編集。このコメントに対して否定的な反応を受け取ったので、私はそれを再訪して、私のハメ撮りのいくつかを修飾しようと思いました。残念ながら、ここでのフィードバックは特に建設的なものではありませんが、React、Web開発の現在のホットテクノロジー、実際の例を見て、関心の分離を破るかどうか、特に関心の分離を破るかどうかを尋ねる興味深い議論を他の場所で見ました。フェザーの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. このページには、FacebookのPete Huntによる興味深いプレゼンテーションへのリンクもあります。ここでは、テンプレートではなくコンポーネントについて説明し、言語アプリケーションではなく言語アプリケーションの懸念を分離しています。フレームワークの懸念事項、つまりテンプレート、css、javascriptなどを分離します。
アプリケーションの言語で懸念事項を分離することに関しては、さまざまなパターンを使用してコードを分離またはモジュール形式に分離する必要があります。ユニットテストなどが可能です。
要約すると、懸念事項の分離は、他の場所で述べたように、役割や視点によって異なります。
コメント
- これは'以前に作成および説明されたポイントよりも実質的なものを提供していないようです7つの回答
- 懸念事項を分離することは、状況に応じて異なるアプローチを取る可能性があることを指摘しています。これは、ソフトウェアエンジニアリングの分野における現実の状況に近く、最初は矛盾しているように見えるHTMLページで作業するときに実行できるさまざまなアプローチがあることを強調しています。