디자인 및 코딩 - 위에서 아래까지 또는 아래에서 위로?

Question

코딩 할 때 더 나은 접근 방법은 무엇입니까?

1. 문제를 충분히 작은 조각으로 나누고 각 조각을 구현하십시오.
2. 문제를 해결 한 다음 하향식 접근 방식을 사용하여 구현하십시오.
3. 기타?

Answer 1

내가하는 일 :

먼저 도메인을 이해하십시오. 해결해야 할 문제를 이해하십시오. 귀하와 고객 (고객이 귀하라고하더라도)이 해결해야 할 문제가있는 페이지와 동일한 페이지에 있는지 확인하십시오.

그런 다음 문제에 대해 높은 수준의 해결책이 제안되고 그로부터 디자인은 페이지의 거품 또는 글 머리 기호로 바뀌지 만 요점은 디자인 할 수있는 구성 요소로 흔들 리게된다는 점입니다.

그 시점에서 필자는 아직 작성하지 않은 클래스에 대한 테스트를 작성한 다음 해당 테스트를 통과하도록 클래스를 완성합니다.

필자는 테스트 우선 접근법을 사용하고 작동하고 테스트 된 구성 요소를 구축합니다. 그것이 나를 위해 일하는 것입니다. 구성 요소 인터페이스가 알려져 있고 '규칙'이 서로 이야기하고 서로에게 서비스를 제공하는 방법으로 알려져있을 때 일반적으로 직선적 인 '모든 것을 하나로 묶는'운동이됩니다.

그게 내가하는 방식이고, 나에게 잘 맞았다.

Answer 2

예. 그 모든 일을하십시오.

죄송합니다 (미안하지만, 나는 형태로 되돌아갑니다). 그러나 이것은 정말로 정답이없는 경우입니다.

Answer 3

두 번째 옵션은 적절한 방법입니다. 문제를 이해할 수있는 덩어리로 분해하면, 모든 세부 사항을 모두 구현하기 전에 하향식 접근 방식으로 주요 디자인 결함을 알 수 있습니다. 모든 것을 함께 묶는 낮은 수준의 기능을위한 스텁을 작성할 수 있습니다.

Answer 4

Agile Manifesto을 살펴볼 수 있습니다. 하향식 및 하향식은 모두 설계된대로 설계 및 시공에 근거합니다.

"포괄적 인 문서에 대한 작업 소프트웨어"는 실행하는 데 사용할 수있는 가장 작은 유용한 것임을 의미합니다. 상단? 바닥? 둘 다.

---

저는 어렸을 때 - 계약에 의해 엄격히 하향 조정 된 프로젝트에 참여했습니다. 이것은 작동하지 않습니다. 실제로 그것은 작동하지 않습니다. 결과적으로 중복되는 산과 코드가 생깁니다. 그것은 어리석게 적용될 때 건전한 접근법이 아니 었습니다.

내가 알아 차 렸던 것은 애자일 방식 (작은 조각이 작동하는)이 문제를 한꺼번에 파악할 수있는 부분으로 나누는 경향이 있다는 것입니다. 하향식/상향식은 더 이상 중요하지 않습니다. 실제로 그것은 전혀 중요하지 않을 수 있습니다.

"어떻게하면 민첩한 개발을 위해 분해합니까?" 트릭은 큰 것을 작성한 다음 분해해야합니다. 문제를 분석 할 경우 모든 정보가 없거나 적시에 제공하지 않았거나 의사 결정을 실행할 수 없기 때문에 유스 케이스를 성취하고 실패한 액터가 발견됩니다.

종종 분해를 필요로하는 큰 것들이 아닙니다. 그럴 때 목표를 방향으로 진행해야합니다. 목표에서부터 인 에이 블러 등을 가능하게하는 목표에 이르기까지 목표를 달성 할 수있게 해주는 것에 이르기까지 목표는 종종 Big Things이기 때문에 일반적인 비즈니스 목표에서 자세한 비즈니스 프로세스 및 단계에 이르기까지 Top Down 경향이 있습니다.

어느 시점에서 우리는 목표를 이끌어내는 이러한 다양한 단계를 대략적으로 설명합니다. 우리는 분석 부분을 끝냈습니다. 이제 합성 부분이 생깁니다. 우리가 가지고있는 것을 실제로 만들 수있는 것으로 재구성합니다. 합성은 상향식입니다. 그러나, 도망 가자. 우리는 여러 관점을 가지고 있습니다. 각각의 관점은 다릅니다.

모델이 있습니다. 이것은 종종 세부 사항에서 더 큰 개념 모델로 만들어집니다. 그런 다음 때로는 OLTP에 대해 표준화 된 모델로 다시 분해됩니다. 또는 OLAP 용으로 표준화 된 스타 스키마로 분해되었습니다. 그런 다음 정규화 된 모델에서 ORM 매핑을 생성하기 위해 백업 작업을 수행합니다. 위 - 아래 - 위로.

처리했습니다.이것은 종종 비즈니스 프로세스 요약에서 처리 단계의 세부 사항으로 작성됩니다. 그런 다음 소프트웨어는 단계별로 설계되었습니다. 그런 다음 소프트웨어는 클래스와 메소드로 분리됩니다. 아래 위로 - 아래로.

[] 우회. 계몽 된 사용자와 함께,이 분해는 새로운 직위와 작업 방식을 정의합니다. 익숙하지 않은 사용자는 이전 작업을 유지하고 이전 작업을 새로운 소프트웨어에 매핑하기 위해 설명서를 작성합니다.]

구성 요소가 있습니다. 우리는 종종 조각을보고, 사용 가능한 구성 요소에 대해 알고있는 것을보고, 일종의 일치를합니다. 이것은 임의의 프로세스입니다. 그것은 결정이 형성되는 방식과 유사합니다. 핵 생성의 중심과 그 중심 주위에 응고하는 디자인 종류가 있습니다. 웹 서비스. 데이터 베이스. 트랜잭션 관리. 공연. 음량. 여러 가지 기능을 통해 우리 솔루션의 일부 또는 전부를 구현하는 구성 요소를 선택하는 데 도움이됩니다. 종종 상향식 (기능에서 제품으로)이긴하지만 때로는 하향식 ("나는 망치를 잡고있어 모든 것을 못이라고 부른다.").

결국 코드를 ​​작성해야합니다. 이것은 아래쪽에 있습니다. 거의. 패키지 구조를 정의해야합니다. 클래스를 전체적으로 정의해야합니다. 그 부분은 위로 내려 갔다. 클래스 내에 메소드를 작성해야합니다. 나는 종종 이것을 상향식으로 수행한다 - 방법을 어루 만지고, 단위 테스트를 작성하고, 방법을 마친다. 다음 방법을 밖으로 러프, 단위 테스트를 작성, 방법을 마칩니다.

운전 원리는 민첩합니다. 작동하는 것을 만드십시오. 세부 사항은지도 전체, 상하, 앞, 뒤, 데이터, 프로세스, 배우, 주제 영역, 비즈니스 가치에 걸쳐 있습니다.

Answer 5

아래쪽 디자인보다 더 많은 부분을 고려해야한다고 생각합니다. 분명히 설계를 관리 가능한 작업 단위로 나눌 필요가 있지만 우선 순위 부여 등을 고려해야합니다. 반복 개발 프로젝트에서는 이전 반복에 대한 솔루션을 제공 한 후 다음 반복을 위해 문제를 재정의하는 경우가 많습니다 .

Answer 6

외부 설계.

상단에서 성취하고자하는 것을 시작하고 하단에서 무엇을해야하는지 알고 있습니다. 중간에 만날 때까지 양쪽 끝을 계속 작동하십시오.

Answer 7

디자인 할 때, 나는 중간 아웃을 좋아합니다. 저는 도메인을 모델링 한 다음 클래스를 설계하고 거기에서 데이터베이스와 UI로 이동합니다.UI 기반 또는 데이터베이스 기반의 특정 기능이있는 경우 해당 기능도 전면 디자인 할 수 있습니다.

코딩 할 때 가능한 한 상향식 (데이터베이스 우선, 비즈니스 엔터티, UI)이 일반적입니다. 나는이 방법으로 일들을 똑바로 유지하는 것이 훨씬 쉽다는 것을 안다.

Answer 8

또한 민첩한 방법으로 테스트를 먼저 작성하십시오!

는 모든 소프트웨어는

• 레드의 지속적인 사이클 - 의도 보존되어 코드 개선 - 코드 테스트
• 팩터를 전달 - 코드는
• 녹색 테스트를 실패합니다.

결함, 새로운 기능, 변경. 모두 같은 패턴을 따릅니다.

Answer 9

모든 사람들이 "어느 쪽도 아니"라고 말하면서 동의하지만 모두가 스펙트럼에 떨어집니다.

저는 더 많은 종류의 사람입니다. 하나의 고수준 기능/포인트/무엇을 선택하고 완전한 프로그램으로 구현합니다. 이를 통해 문제 영역의 범위 내에서 기본 계획과 구조를 스케치 할 수 있습니다.

그런 다음 다른 기능과 리팩터링을 사용하여 두 번째로 사용할 수있는 원본에서부터 새로운 공유 엔티티로 모든 것을 리팩토링합니다. 거품이 잘 흘리면 도포가 완료 될 때까지 반복하십시오.

그러나 나는 문제를 듣고 그 위에 응용 프로그램을 빌드하는 데 필요한 모든 지원 서브 시스템에 대해 생각하기 시작하는 많은 사람들을 알고 있습니다.

나는 접근법이 잘못되었다고 생각하지 않습니다. 둘 다 결과를 얻을 수 있습니다. 나는 심지어 다른 두 가지 관점에서 문제를 공격 할 수 있기 때문에 함께 일할 사람들을 찾는다.

Answer 10

저는 하향식을 디자인하고 상향식으로 구현하는 경향이 있습니다.

구현을 위해 가장 작은 기능 부품을 만들고이를 상위 레벨 구조로 어셈블하는 것이 가장 적합합니다. 그러나 디자인을 위해서는 전반적인 그림부터 시작하여 조각이 무엇인지 결정해야합니다.

Answer 11

둘 모두 유효한 접근 방법입니다. 가끔은 다른 것보다 더 자연 스럽다고 느끼는 경우가 있습니다. 그러나 한 가지 큰 문제가 있습니다. 주로 주류 언어와 특히 프레임 워크와 라이브러리가 인데 구문 강조 표시, 백그라운드 유형 확인, 백그라운드 컴파일, 지능형 코드 완성, IntelliSense 등과 같은 IDE 지원에서 크게입니다.

그러나 은 하향식 코딩에서 작동하지 않습니다! 하향식 코딩에서는 아직 구현하지 않은 변수, 필드, 상수, 함수, 프로 시저, 메소드, 클래스, 모듈, 특성, 믹스 인, 애스펙트, 패키지 및 유형 을 계속 사용합니다. 그래서 IDE는 컴파일 오류 때문에 끊임없이 소리를 지르며 어디에서나 빨간색 구불 구불 한 선이 생기며 코드 완성을 얻지 않을 것입니다. 따라서 IDE는 꽤 많이 이므로에서 하향식 코딩을 금지합니다.

Answer 12

나는 하향식 변형을합니다.인터페이스를 먼저 시도해보고 인터페이스를 사용하는 경향이 있습니다. 그런 다음이를 기능 목록으로 사용합니다. 이 버전의 장점은 여전히 ​​IDE에서 작동하며 그렇지 않으면 불평 할 수 있습니다. 한 함수 호출을 아직 구현되지 않은 것에 주석 처리하십시오.

Answer 13

필자는 훌륭한 소프트웨어 디자이너 (모든 소프트웨어 개발자는 어느 수준의 소프트웨어 디자이너 여야한다고 생각합니다)와 함께, 마법은 하향식과 상향식을 동시에 수행 할 수 있다고 믿습니다.

멘토가 내가 "교육받은"것은 참여한 엔티티를 이해하기 위해 매우 간단한 하향식으로 시작한 다음 아래로 위로 이동하여 만들고 싶은 기본 요소를 파악한 다음 백업합니다. "내면에서 만날 때까지"내 밑바닥 결과에 대해 내가 아는 것을 아는 등 한 단계 아래로 내려갈 수있는 방법을 확인하십시오.

희망이 있습니다.