하향식 또는 상향식을 설계하는 것이 바람직합니까?

내가 알다시피, 하향식 디자인은 가장 작은 빌딩 블록이 정의 될 때까지 추상적 인 높은 수준의 개념을 더 작은 콘크리트와 이해하기 쉬운 부분으로 구체화하는 것입니다. 반면, 상향식은 저수준 부품을 정의한 다음 전체 시스템이 형성 될 때까지 점차 높은 수준의 블록을 구성합니다.

실제로 두 가지 방법을 결합하는 것이 가장 좋습니다. 높은 수준의 사양으로 시작하여 도메인 지식, 관계 및 제약 조건을 완전히 지정합니다. 일단 문제가 잘 이해되면 시스템을 구축하기 위해 가장 작은 빌딩 블록이 생성됩니다.

과정 :

• 요구 사항 스펙 작성
• 설계 사양 생성 (다이어그램 포함)
• 도구
• 배달
• 반복 (각 단계에서 전체 청크를 수행하지 않고 반복 개발에서 각각 조금씩 반복하고 고객의 동적 요구 사항에 맞게 매일 회의를 가짐)

나에게 완벽하게 정상으로 보입니다 (사양은 계획입니다). 결함이 있지만 반복 개발이 필요한 이유는 한 단계에서 시간을 소비하는 대신, 요구 사항 분석은 도메인 지식에서 가능한 모든 것을 변화시키기 위해 (매일 매일) 연구해야한다는 것입니다. 약간의 디자인을 한 다음 구현하십시오.

또 다른 방법은 각 반복이 미니 워터 폴 방식으로, 며칠 (또는 일주일) 이내에 분석이 수행되는 것입니다. 디자인에도 동일하게 적용됩니다. 나머지 시간은 구현에 소비됩니다. 반복 개발과 함께 하향식 접근 방식에 본질적으로 잘못된 것이 있습니까?

자신의 에세이 Programming Bottom Up 에서 Paul Graham은 아래에서 위로 완전히 빌드하거나 아래에서 위로 프로그래밍 하도록 권장하지만 요구 사항 분석 / 디자인 단계는 권장하지 않습니다.

숙련 된 Lisp 프로그래머는 프로그램을 다르게 나눕니다. 하향식 설계뿐만 아니라 상향식 설계라고하는 원칙을 따릅니다. 문제에 맞게 언어를 변경합니다.

내가 알기로는 그가 Lisper가 여전히 하향식 설계를 수행하지만 프로그램을 상향식으로 처리한다는 것이 의미하는 바입니까? 그가 쓴 또 다른 요점 :

상향식 디자인은 동일한 프로그램을 다른 순서로 작성하는 것을 의미하지는 않습니다. 상향식으로 작업 할 때는 대개 다른 프로그램으로 끝납니다. 단일 모 놀리 식 프로그램 대신 더 추상적 인 연산자와 더 작은 프로그램으로 작성된 더 큰 언어를 얻게됩니다. 상인방 대신 아치를 얻을 수 있습니다.

이것은 Lisp에서 프로그램을 작성하는 동안 일반 도구를 사용한다는 의미입니까?

하향식은 내가 아는 것을 설명하거나 이미 구축 한 것을 재건하는 좋은 방법입니다.

하향식 가장 큰 문제는 종종 단순히 "정상"이 없다는 것입니다. 시스템을 개발하거나 도메인을 탐색하는 동안 시스템이 수행해야하는 작업에 대한 생각이 바뀔 것입니다. 모르는 것 (즉, 시스템이 원하는 것)을 어떻게 시작점이 될 수 있습니까?

"로컬"하향식은 좋은 것입니다 ... 코딩에 앞서 생각하는 것은 분명히 좋습니다. 그러나 계획하고있는 것이 실제 시나리오가 아니기 때문에 (생각하지 않고 재건축하는 경우와 같이) 실제로 시나리오가 아니기 때문에 너무 많은 생각과 계획은 아닙니다. 새로운 것을 만들 때의 글로벌 하향식은 말도 안됩니다.

문제의 100 %를 알지 않는 한 상향식은 (전 세계적으로) 접근 방식이어야하며, 코딩 할 알려진 솔루션 만 있으면되고 가능한 대안 솔루션을 찾는 데 신경 쓰지 않아도됩니다.

리스프 방식은 증류 식 상향식입니다. 당신은 바닥을 쌓을뿐만 아니라 필요한 방식으로 벽돌을 만들 수도 있습니다. 아무것도 고정되어 있지 않으며 자유는 총체입니다. 물론 자유는 책임을지고이 힘을 잘못 사용함으로써 끔찍한 것을 만들 수 있습니다.

그러나 끔찍한 코드는 모든 언어로 작성할 수 있습니다. 마음의 새장 모양의 언어조차도 그 언어를 사용하면 원숭이조차도 좋은 프로그램을 실행할 수 있기를 희망합니다 (많은 수준에서 너무 잘못 생각하여 생각조차하지 않습니다).

귀하의 예는 웹 서버에 관한 것입니다. 이제 2012 년에 이것은 잘 정의 된 문제입니다. 스펙을 따라야합니다. 웹 서버는 구현 문제 일뿐입니다. 특히 웹 서버를 다른 웹 서버와 실질적으로 동일한 웹 서버를 작성하는 것을 목표로하고 있다면, 일부 미세한 점을 제외하고는 확실하지 않습니다. RSA에 대한 귀하의 의견조차도 공식적인 사양으로 명확하게 정의 된 문제에 대해 이야기하고 있습니다.

공식적인 사양과 이미 알려진 솔루션으로 잘 정의 된 문제로 코딩은 점으로 연결됩니다. 하향식은 괜찮습니다. 이것이 프로젝트 관리자 천국입니다.

그러나 많은 경우에 점을 연결하는 데 잘 알려진 입증 된 방법이 없습니다. 실제로 점들이 무엇인지 말하기조차 매우 어렵습니다.

예를 들어, 이론적 인 반복 로고와 완벽하게 일치하지 않는 인쇄물에 절단 할 부품을 정렬하도록 자동 절단기에 지시하도록 요청 받았다고 가정하십시오. 기계가 촬영 한 재료의 부품과 사진이 제공됩니다.

정렬 규칙은 무엇입니까? 당신은 결정합니다. 패턴은 무엇이며 어떻게 표현합니까? 당신은 결정합니다. 부품을 정렬하는 방법? 당신은 결정합니다. 부품이 "구부러 질"수 있습니까? 그것은 일부, 그렇지 않은 것도 있지만, 물론 너무 많지는 않습니다. 재료가 너무 잘 변형되어 부품을 수용 가능하게 절단 할 수없는 경우 어떻게해야합니까? 당신은 결정합니다. 모든 재료 롤이 동일합니까? 물론 그렇지는 않지만 사용자가 모든 롤에 대해 정렬 규칙을 적용하도록 버그를 줄 수는 없습니다. 그것은 비현실적입니다. 어떤 사진이 카메라를보고 있습니까? 그 의미는 무엇이든, 그것은 색일 수 있고, 빛의 반사가 패턴을 분명하게하는 검은 색 위에 검은 색일 수 있습니다. 패턴을 인식 한다는 것은 무엇을 의미 합니까? 당신은 결정합니다.

이제이 문제에 대한 솔루션의 일반적인 구조를 설계하고 돈과 시간으로 견적을 제공하십시오. 내 시스템은 심지어 당신의 시스템 아키텍처조차도 (예, 아키텍처) 틀릴 것이라는 점입니다. 비용 및 시간 추정은 임의의 숫자입니다.

우리는 그것을 구현했고 이제는 작동하는 시스템이지만 시스템의 모양에 대해 우리의 마음을 크게 바 꾸었습니다. 메뉴에서 접근 할 수없는 전체 하위 시스템을 추가했습니다. 프로토콜에서 마스터 / 슬레이브 역할을 두 번 이상 전환했습니다. 아마도 이제는 더 나은 재 구축을 시도하기에 충분한 지식이 있습니다.

물론 다른 회사들도 같은 문제를 해결했지만 ... 당신이이 회사들 중 하나에 속하지 않는다면 아마도 하향식 세부 ​​프로젝트는 농담 일 것입니다. 하향식으로 디자인 할 수 있습니다. 전에 한 번도 해본 적이 없기 때문에 할 수 없습니다.

아마도 같은 문제를 해결할 수도 있습니다. 그러나 상향식 작업. 아는 것부터 시작하여 모르는 것을 배우고 추가하는 것.

새로운 복잡한 소프트웨어 시스템이 성장하지 않고 설계되었습니다. 때때로 누군가는 처음부터 완전히 새로운 복잡한 잘못 지정된 소프트웨어 시스템을 설계하기 시작합니다. 또는 c] 둘 다 ... 그리고 대부분의 경우 [c]가 그 경우이다).

이것들은 파워 포인트 슬라이드와 UML 다이어그램에만 수천 시간과 수천 시간을 투자 한 전형적인 대기업 프로젝트입니다. 창피한 양의 리소스를 태운 후에도 완전히 실패합니다. 또는 매우 예외적 인 경우에는 초기 사양의 작은 부분만을 구현하는 고가의 소프트웨어를 마침내 제공합니다. 그리고 그 소프트웨어는 사용자가 항상 싫어하는 것입니다. 구입하려는 소프트웨어의 종류가 아니라 강제로 사용하는 소프트웨어의 종류입니다.

이것은 내가 코딩하는 것만 생각해야한다는 것을 의미합니까? 당연히 아니지. 그러나 제 생각에는 건축은 바닥에서 시작해야하고 (벽돌, 콘크리트 코드) 올라 가야합니다 ... 그리고 세부 사항에 대한 관심과 집중은 당신이 가진 것에서 멀어 질수록 "페이드"되어야합니다. 하향식은 종종 전체 시스템에 동일한 수준의 세부 사항을 한 번에 배치해야하는 것처럼 종종 표시됩니다. 모든 것이 명확해질 때까지 모든 노드를 분할 상태로 유지하십시오. 실제 모듈에서 서브 시스템은 서브 루틴에서 "성장"합니다. 특정 문제에 대한 이전 경험이 없으면 서브 시스템, 모듈 또는 라이브러리의 하향식 설계가 끔찍할 것입니다. 다른 함수가 아닌 어떤 함수를 넣을지 알면 좋은 라이브러리를 디자인 할 수 있습니다.

Lisp 아이디어의 많은 부분이 인기를 얻고 있습니다 (일류 함수, 클로저, 동적 타이핑, 가비지 콜렉션, 메타 프로그래밍, 대화식 개발). Lisp는 여전히 코드를 작성하는 방법이 매우 독창적입니다. 필요한 것을 위해.

예를 들어 키워드 매개 변수는 이미 존재하지만 존재하지 않는 경우 추가 할 수 있습니다. 실험중인 장난감 Lisp 컴파일러에 대해 (컴파일 시간에 키워드 확인 포함) 수행했으며 많은 코드를 사용하지 않습니다.

대신 C ++을 사용하면 얻을 수있는 가장 많은 C ++ 전문가가 키워드 매개 변수가 유용하지 않거나 실제로는 그렇게 복잡하지 않고 매우 부적절하고 절반이 지원되는 템플릿 구현이 가능하다는 것을 알 수 있습니다. C ++ 클래스는 일류 객체입니까? 아니요, 할 수있는 일은 없습니다. 런타임 또는 컴파일 타임에 검사 할 수 있습니까? 아니요, 할 수있는 일은 없습니다.

Lisp의 이러한 언어 유연성은 상향식 건물에 적합합니다. 서브 루틴뿐만 아니라 언어의 구문과 의미도 작성할 수 있습니다. 그리고 어떤면에서 Lisp 자체는 상향식입니다.

이 답변이 Lisp에 어떻게 적용되는지 잘 모르겠지만 방금 Agile Principles, Patterns and Practices 읽기를 마쳤으며 Bob Uncle 저자 는 C #에 대한 하향식 접근 방식을 강력하게 옹호합니다 (C ++에도 적용 가능). 동의하다.

그러나 하향식 접근 방식은 첫 번째 상호 작용에서 문서와 전체 디자인 만 제공한다는 점을 뒷받침하는 다른 답변과 달리이 책은 다른 방법, 즉 진화 적 디자인과 결합 된 TDD를 가리 킵니다.

아이디어는 맨 위에서 시작하여 가장 높은 추상화 레벨 (또는 로컬 최고)을 정의하고 정의하자마자 유용한 기능을 수행하여 기능 # 1이 즉시 작동하도록하는 것입니다. 그런 다음 점점 더 많은 기능을 추가 할 때 항상 SOLID 원리를 인식하면서 코드를 리팩터링하고 필요에 따라 설계를 발전시킵니다.. 이 방법으로 너무 많은 추상화 계층으로 끝나지 않을 것이며 전체 아키텍처에 맞지 않는 저수준 디자인으로 끝나지 않을 것입니다. 이것이 무엇을 의미하는지 잘 모르는 경우, 위에서 언급 한 책은 개발자들이 개념을 취하고 UML 다이어그램과 저수준 클래스로 시작하는 예제가 포함 된 전체 장을 포함하며, 코딩이 실제로 시작된 후에는 해당 클래스의 절반 만 필요하지 않습니다. 본질적으로이 접근 방식에서는 프로젝트에서 더 높은 수준의 세부 정보가 정의 될 때 낮은 수준의 코드가 자연스럽게 푸시 다운됩니다.

마지막으로, SOLID를 연습하는 경우 고급 추상화가 정의 된 상황에서 세부 정보를 얻거나 OOD 또는 추상화가 없음을 갑자기 발견해서는 안됩니다. 그것은 실제로 하향식 디자인의 결함이 아니라 게으른 엔지니어링입니다.

XP와 진화론 적 디자인에 대해 더 자세히 알고 싶으 시다면, 위대한 저술가 인 Martin Fowler의 "Design Dead?"

폴 그래엄 (Paul Graham)이 그의 기사에서하는 가장 중요한 말은 다음과 같습니다.

[...] Lisp 프로그래머 [...]는 문제에 맞게 언어를 변경하는 상향식 디자인이라고 할 수있는 원칙을 따릅니다. Lisp에서는 언어를 향해 프로그램을 작성하는 것이 아니라 프로그램을 향해 언어를 작성합니다.

또는 C ++ 서클에서 알려진 것처럼 라이브러리 디자인은 언어 디자인입니다 (Bjarne Stroustrup)

하향식 설계의 주요 아이디어는 먼저 계획하고 코드를 작성하는 것입니다. Beanow는 그가 작성할 때 정확 하며 , 실행 코드가 프로세스에서 늦게 올 때 문제가 있음을 나타냅니다. 상향식 디자인에는 항상 코드와 테스트 할 수있는 코드가 있습니다.

또한 코드가 평평하지 않습니다. 즉, 더 많은 추상화 수준을 갖는 경향이 있습니다. 하향식 설계에서 사람들은 종종 임의의 수준으로 내려 가고 그 이하로 추상화되지 않는 큰 어색함을 겪습니다. 상향식으로 설계된 코드 OTOH는 추상화 될 가능성이 있기 때문에 낮은 수준의 제어 및 데이터 구조를 포함하지 않는 경우가 많습니다.

이상적으로 Lisp뿐만 아니라 모든 언어로 프로그램을 작성하면 다음 프로그램에서 속도를 높이거나 현재 프로그램의 속도를 향상시킬 수있는 전체 일반 도구 세트를 작성할 수 있습니다.

실제로 이러한 도구를 추적하는 것은 어려울 수 있습니다. 문서가 열악하고 정리가 잘되어 있지 않아 문서를 알고있는 사람들이 떠나게됩니다. 실제로, 코드를 재사용하는 것은 종종 가치보다 더 문제가됩니다. 그러나 코드가 제대로 문서화되고 체계화되어 있고 프로그래머가 유용한 코드를 제공하거나 유지하는 경우 코드를 다시 작성하지 않고웨어 하우스에서 코드를 가져 와서 막대한 양의 작업을 줄일 수 있습니다.

모든 디자인은 하향식이어야합니다. 그렇지 않으면 무엇을하고 있는지 알 수 없습니다. 창고 나 차를 짓고 있습니까? 상향식 디자인으로는 알 수 없습니다. 그러나 왼쪽 앞 바퀴를 만들려는 경우 나중에이 프로젝트와 다른 프로젝트에 더 많은 바퀴가 필요할 수 있습니다. 재사용 가능한 휠을 만들면 하나의 가격으로 4 개가됩니다. (그리고 다음에 건설 할 트랙터-트레일러의 경우 18 개를 모두 무료로 제공합니다.)

실제 자동차 및 실제 휠과 달리 하나의 소프트웨어 "휠"을 구축 한 경우 무한한 수의 소프트웨어를 구축했습니다.

더 하향식 (top-down) 디자인 :이 밖으로 시작해야 할 때, 당신이 경우 지적 할 의무가 느낄 수없는 바퀴를 구축, 당신이 밖으로을 찾아야 하기 전에 당신이 당신의 차에 많은 일을한다. 따라서 하향식 작업과 거의 동시에 상향식 작업이 필요합니다. 또한 바퀴를 만들 수 있다는 사실을 알면 트랙터 트레일러와 같이 이전에는 생각하지 못했던 많은 프로젝트를 제안 할 수 있습니다 . 하향식 접근 방식이 지배적이지만 매우 가벼운 터치로 생각합니다.

따라서 Paul Graham을 계속 말하면 프로그램을 작성할 때 재사용 할 수있는 많은 부분이 생겨 원래 프로그램과 다른 프로그램에서 많은 시간을 절약 할 수 있습니다. Paul Graham과 약간 거리를두기 위해 모든 언어로 작동합니다 (일부는 다른 프로세스보다 프로세스를 권장합니다).

이 거의 마술 같은 과정의 적은 매우 단기적인 시각을 가진 프로그래머입니다. 이는 인격 결함으로 인해 발생할 수 있지만 일반적으로 회사 내부 및 고용 회사간에 직무 전환과 책임을 너무 빨리 전환하여 발생합니다.

반복 개발과 함께 하향식 접근 방식의 문제점은 무엇입니까?

반복 개발과 함께 하향식 접근 방식을 사용하더라도 첫 번째 반복에서 작동 코드를 제공하지 않습니다. 디자인 문서를 제공하며 고객이 피드백을 제공하는 데 어려움을 겪을 수 있습니다. "그렇습니다. (이것은 너무 추상적입니다.")와 같은 응답은 고객이 원하는 시스템의 세부 사항을 더 자세히 지정하는 데 도움이되지 않습니다.

대신 요청 된 사항에 대한 일반적인 개요 만 작성하십시오. (필수 사항) 완제품을 정의하고 구현 우선 순위를 부여 할 대상에 대한 일반 지침으로 사용합니다. 거기서부터 고객은 실제로 반복 할 때마다 실제 제품이 마음에 든 것인지 확인할 수있는 실제 제품을 만듭니다. 그렇지 않다면 고객이 요구하는 것과 다른 시스템을 설계하는 데 수백 시간을 소비하지 않았기 때문에 문제가되지 않습니다.

Paul Graham은 처음부터 끝까지 구축을 장려 했습니까? 또는 아래에서 위로 프로그래밍하지만 요구 사항 분석 / 사망 단계는 아닙니다.

나는 다른 사람을 위해 말하지 않을 것입니다. 또한 나는 그의 에세이를 읽지 않았다. 내가 드리는 대답은 경험뿐만 아니라 교육에서도 나옵니다.

즉, Lisp에서 프로그램을 작성하는 동안 원래 프로그램과 유사한 프로그램을 작성하는 데 사용할 수있는 일반 도구를 사용하게됩니다.

이 접근 방식을 사용하면 더 추상적 인 빌딩 블록이 생깁니다. 간단하게 제시 할 수있는 독립형 서브 시스템을 구축해야하기 때문에 크게 얽혀 있고 한 번에 모두 구현해야하는 하향식 설계를 작성할 수 없습니다. 재사용 성, 유지 관리 성이 향상되지만 무엇보다 변화에보다 유연하게 대응할 수 있습니다.