이해하기 쉬운 부분으로 문제를 분할하는 방법은 무엇입니까?

Question

이 주제에 대한 일반적인 조언을 할 수 있는지 확실하지 않지만 시도하십시오. 설명하기에는 너무 복잡하기 때문에 내 사례를 설명하기가 어렵습니다. 그리고 그것은 정확히 문제입니다.

나는 프로젝트의 일부를 디자인하려고하는 상황에서 끊임없이 걸려 넘어지는 것처럼 보이지만, 그것을 이해할 수 없을 정도로 많은 것을 고려해야 할 것들이 너무 많습니다.

내 시스템을 한 번에 작은 조각으로 보는 방법에 대한 일반적인 팁이나 조언이 있습니까? 자체적으로 별도로 설계 할 수있는 작은 부분을 찾는 방법은 무엇입니까?

Answer 1

주요 목표는 다음과 같습니다.

• 높은 응집력: 코드 (메소드, 필드, 클래스)는 한 조각/모듈/파티션 내에서 집중적으로 상호 작용해야합니다. 해야합니다 이해가됩니다 이 요소들이 서로에 대해 알아야합니다. 그들 중 일부가 나머지와 크게 상호 작용하지 않는다는 것을 알게되면, 아마도 다른 곳에 속해 있거나 자신의 파티션을 형성해야합니다. 칸막이와 집중적으로 상호 작용하고 내부 작업에 대해 너무 많이 아는 코드를 찾으면 내부에 속할 것입니다. 일반적인 예는 절차 적 스타일로 작성된 OO 코드에서 찾을 수 있으며 "Dumb"데이터 객체와 "관리자"코드가 작동하지만 실제로 데이터 객체의 일부 여야합니다.
• 느슨한 결합: 상호 작용 ~ 사이 조각/모듈/파티션은 좁고 잘 정의 된 잘 문서화 된 API를 통해서만 발생해야합니다. 이러한 API를 식별하고 구현하는 데 필요한 코드와 어떤 코드를 사용할 것인지 확인하십시오.

Answer 2

용어집을 만듭니다.

다시 말해, 프로그래머의 관점이 아니라 주제에 익숙한 사용자의 관점에서 나온 프로젝트 도메인에 의미있는 용어를 식별하십시오.

그런 다음 용어를 다음과 같이 정의하십시오 정확하게 그리고 별로 당신이 할 수 있듯이. 이 형태의 좋은 정의는 일종의 의사 코드 역할을 할 수 있습니다.

문제의 영역조차 식별하지 않았으므로 임의의 예를 선택하겠습니다. 민간인 직원 시스템에서는 다음과 같은 용어가있을 수 있습니다.

• 철판: 특정 등급 및 단계에서 서비스 기간 (시작일부터 종료 날짜)
• 직원: 특정 SSN과 관련된 일련의 빌릿
• 등급과 단계: 연방 일반 일정의 행 및 열

등등. 이것은 기능 단위를 식별하는 것이 아니라, 당신이하려고하는 것처럼 들리기 때문에, 그것을하기 전에 좋은 준비 단계이므로, 기능적 단계를 잘 정의 된 용어로 표현할 수 있습니다.

Answer 3

하향식 및 상향식 모두 문제 분해에 접근하는 것이 유용합니다.

큰 문제를 둘 이상의 작은 문제로 나누는 데 어려움이있는 경우 해결해야 할 가장 작은 문제를 생각해보십시오. 처리되면 원래 큰 문제에 접근 할 때 더 큰 문제로 결합하는 방법을보기 시작할 수 있습니다.

Answer 4

최소한의 조정으로 코드 덩어리를 복사하고 붙여 넣는 것을 발견하면 "파티션"이라는 것을 알게 된 다음 클래스, 메소드, 기능 또는 무엇이든 만듭니다.

실제로, 전체 객체 지향적 접근법은 그것이 전부입니다. 응용 프로그램을 일을하는 실질적인 일로 생각해보십시오. 사물이 무엇인지, 무엇을하는지 설명하는 의사 코드를 작성하면 이런 식으로 많은 "파티션"을 찾습니다.

Answer 5

여기에 시도가 있습니다.

사람들은 일반적으로 일을하는 데 얼마나 오래 걸리는지를 과소 평가합니다. 프로젝트가 크면 여러 사람이 작업해야 할 가능성이 높으므로이를 염두에두고 계획을 세울 수 있습니다. 이제 사람은 한 영역을 머리에 붙잡을 것으로 예상 될 수 있으므로 그가 어떤 종류의 작업을 해야하는지 정확하게 설명해야합니다.

그래서 한 사람이 심각하게 집중할 수 있도록 가능한 한 많이 포괄 해야하는 직업 설명을 작성해야한다고 말하고 싶습니다. 프로젝트를 원하는 부분으로 나눌 때까지 반복하십시오. 혜택으로 팀을 구성 할 준비가되었습니다. 그러나 부품이 작다는 것을 알게되면 여전히 직접 할 수있을 것입니다.