타인에 대한 우려의 분리를 어떻게 설명합니까?

우려 분리의 이점을 이해하지 못하거나 일상 업무에 일관되게 적용하기에 충분하지 않은 동료가 있다면 어떻게 설명 할 수 있습니까?

릴리스 된 프로그램이 있다고 가정하십시오. 고객이 와서 그 기능 중 하나에 대한 개선에 대한 비용을 지불하도록 제안합니다. 돈을 벌려면 새로운 기능을 추가하기 위해 프로그램을 변경해야합니다. 이익 마진에 영향을 미치는 몇 가지 사항은 다음과 같습니다.

1. 얼마나 많은 코드를 변경해야합니까
2. 변경하기가 얼마나 쉬운가
3. 다른 고객이 사용중인 기존 기능을 중단 할 가능성
4. 기존 모델 / 아키텍처를 재사용 할 수있는 정도

우려를 분리하면 이러한 질문에 대한 긍정적 인 답변을 얻을 수 있습니다.

1. 응용 프로그램의 특정 동작에 대한 모든 코드가 분리 된 경우 새 기능과 직접 관련된 코드 만 변경하면됩니다. 변경할 코드가 적어야합니다.
2. 관심있는 동작이 나머지 응용 프로그램과 깔끔하게 분리되어 있으면 나머지 프로그램을 완전히 이해하거나 조작하지 않고도 새로운 구현으로 바꿀 수 있습니다. 또한 어떤 코드를 변경해야하는지 쉽게 찾을 수 있습니다.
3. 변경하지 않아도되는 코드는 변경 한 코드보다 깨질 가능성이 적습니다. 따라서 문제를 분리하면 호출 할 수있는 코드를 변경하지 않아도되므로 관련없는 기능이 손상되는 것을 방지 할 수 있습니다. 기능이 혼합 된 경우 다른 기능을 변경하려고 할 때 실수로 하나의 동작을 변경할 수 있습니다.
4. 아키텍처가 기술 또는 비즈니스 로직 세부 사항에 무관 한 경우 구현 변경시 새로운 아키텍처 기능이 필요하지 않습니다. 예를 들어, 기본 도메인 논리가 데이터베이스에 무관 한 경우 새 구현을 지속성 계층의 새로운 구현에서 스왑하는 것만 큼 쉬워야합니다.

병원을 살펴보고 환자를 돌보는 데 관여하는 여러 가지 역할, 즉 심사 간호사, 의사, 의료 보조원, 기술자, 사무 직원, 식당 등을 모두 생각해보십시오.

모든 사람들이 자신의 업무를 수행 하는 방법을 아는 사람이 있습니까? 아닙니다. 압도적 일 것입니다. 그들은 서로 다른 책임을 별개의 역할로 분리해야하며 이러한 역할 간의 접점은 매우 구체적입니다.

사무실에서 일하는 경우, 예를 들어 그 사무실에서 각 직원의 역할을 설명하고, 직원이 자신의 직무에 따라 나뉘 지 않으면 어떻게 될지 물어보십시오.

그가 코드 / 디자인에 SoC를 적용하지 못한 방법을 살펴보고 그가 관련시킬 수있는 실제 사례로 바꾸는 것은 분명하지만 바람직하지 않습니다.

예를 들어, 고객이 해당 고객과 관련이없는 몇 가지 정보를 제공해야하는 수업이있는 경우, 구매하려는 경우 곡물과 효모를 가져와야하는 제과점의 비유를 사용합니다. 빵.

html 개발자는 html, css 및 javascript를 별도의 파일로 분리하려고 할 수 있습니다. 이렇게하면 별도로로드 된 자바 스크립트 파일을 변경하여 CSS 또는 무언가의 동작을 수정하여 말의 모양과 느낌을 변경할 수 있습니다. 반응 형 또는 적응 형 사이트가있는 경우이 패러다임은 사용자 뷰포트 또는 사용자 에이전트에 따라 다른 CSS 또는 자바 스크립트를로드 할 수 있으므로 효과적입니다. 그러나 HTML 또는 템플릿을 수정하면 CSS 또는 자바 스크립트가 손상 될 수 있습니다. 이러한 개별적인 문제는 또한 의존적 일 수 있습니다.

또 다른 방법은 모든 CSS javascript 및 html을 구성 요소 또는 모듈 그룹으로 묶는 것입니다. 즉, 한 모듈을 변경할 수 있으며 해당 모듈과 함께 실행되는 페이지의 다른 구성 요소 나 모듈에는 관련이 없습니다. 여기서 CSS, js 및 html 파일은 단위 테스트가 가능한 단일 구성 요소로 병합됩니다. 따라서 관심의 분리는 마크 업, 스타일 및 행동 요소의 분리가 아니라 단위 테스트가 가능한 개별 원자 구성 요소의 형태로 이루어집니다. 이 두 번째 방법은보다 복잡한 웹 응용 프로그램을 만드는 데 더 적합합니다.

편집하다. 이 의견에 대해 부정적인 답변을 받았으므로 다시 방문하여 일부 POV를 검증하려고 생각했습니다. 불행히도 여기에있는 피드백은 특별히 건설 적이지는 않지만 웹 개발의 최신 기술 인 React, 실제 사례를 살펴보고 우려의 분리를 깨뜨릴 것인지 또는 특히 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)를 분리하는 대신 언어 응용 프로그램의 문제를 분리합니다. 기타

응용 프로그램의 언어로 문제를 분리하는 것과 관련하여 다양한 패턴을 사용하여 코드를 단위 테스트 등의 모듈 형태로 분리하거나 분리 할 수 ​​있습니다.

요약하면, 우려를 분리하는 것은 다른 곳에서 언급 한 것처럼 역할이나 관점에 따라 달라질 수 있습니다.