대규모 시스템 설계를 어떻게 시작합니까?[닫은]

https://stackoverflow.com/questions/15690

08-06-2019
|

문제

제가 대규모 새 시스템의 유일한 개발자가 될 것이라는 언급을 들었습니다.무엇보다도 저는 UI와 데이터베이스 스키마를 디자인할 것입니다.

분명 지도를 받게 되겠지만, 그들의 양말을 벗겨줄 수 있었으면 좋겠습니다.그동안 무엇을 준비해야 하며, 스펙을 가지고 컴퓨터 앞에 앉았을 때 무엇을 염두에 두어야 할까요?

명심해야 할 몇 가지 사항:저는 첫 번째 실제 프로그래밍 직업을 가진 대학생입니다.나는 자바를 사용할 것이다.우리는 이미 자동화된 테스트 등을 갖춘 SCM을 설정했으므로 도구는 문제가 되지 않습니다.

해결책

OOP에 대해 많이 알고 계시나요?그렇다면 구현을 깔끔하게 유지하기 위해 Spring과 Hibernate를 살펴보세요. 직교.그것을 얻으면 TDD가 디자인을 간결하고 간결하게 유지하는 좋은 방법이라는 것을 알게 될 것입니다. 특히 "자동화된 테스트"를 실행하고 있기 때문입니다.

업데이트:첫 번째 답변을 보면 더 이상 동의하지 않을 수 없습니다.특히 Java 공간에서는 객체를 사용하여 애플리케이션을 작업하는 데 대한 많은 멘토/리소스를 찾아야 합니다. 데이터베이스 중심 접근 방식이 아님.데이터베이스 설계는 일반적으로 Microsoft 사용자의 첫 번째 단계입니다(저는 매일 수행하지만 복구 프로그램인 Alt.Net을 사용하고 있습니다).고객에게 제공해야 하는 것에 초점을 맞추고 ORM이 개체를 유지하는 방법을 파악하도록 하면 디자인이 더 좋아질 것입니다.

다른 팁

이것은 내 첫 직장과 매우 흡사합니다.대학을 졸업하자마자 나는 데이터베이스와 비즈니스 로직 레이어를 디자인하라는 요청을 받았고, 다른 사람들은 UI를 관리했습니다.그러는 동안 사장은 내 어깨너머를 바라보며 예전에는 자신의 아기였고 지금은 내 것이 된 아기를 놓지 않으려고 손가락을 찔렀습니다.3년 후, 개발자들은 회사를 떠났고 우리가 실제로 판매할 수 있는 날은 X개월이나 남았습니다.

가장 큰 실수는 너무 야심적이었다는 점이다.이것이 첫 직장이라면, ~ 할 것이다 실수를 하고 너도 ~ 할 것이다 작성한 후 오랜 시간이 지나서 작동 방식을 변경해야 합니다.우리는 데이터베이스 수준과 다른 개발자에게 제공되는 API 모두에서 시스템을 필요 이상으로 복잡하게 만드는 모든 종류의 기능을 갖추고 있었습니다.결국, 모든 것이 한꺼번에 지원하기에는 너무 복잡해서 그냥 죽었습니다.

그래서 내 조언은 다음과 같습니다.

그렇게 큰 일을 혼자서 감당할 자신이 없다면 그렇게 하지 마십시오.고용주에게 알리고 함께 일할 수 있는 사람을 찾거나 고용하여 도움을 줄 수 있도록 하십시오.프로젝트에 사람들을 추가해야 하는 경우 문제가 발생하기 시작한 이후가 아니라 시작 시점에 추가해야 합니다.
제품의 용도를 매우 신중하게 생각하고, 이를 요약하여 설명합니다. 가장 단순한 당신이 생각할 수 있는 요구사항 세트.당신에게 사양을 제공하는 사람들이 기술적이지 않다면, 그들이 작성한 내용이 실제로 효과가 있고 돈을 벌 수 있는지 살펴보십시오.고객 및 영업사원과 대화하고 시장을 이해하세요.
자신이 틀렸다는 것을 인정하는 것은 부끄러운 일이 아닙니다.첫 번째 버전에서 실수를 했기 때문에 전체 시스템을 다시 작성해야 하는 것으로 밝혀지면 가능한 한 빨리 이를 인정하여 이에 접근하는 것이 좋습니다.따라서 첫 번째 버전에서 가능한 모든 상황을 예상할 수 있는 아키텍처를 만들려고 하지 마십시오. 왜냐하면 모든 상황이 무엇인지 모르고 잘못될 수 있기 때문입니다.버리고 다시 시작하는 눈으로 한 번 쓰세요. 꼭 그럴 필요는 없을 수도 있고, 첫 번째 버전은 괜찮을 수도 있지만, 그렇다면 인정하세요.

나는 또한 데이터베이스로 시작하는 것에 동의하지 않습니다.DB는 단순히 비즈니스 개체가 지속되는 방식에 대한 인공물입니다.Java에는 이에 상응하는 도구가 없지만 .Net에는 다음과 같은 뛰어난 도구가 있습니다. 서브소닉 이를 통해 비즈니스 개체 설계를 반복할 때 DB 설계를 유동적으로 유지할 수 있습니다.무엇보다도 (어떤 기술을 도입할지 결정하기 전에도) 프로세스에 집중하고 명사와 동사를 식별해야 한다고 말하고 싶습니다.그런 다음 해당 추상화를 기반으로 구축하세요.안녕하세요, OOP 101에서 가르쳐드린 것처럼 "실제 세계"에서는 실제로 작동합니다!

코딩을 시작하기 전에 데이터베이스 스키마를 계획하세요. 다른 모든 것은 그 스키마에서 시작됩니다.초기에 데이터베이스를 합리적으로 정확하게 설정하면 나중에 시간과 골치 아픈 일을 줄일 수 있습니다.

가장 중요한 것은 시스템의 복잡성을 추상화하여 시작하자마자 시스템에 얽매이지 않도록 하는 것입니다.

먼저 스펙을 이야기처럼 읽어보세요(훑어보기).모든 요구 사항에서 바로 분석을 중단하지 마십시오.이렇게 하면 너무 많은 세부 정보 없이도 시스템의 전체적인 그림을 얻을 수 있습니다.이 시점에서 시스템의 주요 기능 구성 요소를 식별하기 시작합니다.이것들을 내려놓으세요(원한다면 마인드맵 도구를 사용하세요).
그런 다음 각 구성 요소를 가져와 분해를 시작합니다(각 세부 사항을 사양 문서의 요구 사항과 연결).모든 요구 사항을 충족할 때까지 모든 구성 요소에 대해 이 작업을 수행합니다.
이제 구성 요소 간의 관계와 다양한 구성 요소에 반복되는 기능이 있는지(그런 다음 유틸리티 구성 요소 등을 만들기 위해 끌어낼 수 있음) 살펴보기 시작해야 합니다.지금쯤이면 마음 속에 요구 사항에 대한 상세 지도가 그려져 있을 것입니다.
이제 데이터베이스, ER 다이어그램, 클래스 디자인, DFD, 배포 등을 디자인해야 합니다.

마지막 단계를 먼저 수행할 때의 문제점은 애초에 전반적인 이해를 얻지 못한 채 시스템의 복잡성으로 인해 수렁에 빠질 수 있다는 것입니다.

나는 그것을 반대 방향으로 한다.데이터베이스 스키마 우선 작업을 수행하면 시스템이 지속성에서 추상화하기 어려운 데이터 중심 설계에 갇히게 됩니다.우리는 도메인 모델 디자인을 먼저 시도합니다 그런 다음 이를 기반으로 데이터베이스 스키마를 기반으로 합니다.

그리고 인프라 설계가 있습니다.팀은 무엇보다도 프로그램을 구성하는 방법에 대한 규칙을 정해야 합니다.그런 다음 우리는 시스템의 공통 기능(예: 지속성, 로깅 등과 같이 모든 사람에게 필요한 것)을 위한 설계에 먼저 합의하기 위해 협력합니다.이것이 시스템의 틀이 됩니다.

우리는 나머지 기능을 서로 나누기 전에 먼저 함께 작업합니다.

내 경험에 따르면 데이터베이스를 마지막으로 고려하는 Java 애플리케이션(.NET도 마찬가지)은 기업 환경에 배치할 때 성능이 저하될 가능성이 높습니다.청중에 대해 진지하게 생각해야 합니다.웹 앱인지 아닌지는 말하지 않았습니다.어느 쪽이든 데이터 처리 방법을 고려할 때 구현하는 인프라가 중요합니다.

어떤 방법론을 고려하더라도 데이터를 얻고 저장하는 방법과 그것이 성능에 미치는 영향이 최우선 순위 중 하나가 되어야 합니다.

이 애플리케이션이 어떻게 사용될지 생각해 보는 것이 좋습니다.미래의 사용자는 어떻게 작업하게 될까요?이 응용 프로그램이 처리해야 하는 사항에 대해 최소한 몇 가지 사항을 알고 계시리라 확신합니다. 하지만 제가 먼저 드리는 조언은 "사용자와 그 사용자에게 필요한 것이 무엇인지 생각해 보십시오"입니다.

코드를 분할할 위치를 생각하면서 일반 종이에 그립니다.논리를 GUI 코드와 혼합하지 마십시오(공통 오류).이렇게 하면 향후에 서블릿 및/또는 애플릿 또는 어떤 플랫폼이 나오더라도 애플리케이션 범위를 확장할 수 있습니다.모든 것을 다시 빌드하지 않고도 대규모 변경 사항에 더 빠르게 대응할 수 있도록 레이어로 섹션을 구분합니다.레이어는 가장 가까운 이웃 레이어 이외의 다른 레이어를 볼 수 없습니다.

진정한 핵심 기능으로 시작하세요.시간이 많이 걸리는 허술한 작업(이로 인해 프로젝트가 4주 지연될 수 있음)은 대부분의 사용자에게 별 문제가 되지 않습니다.나중에 제 시간에 배송할 수 있다고 확신하면 추가할 수 있습니다.

그런데.이것이 디자인과는 아무 관련이 없지만 제 시간에 배달되지 않을 것이라고 말씀드리고 싶습니다.시간 소모에 대해 현실적인 추정을 하고 그 시간을 두 배로 늘립니다. :-) 여기서는 이 프로젝트에 혼자가 아닐 것이며 프로젝트가 진행됨에 따라 사람들이 오고 갈 것이라고 가정합니다.프로젝트 중간에 사람들을 교육해야 할 수도 있고, 휴가를 가거나 수술이 필요할 수도 있습니다.

큰 시스템을 작은 조각으로 분할합니다.그리고 일반적으로 그렇지 않기 때문에 그렇게 복잡하다고 생각하지 마십시오.너무 복잡하게 생각하면 생각이 망가지고 결국 디자인이 망가질 뿐입니다.어떤 시점에서는 같은 일을 더 쉽게 할 수 있다는 것을 깨닫고 다시 디자인하게 됩니다.

적어도 이것은 디자인에 있어서 나의 큰 실수였습니다.

간단하게 유지하세요!

나는 새로운 대규모 프로젝트를 시작하는 것에 관해 매우 통찰력 있는 아이디어를 찾았습니다.

일반적인 모범 사례
테스트 주도 개발
그리고 실용적인 접근 방식

책에서 테스트를 통해 객체 지향 소프트웨어 성장.

아직 개발 중이지만 처음 3장은 귀하가 찾고 있는 내용이고 읽을 가치가 있는 IMHO일 수 있습니다.

라이센스 : CC-BY-SA ~와 함께 속성

제휴하지 않습니다 StackOverflow