Jak wytłumaczysz rozdzielenie obaw innym?

Jeśli miałbyś kolegę, który nie rozumiał korzyści płynących z separacji obaw lub nie rozumiał go wystarczająco, by konsekwentnie stosować się w codziennej pracy, jak byś im to wyjaśnił?

Wyobraź sobie, że masz program, który został wydany. Pojawia się klient i proponuje zapłacić za ulepszenie jednej z jego funkcji. Aby otrzymać pieniądze, musisz zmienić swój program, aby dodać nową funkcję. Niektóre rzeczy, które wpłyną na twoją marżę zysku to:

1. ile kodu musisz zmienić
2. jak łatwo jest wprowadzić zmiany
3. prawdopodobieństwo złamania istniejących funkcji, z których korzystają inni klienci
4. ile możesz ponownie wykorzystać istniejący model / architekturę

Rozdzielenie obaw pomaga uzyskać bardziej pozytywne odpowiedzi na te pytania.

1. jeśli cały kod dla określonego zachowania aplikacji zostanie wyodrębniony, będziesz musiał jedynie zmienić kod bezpośrednio związany z nową funkcją. Który kod powinien być mniej do zmiany.
2. jeśli zachowania, które Cię interesują, są starannie oddzielone od reszty aplikacji, bardziej prawdopodobne jest, że będziesz mógł zamienić się nową implementacją bez konieczności pełnego zrozumienia lub manipulowania resztą programu. Powinno być również łatwiej dowiedzieć się, który kod należy zmienić.
3. Kod, którego nie musisz zmieniać, jest mniej podatny na uszkodzenie niż kod, który zmieniasz. Tak więc podzielenie się obawami pozwala uniknąć uszkodzenia niepowiązanych funkcji, zapobiegając konieczności zmiany kodu, który mogliby wywołać. Jeśli twoje funkcje zostaną pomieszane, możesz zmienić zachowanie jednego z nich przez przypadek, próbując zmienić inny.
4. Jeśli twoja architektura jest niezależna od szczegółów technicznych lub logiki biznesowej, zmiany w implementacji rzadziej wymagają nowych funkcji architektonicznych. Na przykład, jeśli główną logiką domeny jest agnostyka bazy danych, obsługa nowej bazy danych powinna być tak łatwa, jak zamiana w nowej implementacji warstwy trwałości.

Spójrz na szpital i pomyśl o wszystkich różnych rolach związanych z opieką nad pacjentem: pielęgniarki, lekarze, asystenci medyczni, technicy, pracownicy biurowi, kawiarnie itp.

Czy jest jakaś osoba, która wie, jak wszystkie te osoby wykonują swoją pracę? Nie, ponieważ byłoby to przytłaczające. Muszą rozdzielić różne obowiązki na odrębne role, a punkty kontaktowe między tymi rolami są bardzo konkretne.

Jeśli on / ona pracuje w biurze, weź to jako przykład, wyjaśnij rolę każdego sztabu w tym biurze i zapytaj go, co by się stało, gdyby te sztaby nie zostały podzielone zgodnie z ich pracą?

Spojrzałbym na to, jak nie zastosował SoC w swoim kodzie / projekcie i zamieniłem to w rzeczywisty przykład, z którym mógł się odnosić i co jest oczywiście niepożądane.

Na przykład, jeśli ma klasę, w której klient musi dostarczyć kilka informacji, które nie są istotne dla tych klientów, skorzystałbym z analogii piekarni, w której musisz przynieść własne ziarna i drożdże, jeśli chcesz kupić chleb.

Jednym z przykładów może być programista html, który może chcieć rozdzielić html, css i javascript na osobne pliki. W ten sposób możesz zmienić wygląd czegoś, mówiąc po prostu modyfikując css lub zachowanie czegoś poprzez zmianę pliku javascript ładowanego osobno. Jeśli masz responsywną lub adaptacyjną stronę, ten paradygmat działa dobrze, ponieważ możesz załadować różne css lub javascript w zależności od okienka użytkownika lub agenta użytkownika. Jednak jeśli zmodyfikujesz HTML lub szablon, istnieje prawdopodobieństwo, że albo css, albo javascript może się zepsuć. Te odrębne obawy mogą być również zależne.

Innym podejściem jest spakowanie całego javascript i HTML css w grupę komponentów lub modułów. Oznacza to, że możesz wprowadzać zmiany w jednym module i nie powinno to wpływać na inne komponenty lub moduły na stronie, które są obok niego powiązane, nie są powiązane. Tutaj pliki css, js i html są scalane w jeden komponent, który można przetestować jednostkowo. Tak więc rozdzielenie problemów ma postać pojedynczych składników atomowych, które można testować jednostkowo, a nie oddzielenia znaczników, stylu i elementów behawioralnych. To drugie podejście jest bardziej odpowiednie do tworzenia bardziej złożonych aplikacji internetowych.

edytować. Ponieważ otrzymałem negatywną odpowiedź na ten komentarz, pomyślałem, że ponownie go odwiedzę i spróbuję zakwalifikować niektóre z moich pow. Niestety, każda informacja zwrotna tutaj nie jest szczególnie konstruktywna, ale widziałem ciekawą dyskusję gdzie indziej, która patrzy na React, obecną gorącą technologię w tworzeniu stron internetowych, przykład ze świata rzeczywistego i pyta, czy to łamie separację obaw, a w szczególności, czy łamie zasady metodologii projektowania zorientowanego obiektowo SOLID Feather.

Techniczna perspektywa programisty 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.

Perspektywa projektanta 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.

Perspektywa zespołu

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

Na stronie znajduje się również link do interesującej prezentacji Pete Hunta z Facebooka, w której mówi on o komponentach, a nie o szablonach i rozróżnia obawy w aplikacji językowej, a nie wyodrębnia obawy dotyczące frameworka, tj. Szablony, css i javascript itp.

Jeśli chodzi o rozróżnianie swoich obaw w języku aplikacji, może to obejmować użycie różnych wzorców do oddzielenia lub oddzielenia kodu do postaci modułowej, która może być testowana jednostkowo itp.

Podsumowując, wyodrębnienie problemów może zależeć od twojej roli lub punktu widzenia, jak wspomniano gdzie indziej.