Como você explica a Separação de preocupações para os outros?

Se você tivesse um colega que não entendeu os benefícios da Separação de Preocupações ou não o entendeu o suficiente para aplicar de maneira consistente no trabalho diário, como explicaria isso a eles?

Imagine que você tem um programa que foi lançado. Um cliente aparece e se oferece para pagar por uma melhoria em um de seus recursos. Para obter o dinheiro, você precisará alterar seu programa para adicionar o novo recurso. Algumas das coisas que irão influenciar qual é a sua margem de lucro são:

1. quanto código você tem que mudar
2. quão fácil é fazer as alterações
3. qual a probabilidade de você quebrar os recursos existentes que estão sendo usados ​​por outros clientes
4. quanto você pode reutilizar seu modelo / arquitetura existente

A separação de preocupações ajuda você a obter respostas mais positivas para essas perguntas.

1. se todo o código de um determinado comportamento do aplicativo estiver separado, você precisará alterar apenas o código diretamente associado ao seu novo recurso. O que deve ser menos código a ser alterado.
2. se os comportamentos nos quais você está interessado são claramente separados do restante do aplicativo, é mais provável que você consiga trocar uma nova implementação sem precisar entender ou manipular completamente o restante do programa. Também deve ser mais fácil descobrir qual código você precisa alterar.
3. O código que você não precisa alterar tem menos probabilidade de quebrar do que o código que você altera. Portanto, dividir as preocupações ajuda a evitar a quebra de recursos não relacionados, impedindo que você precise alterar o código que eles poderiam chamar. Se seus recursos forem misturados, você poderá alterar o comportamento de um por acidente enquanto tenta alterar outro.
4. Se sua arquitetura é independente dos detalhes técnicos ou da lógica de negócios, é menos provável que as alterações na implementação exijam novos recursos arquiteturais. Por exemplo, se sua lógica de domínio principal é independente de banco de dados, o suporte a um novo banco de dados deve ser tão fácil quanto trocar em uma nova implementação da camada de persistência.

Procure um hospital e pense em todos os diferentes papéis envolvidos na prestação de cuidados a um paciente: triagem de enfermeiros, médicos, assistentes médicos, técnicos, equipe de funcionários, cafeteria, etc.

Existe alguém que sabe como todas essas pessoas fazem seu trabalho? Não, porque seria esmagador. Eles precisam separar as diferentes responsabilidades em papéis distintos e os pontos de contato entre esses papéis são muito específicos.

Se ele / ela trabalha em um escritório, tome como exemplo, explique o papel de cada equipe naquele escritório e pergunte-lhe o que aconteceria se essas equipes não estivessem divididas de acordo com seu trabalho?

Gostaria de ver como ele falhou em aplicar o SoC em seu código / design e transformá-lo em um exemplo do mundo real com o qual ele pode se relacionar e que é obviamente indesejável.

Por exemplo, se ele tem uma classe em que o cliente precisa fornecer várias informações que não são relevantes para esses clientes, eu usaria a analogia de uma padaria onde você deve trazer seus próprios grãos e leveduras, se quiser comprar um pão.

Um exemplo pode ser que um desenvolvedor de html queira separar html, css e javascript em arquivos separados. Dessa forma, você pode alterar a aparência de algo que diz algo, simplesmente modificando o css ou o comportamento de algo, alterando o arquivo javascript carregado separadamente. Se você tiver um site responsivo ou adaptável, esse paradigma funcionará bem, pois você poderá carregar css ou javascript diferentes, dependendo da viewport ou do agente do usuário. No entanto, se você modificar o html ou o modelo, é provável que o css ou o javascript possam quebrar. Essas preocupações separadas também podem ser dependentes.

Outra abordagem é agrupar todo o seu css javascript e html em um grupo de componentes ou módulos. Isso significa que você pode fazer alterações em um módulo e não deve afetar outros componentes ou módulos na página em que são executados ao lado e que não estão relacionados. Aqui, os arquivos css, js e html são mesclados em um único componente que pode ser testado em unidade. Portanto, a separação de preocupações vem na forma de componentes atômicos individuais que podem ser testados por unidade, em vez de separação de elementos de marcação, estilo e comportamento. Essa segunda abordagem é mais adequada para criar aplicativos da web mais complexos.

editar. Como recebi uma resposta negativa a esse comentário, pensei em revisitá-lo e tentar qualificar parte do meu pov. Infelizmente, qualquer feedback aqui não é particularmente construtivo, mas vi uma discussão interessante em outro lugar que analisa o React, a atual tecnologia em desenvolvimento no momento, um exemplo do mundo real e pergunta se ele quebra a separação de preocupações ou, em particular, se quebra uma das os princípios da metodologia de projeto orientado a objeto do SOLID de Feather.

A perspectiva técnica do desenvolvedor 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.

A perspectiva do designer de 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.

A perspectiva da equipe

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

Também na página há um link para uma interessante apresentação de Pete Hunt, do Facebook, onde ele fala sobre componentes, não modelos, e separa as preocupações no aplicativo de idiomas, em vez de separar as preocupações da estrutura, como modelos, css e javascript. etc.

No que diz respeito a separar suas preocupações no idioma do seu aplicativo, isso pode envolver o uso de vários padrões para separar ou desacoplar seu código em um formato modular que pode ser testado em unidade etc.

Portanto, para resumir, separar as preocupações pode depender do seu papel ou ponto de vista, conforme mencionado em outro lugar.