우려 사항 분리를 다른 사람에게 어떻게 설명합니까?

프로그램이 있다고 상상해보세요. 출시되었습니다. 고객이 와서 그 기능 중 하나를 개선 한 대가를 지불하겠다고 제안합니다. 돈을 받으려면 새 기능을 추가하기 위해 프로그램을 변경해야합니다. 수익 마진에 영향을 미치는 몇 가지 사항은 다음과 같습니다.

1. 변경해야하는 코드의 양
2. 변경하는 것이 얼마나 쉬운 지
3. 다른 고객이 사용중인 기존 기능을 손상시킬 가능성이 얼마나되는지
4. 기존 모델 / 아키텍처를 얼마나 재사용 할 수 있는지

문제를 분리하면 도움이됩니다. 이러한 질문에 대한보다 긍정적 인 답변을 얻을 수 있습니다.

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

댓글

• 금융 현실에 굳건한 답변을 해주셔서 감사합니다. 관리자는 엉성하고이 기본 개념을 무시할 변명이 없습니다.

병원을 살펴보고 간호사, 의사, 의료 보조원, 기술자, 사무 직원, 카페테리아 등 환자에게 치료를 제공하는 데 관련된 모든 역할에 대해 생각해보십시오.

그 방법을 아는 사람이 있습니까? 그들 모두가 일을 완수합니까? 아니, 압도적이기 때문이다. 그들은 서로 다른 책임을 별개의 역할로 분리해야하며 이러한 역할 간의 접점은 매우 구체적입니다.

/ 그녀는 사무실에서 일하고, 예를 들어, 그 사무실의 각 직원의 역할을 설명하고, 그 직원이 업무에 따라 나뉘 지 않으면 어떻게 될까요?

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

예를 들어, 클라이언트가 해당 클라이언트와 관련이없는 여러 정보를 제공해야하는 클래스가 있다면, 저는 당신이 가지고있는 빵집의 비유를 사용합니다. 빵을 사고 싶다면 곡물과 효모를 가져와야합니다.

예를 들어 html 개발자는 html, css 및 javascript를 separa로 분리하고 싶습니다. te 파일. 이렇게하면 개별적으로로드되는 자바 스크립트 파일을 변경하여 CSS 또는 무언가의 동작을 간단히 수정하여 말의 모양과 느낌을 변경할 수 있습니다. 반응 형 또는 적응 형 사이트가있는 경우이 패러다임이 잘 작동하며 사용자 뷰포트 또는 사용자 에이전트에 따라 다른 CSS 또는 자바 스크립트를로드 할 수 있습니다. 그러나 html 또는 템플릿을 수정하면 CSS 또는 javascript가 손상 될 수 있습니다. 이러한 별도의 우려 사항도 종속 될 수 있습니다.

또 다른 접근 방식은 모든 CSS 자바 스크립트와 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 및 자바 스크립트 등의 문제를 분리합니다.

애플리케이션의 언어에서 문제를 분리하는 것과 관련하여 다양한 패턴을 사용하여 코드를 모듈 형식으로 분리하거나 분리 할 수 있습니다. 이는 단위 테스트 등이 될 수 있습니다.

요약하자면 다른 곳에서 언급했듯이 관심사를 분리하는 것은 역할이나 관점에 따라 달라질 수 있습니다.

댓글

• 이것이 ' 이전에서 이루어지고 설명 된 포인트보다 실질적인 것을 제공하지 않는 것 같습니다. 7 개의 답변
• 문제를 분리하는 것은 상황에 따라 다른 접근 방식을 취할 수 있다는 점을 지적하고 있습니다. 이것은 소프트웨어 엔지니어링 분야의 실제 상황에 더 가깝고 처음에는 모순적으로 보일 수있는 html 페이지에서 작업 할 때 취할 수있는 다양한 접근 방식이 있음을 강조합니다.