내가 고민하는 한 가지는 코드를 작성하기 전에 애플리케이션의 아키텍처를 계획하는 것입니다.
애플리케이션이해야 할 일을 좁히기위한 요구 사항을 수집하는 것이 아니라 전체 클래스, 데이터 및 흐름 구조를 배치하는 좋은 방법을 효과적으로 생각하고 이러한 생각을 반복하여 신뢰할 수있는 계획을 세웁니다. IDE를 열기 전에 염두에 두어야합니다. 현재로서는 IDE를 열고 빈 프로젝트를 만들고 비트와 봅슬레이 작성을 시작하고 거기에서 디자인이 '성장'하도록하는 것이 모두 쉽습니다.
나는 UML을 수집하는 것이 이것을 수행하는 한 가지 방법이지만 경험이 없어서 모호한 것처럼 보입니다.
어떻게 당신은 코드를 작성하기 전에 응용 프로그램의 아키텍처를 계획? UML이 갈 길이라면, 작은 응용 프로그램 개발자에게 간결하고 실용적인 소개를 권할 수 있습니까?
귀하의 의견에 감사드립니다.
답변:
다음을 고려합니다.
그런 다음 시스템을 블랙 박스로보기 시작합니다.
그러면 다양한 내부 블랙 박스로 구성된 시스템보기가 시작되며, 각 블랙 박스는 동일한 방식으로 더 세분화 될 수 있습니다.
UML은 그러한 행동을 나타내는 데 매우 좋습니다. UML의 여러 구성 요소 중 두 가지를 사용하여 대부분의 시스템을 설명 할 수 있습니다.
설명해야하는 동작에 병렬 처리가있는 경우 활동 다이어그램도 필요할 수 있습니다.
학습 UML을위한 좋은 자원은 (마틴 파울러의 훌륭한 책 "UML 증류"입니다 아마존 링크 가 (밖으로 스크립트 키디 링크 나치에 대한 살균 - : -.)이 책은 당신의 각 구성 요소의 본질적인 부분에 잠깐 모습을 제공 UML.
오. 제가 설명한 것은 Ivar Jacobson의 접근 방식입니다. Jacobson은 OO의 Three Amigos 중 하나입니다. 사실 UML은 처음에는 Three Amigos, Grady Booch 및 Jim Rumbaugh를 구성하는 다른 두 사람이 개발했습니다.
Steve McConnell의 Code Complete, 특히 "Design in Construction"에 대한 공짜 챕터를 반드시 확인해야합니다.
그의 웹 사이트에서 다운로드 할 수 있습니다.
.NET 용으로 개발하는 경우 Microsoft는 방금 Application Architecture Guide 2.0b1을 게시했습니다 (무료 전자 책으로!) . 코드를 작성하기 전에 아키텍처 계획에 대한 정말 좋은 정보를 많이 제공합니다.
필사적이라면 .NET 기반이 아닌 아키텍처에 많은 양을 사용할 수있을 것으로 기대합니다.
나는 대부분의 아키텍처가 이미 사전에 결정된 웹 개발 (WebForms, 현재 MVC)을 주로 수행하며 대부분의 프로젝트는 1 년도 채 걸리지 않는 소규모의 1 인 작업이라고 말하면서 서문을 시작할 것입니다. 또한 비즈니스 개체와 데이터 상호 작용을 각각 처리하기 위해 ORM과 DAL이 있다는 것도 알고 있습니다. 최근에 저는이를 위해 LINQ를 사용하도록 전환했습니다. 너무 많은 "디자인"이 DBML 디자이너를 통한 데이터베이스 디자인 및 매핑이됩니다.
일반적으로 TDD (테스트 주도 개발) 방식으로 작업합니다. 나는 건축 또는 디자인 세부 사항에 대해 미리 작업하는 데 많은 시간을 소비하지 않습니다. 저는 스토리를 통해 사용자와 애플리케이션의 전반적인 상호 작용을 수집합니다. 스토리를 사용하여 인터랙션 디자인을 작업하고 응용 프로그램의 주요 구성 요소를 발견합니다. 저는이 과정에서 고객과 함께 많은 화이트 보드 작업을합니다. 때로는 디지털 카메라로 세부 사항이 다이어그램 형식으로 유지하기에 충분히 중요하다고 생각되면 캡처합니다. 주로 내 이야기는 위키에서 이야기 형식으로 캡처됩니다. 결국 스토리는 릴리스와 반복으로 구성됩니다.
이때 쯤이면 보통 아키텍처에 대해 꽤 잘 알고 있습니다. 복잡하거나 비정상적인 부분이있는 경우 (일반적인 관행과 다른 것) 또는 다른 사람 (일반적이지 않음)과 함께 작업하는 경우 (다시 화이트 보드에) 다이어그램을 작성합니다. 복잡한 상호 작용의 경우도 마찬가지입니다. 페이지 레이아웃과 흐름을 화이트 보드에 디자인하여 해당 섹션을 완료 할 때까지 유지 (또는 카메라를 통해 캡처) 할 수 있습니다. 내가 어디로 가고 무엇을 먼저해야하는지에 대한 일반적인 아이디어를 얻은 후에는 첫 번째 이야기에 대한 테스트를 작성하기 시작합니다. 일반적으로 다음과 같이 진행됩니다. "좋아요. 이렇게하려면이 수업이 필요합니다.이 수업부터 시작하겠습니다.이 수업을 수행해야합니다." 그런 다음 즐겁게 TDDing을 시작하고 아키텍처 / 디자인은 애플리케이션의 요구 사항에 따라 성장합니다.
주기적으로, 나는 약간의 코드를 다시 작성하고 싶거나 "이것이 정말 냄새가 난다"고 생각하고 중복을 제거하거나 냄새 나는 비트를 더 우아한 것으로 대체하기 위해 내 디자인을 리팩토링 할 것입니다. 대부분은 좋은 디자인 원칙을 따르면서 기능을 낮추는 데 관심이 있습니다. 나는 알려진 패턴을 사용하고 당신이 따라갈 때 좋은 원칙에주의를 기울이는 것이 꽤 잘 작동한다는 것을 알았다.
http://dn.codegear.com/article/31863
저는 UML을 사용하고 있으며 그 가이드가 매우 유용하고 읽기 쉽습니다. 다른 것이 필요하면 알려주세요.
UML은 표기법입니다. 그것은 당신의 디자인을 기록하는 방법이지만 (제 생각에는) 디자인을하는 것이 아닙니다. 글을 써야한다면 UML을 추천합니다. "최고"이기 때문이 아니라 다른 사람들이 이미 읽는 방법을 알고있는 표준이기 때문에 자신의 "표준"을 만드는 것보다 뛰어납니다.
UML에 대한 최고의 소개는 여전히 Martin Fowler의 UML Distilled 라고 생각합니다 . 왜냐하면 간결하고 사용 위치에 대한 실용적인 지침을 제공하고이를 위해 전체 UML / RUP 스토리를 구매할 필요가 없음을 분명히하기 때문입니다. 유용한
디자인은 어렵고 하나의 StackOverflow 답변으로 캡처 할 수 없습니다. 안타깝게도 저의 디자인 기술은 수년에 걸쳐 발전해 왔기 때문에 참조 할 수있는 출처가 하나도 없습니다.
그러나 내가 유용하다고 생각한 모델 중 하나는 견고성 분석입니다 (Google에 대해서는 여기 에 소개가 있습니다 ). 시스템이해야 할 일, 관련된 일에 대한 도메인 모델에 대한 유스 케이스가 있다면, 견고성 분석이 둘을 연결하고 시스템의 주요 구성 요소가 무엇이어야하는지 알아내는 데 유용한 도구임을 발견했습니다. .
그러나 가장 좋은 조언은 널리 읽고 열심히 생각하고 연습하는 것입니다. 순전히 가르 칠 수있는 기술이 아닙니다. 실제로해야합니다.
나는 조금 이상 미리 계획 할만큼 똑똑하지 않다. 미리 계획을 세울 때 내 계획은 항상 틀렸지 만 지금 은 나쁜 계획에 n 일을 보냈습니다 . 내 한도는 화이트 보드에서 약 15 분인 것 같습니다.
기본적으로 나는 내가 올바른 방향으로 가고 있는지 알아 내기 위해 할 수있는 한 적은 일을한다.
중요한 질문에 대한 내 디자인을 살펴 봅니다. A가 B에서 C로 전환 될 때 D가 충분히 빠를까요? 그렇지 않다면 다른 디자인이 필요합니다. 이러한 각 질문에 대한 답은 급증 할 수 있습니다. 스파이크가 좋아 보이면 디자인이있는 것이므로 확장해야 할 때입니다.
나는 가능한 한 빨리 실제 고객 가치를 얻는 방향으로 코딩하여 고객이 내가 어디로 가야하는지 말할 수 있습니다.
나는 항상 일이 잘못되기 때문에 리팩토링에 의존하여 올바른 일을합니다. 리팩토링은 위험하므로 이동하면서 단위 테스트를 작성해야합니다. 사실 후 단위 테스트를 작성하는 것은 커플 링 때문에 어렵 기 때문에 먼저 테스트를 작성합니다. 이 일에 대해 훈육을 유지하는 것은 어렵고, 다른 두뇌는 사물을 다르게 보는 것이므로 친구와 코딩하는 것을 좋아합니다. 코딩 친구는 코가있어서 정기적으로 샤워를합니다.
그것을 "극단적 인 프로그래밍"이라고합시다.
"화이트 보드, 스케치 및 포스트잇 노트는 훌륭한 디자인 도구입니다. 복잡한 모델링 도구는 조명보다 산만 해지는 경향이 있습니다." 에서 벤 카트 Subramaniam 앤디 헌트에 의해 애자일 개발자의 사례 .
나는 아무것도 할 수 있다고 확신하지 않는다구현하기 전에 미리 계획해야합니다. 나는 10 년의 경험을 가지고 있지만 그것은 단지 4 개 회사 (한 회사의 2 개 사이트 포함, 거의 정반대에 해당하는 사이트 포함) 뿐이며 거의 모든 경험이 거대한 클러스터를 시청하는 것입니다 ****** **가 발생합니다. 리팩토링과 같은 것들이 일을하는 가장 좋은 방법이라고 생각하기 시작했습니다.하지만 동시에 제 경험이 제한적이라는 것을 깨닫고 제가 본 것에 반응 할 수도 있습니다. 내가 정말로 알고 싶은 것은 최고의 경험을 얻는 방법이므로 적절한 결론에 도달 할 수 있지만 지름길이없는 것 같고 사람들이 잘못하는 것을 보는 데 많은 시간이 소요됩니다. 사람들이 일을 제대로하는 회사에서 일하고 싶습니다 (성공적인 제품 배포로 입증 됨).
저는 다른 점을 간청합니다 : UML은 애플리케이션 아키텍처에 사용될 수 있지만 기술 아키텍처 (프레임 워크, 클래스 또는 시퀀스 다이어그램 등)에 더 자주 사용됩니다. 다이어그램이 개발과 가장 쉽게 동기화 될 수있는 곳이기 때문입니다. .
애플리케이션 아키텍처 는 일부 기능 사양 (향후 구현에 대한 가정을하지 않고 작업의 특성과 흐름을 설명)을 취하고이를 기술 사양으로 변환 할 때 발생합니다.
이러한 사양은 일부 비즈니스 및 기능 요구 사항 을 구현 하는 데 필요한 응용 프로그램 을 나타냅니다 .
따라서 여러 대규모 재무 포트폴리오 (기능 사양)를 처리해야하는 경우 해당 대규모 사양을 다음과 같이 나눌 필요가 있다고 결정할 수 있습니다.
따라서 기본적으로 애플리케이션 아키텍처 에 대해 생각 하는 것은 일관된 방식으로 개발해야하는 "파일 그룹"을 결정하는 것입니다 (동일한 파일 그룹에서 런처, GUI, 디스패처 등을 개발할 수 없습니다. 같은 속도로 진화 할 수 없습니다)
응용 프로그램 아키텍처가 잘 정의 된 경우, 각 구성 요소는 일반적으로에 대한 좋은 후보입니다 구성 VCS는 (버전 제어 시스템)로 모든으로 versionned 수있는 파일의 그룹 인 요소, 즉 모든 해당 파일은 될 것입니다 해당 응용 프로그램의 스냅 샷을 기록해야 할 때마다 함께 레이블을 지정합니다 (다시 말하지만 모든 시스템 에 레이블을 지정하기가 어렵고 각 응용 프로그램이 동시에 안정된 상태에있을 수 없음).
나는 내 생각을 두 가지 영역으로 나누려고 노력한다 : 내가 조작하려는 것의 표현과 그것들로 내가하려는 것.
내가 조작하려는 항목을 모델링하려고 할 때 일련의 개별 항목 정의를 제시합니다. 전자 상거래 사이트에는 SKU, 제품, 고객 등이 있습니다. 또한 주문 또는 카테고리와 같이 작업중인 비 물질적 인 것들도 있습니다. 시스템에 모든 "명사"가 있으면 이러한 개체가 서로 어떻게 관련되어 있는지 보여주는 도메인 모델을 만들 것입니다. 주문에는 고객과 여러 SKU가 있고 많은 skus는 제품으로 그룹화됩니다. 의 위에.
이러한 도메인 모델은 UML 도메인 모델, 클래스 다이어그램 및 SQL ERD로 표현 될 수 있습니다.
일단 시스템의 명사를 알아 내면 동사로 넘어갑니다. 예를 들어 이러한 각 항목이 명령을 내리기 위해 거치는 연산입니다. 이들은 일반적으로 내 기능 요구 사항의 사용 사례에 잘 매핑됩니다. 내가 찾은이를 표현하는 가장 쉬운 방법은 UML 시퀀스, 활동 또는 협업 다이어그램이나 스윔 레인 다이어그램입니다.
이것을 반복적 인 프로세스로 생각하는 것이 중요합니다. 도메인의 작은 부분을 수행 한 다음 작업을 수행 한 다음 다시 돌아갑니다. 이상적으로는 제가 진행하는 동안 작업을 시도 할 수있는 코드를 작성할 시간이있을 것입니다. 설계가 애플리케이션보다 너무 앞서 나가는 것을 원하지는 않습니다. 이 프로세스는 모든 것을위한 완전하고 최종적인 아키텍처를 구축하고 있다고 생각하는 경우 일반적으로 끔찍합니다. 정말로, 당신이하려는 것은 팀이 개발을 진행하면서 공통적으로 공유 할 기본 기반을 구축하는 것입니다. 당신은 대부분 팀원들이 시스템을 설명 할 때 사용할 수있는 공유 어휘를 만들고 있으며, 어떻게해야하는지에 대한 법을 정하지 않습니다.
코딩하기 전에 시스템을 완전히 생각하는 데 어려움을 겪고 있습니다. 나중에 야 생각했던 것보다 훨씬 더 복잡하다는 것을 깨닫게되는 일부 구성 요소를 피상적으로 훑어 보는 것은 너무 쉽습니다.
한 가지 해결책은 정말 열심히 노력하는 것입니다. 어디서나 UML을 작성하십시오. 모든 수업을 듣습니다. 다른 수업과 어떻게 상호 작용할지 생각하십시오. 이것은하기 어렵다.
제가 좋아하는 것은 처음에 일반적인 개요를 만드는 것입니다. 나는 UML을 좋아하지 않지만 요점을 이해하는 다이어그램을 그리는 것을 좋아합니다. 그런 다음 구현하기 시작합니다. 빈 메서드를 사용하여 클래스 구조를 작성하는 동안에도 이전에 놓쳤던 것을 자주보고 디자인을 업데이트합니다. 코딩을하면서 다른 작업이 필요하다는 것을 깨닫게되므로 디자인을 업데이트하겠습니다. 그것은 반복적 인 프로세스 입니다. "모든 것을 먼저 디자인 한 다음 모두 구현"이라는 개념은 폭포 모델로 알려져 있으며 다른 사람들은 이것이 소프트웨어를 수행하는 나쁜 방법임을 보여 주었다고 생각합니다.