C#에서 앱 개요 계획: Tim Corey와 함께 큰 그림 배우기

개요 계획 소개

비디오의 시작에서 팀 코리는 레슨 02를 소개하고 초점이 개요 계획, 즉 애플리케이션의 큰 그림이라고 설명합니다. 팀은 이 단계가 앱의 기초를 다지는 것이라고 설명합니다. 그는 이 레슨이 다른 레슨보다 더 쉬워 보일 수 있지만 관리 가능하고, 확장 가능하며, 유지보수 가능한 앱을 만드는 데 중요한 역할을 한다고 강조합니다.

팀은 개요 계획이 기능이나 코드 작성에 관한 것이 아니라고 설명합니다. 애플리케이션이 전체적으로 어떻게 작동할 것인지, 사용자가 어떻게 상호작용할지 그리고 개발자가 어떻게 접근해야 하는지를 이해하는 것입니다.

이해 관계자 질문 검토

팀 코리는 앞으로 나아가기 전에 이전 레슨에서 물었던 15가지 질문을 다시 살펴봐야 한다고 설명합니다. 이 질문들은 애플리케이션을 요청한 사람들, 즉 이해 관계자들로부터 추가 정보를 수집하기 위해 설계되었습니다. 팀은 현실 시나리오에서 개발자가 이해 관계자에게 다시 돌아가 명확화 질문을 하고 더 자세한 답변을 받는 시나리오를 시뮬레이션합니다.

그는 이 과정이 실제 비즈니스 환경을 반영한다고 지적합니다. 개발자는 언제나 사용자가 기술적으로 원하는 것을 어떻게 설명할지 모르기 때문에 여러 질문을 하고 요구 사항을 정재해야 합니다.

가변 플레이어 및 토너먼트 크기

팀은 대답을 검토하기 시작하면서 앱이 가변적인 수의 플레이어를 지원해야 한다고 설명합니다. 토너먼트 트래커는 고정된 숫자로 제한되지 않아야 합니다. 두 명의 참가자든 그보다 훨씬 더 많은 참가자가 있든 앱은 이를 처리해야 합니다.

이 요구 사항은 애플리케이션의 기능, 데이터 구조 및 논리에 직접 영향을 미칩니다. 팀은 개발자가 플레이어 수에 대한 가정을 하드코딩할 수 없다고 설명합니다. 대신, 앱은 입력된 참가자 수에 따라 사용자를 및 게임을 동적으로 관리해야 합니다.

완벽하지 않은 토너먼트에서 부전 처리

팀은 토너먼트가 항상 이상적인 수의 참가자를 가지지는 않을 것이라고 설명합니다. 참가자 수가 정확히 나눠지지 않을 때, 앱은 부전을 배정해야 합니다. 이 시점에 팀은 중요한 규칙을 강조합니다: 부전은 무작위로 배정되어야 합니다.

이는 앱의 반복적인 기술 요구 사항 중 하나인 무작위성을 도입합니다. 앱은 플레이를 하지 않고도 진출하는 사람을 무작위로 선택하여 공정하게 사용자를 관리해야 합니다. 이 요구 사항은 도구, 논리 및 애플리케이션 내의 이벤트에 대한 나중의 결정을 형성합니다.

플레이어의 무작위 순서 지정

팀은 계속해서 누가 누구와 경기를 할지가 무작위가 되어야 한다고 설명합니다. 앱은 사용자가 입력된 순서에 의존해서는 안 됩니다. 모든 플레이어가 추가되면 앱은 목록을 무작위로 섞습니다.

이는 공정성을 보장하고 편향을 피합니다. 팀은 무작위성이 규칙이며 선택적 기능이 아님을 명확히 합니다. 이것은 앱의 핵심 규칙의 일부가 되며 전반적인 개발 과정에서 존중되어야 합니다.

유연한 게임 일정

Tim은 게임이 시스템에 의해 일정이 잡히지 않는다고 설명합니다. 플레이어는 원하는 때에 게임을 할 수 있습니다. 그러나 앱은 여전히 규칙을 적용합니다. 3:04에, Tim은 각 라운드가 다음 라운드가 표시되기 전에 완료되어야 함을 명확히 합니다.

이 요구 사항은 앱이 게임을 추적하는 방식, 데이터를 관리하는 방식, 그리고 이벤트를 발생시키는 방식에 영향을 미칩니다. 앱은 한 라운드가 완료되었을 때를 알고, 사용자가 후속 라운드에 조기에 접근하지 못하도록 해야 합니다.

점수 및 데이터 유연성

Tim은 시스템이 단순한 숫자 점수를 저장해야 한다고 설명합니다. 이렇게 하면 앱이 다양한 유형의 게임을 지원할 수 있을 만큼 유연해집니다. 체커, 농구 또는 다른 경쟁이라도, 같은 앱으로 점수를 관리할 수 있습니다.

이 결정은 데이터가 수집되고, 저장되고, 표시되는 방식에 영향을 미칩니다. 점수를 간단하게 유지함으로써 개발자는 앱을 특정 게임 유형에 고정시키지 않을 수 있습니다.

미래를 염두에 둔 사용자 인터페이스 선택

Tim은 앱이 당분간 Windows Forms를 사용하는 데스크탑 애플리케이션이 될 것이라고 설명합니다. 그러나 그는 이해 관계자가 나중에 같은 앱을 웹 또는 모바일 플랫폼으로 진화시키길 원할 수도 있음을 강조합니다.

이 때문에, Tim은 개발자가 사용자 인터페이스를 비즈니스 로직과 분리해야 한다고 설명합니다. 4:41에, 그는 핵심 기능이 클래스 라이브러리에 있어야 하며, 이후 다양한 사용자 인터페이스가 앱을 다시 작성하지 않고도 통합될 수 있도록 해야 한다고 설명합니다.

데이터 저장 및 통합 전략

Tim은 데이터가 이상적으로는 Microsoft SQL Server에 저장되어야 하지만, 앱은 또한 텍스트 파일을 대체할 수 있도록 지원해야 한다고 설명합니다. 이는 특정 도구나 서비스가 이용 불가할 때에도 앱이 작동하도록 보장합니다.

이 결정은 개발자가 데이터 접근 코드를 작성하는 방식에 영향을 미칩니다. Tim은 통합이 유연해야 하며, 동일한 앱이 서로 다른 소스로부터 데이터를 저장하고 검색할 수 있어야 한다고 설명합니다.

참가 비용, 상품, 그리고 실제 모호성

Tim은 이해 관계자가 종종 모호한 답변을 제공한다고 설명합니다. 처음에는 앱이 참가비와 상품을 처리하는지 여부에 대한 답변이 단순히 '예'입니다. Tim은 개발자가 그 의미를 이해하기 위해 더 깊이 파고들어야 한다고 설명합니다.

그는 이후 설명된 요구 사항을 개요화합니다: 토너먼트는 참가비를 부과할 수 있고, 여러 장소에 상품을 수여할 수 있으며, 지불이 수입을 초과하지 않도록 보장합니다. 그는 또한 비율 기반 지불 및 모금 시나리오를 설명합니다.

이 섹션은 앱 개요 계획이 앱을 과보화하지 않고도 실제 비즈니스 규칙을 예상하는 데 개발자에게 어떻게 도움이 되는지를 보여줍니다.

보고 및 결과 표시

Tim은 보고가 단순해야 한다고 설명합니다. 앱은 라운드 결과와 최종 결과를 표시해야 하며, 승자가 누구인지, 얼마나 많이 이겼는지를 포함해야 합니다. 보고서는 양식에서 표시되거나 이메일로 전송될 수 있습니다.

이렇게 하면 복잡한 보고 시스템을 구축하지 않으면서도 사용자의 기대를 충족시킬 수 있습니다. 초점은 불필요한 기능이 아닌 기능성에 남아 있습니다.

사용자 접근 및 단순함

Tim은 앱을 사용하는 모든 사람이 게임 결과를 입력할 수 있다고 설명합니다. 애플리케이션 내부에서 접근 수준에는 차이가 없습니다. 이렇게 하면 계정, 비밀번호 및 보안 계층을 회피하여 개발이 간소화됩니다.

그는 앱이 실무에서 관리자 디바이스에 상주할 수 있으며, 다른 사용자는 이메일을 통해서만 상호작용할 것이라고 설명합니다.

이메일 알림 및 자동화

Tim은 이메일 기능이 중요하다고 강조합니다. 앱은 다가오는 게임과 라운드 결과에 대해 사용자를 자동으로 알림해야 합니다. 이는 개발자가 설계 초기에 이메일 통합 및 자동화를 이해해야 함을 의미합니다.

Tim은 이 요구 사항이 여러 번 나타난다면서 그 중요성을 강조합니다.

팀 및 그룹 사용자 지원

Tim은 앱이 개인뿐만 아니라 팀도 지원해야 한다고 설명합니다. 모든 팀 구성원이 동일하게 대우받고 동일한 이메일을 받습니다. 팀 또한 이름을 가져야 합니다.

이는 사용자가 그룹화되는 방식, 데이터가 구조화되는 방식, 이벤트가 알림을 발생시키는 방식에 영향을 미칩니다.

큰 그림 설계 정의

Tim은 그림의 비유를 사용하여 큰 그림 설계를 소개합니다. 이 단계가 세부 사항이 아닌 경계를 정의한다고 설명합니다. 18:48에, 그는 구조를 개요화합니다: Windows Forms 앱, 클래스 라이브러리, SQL 또는 텍스트 파일 데이터 저장소, 그리고 한 번에 하나의 활성 사용자.

이러한 경계는 개발자가 나중에 불필요한 결정으로 넘어가지 않도록 방지합니다.

개발자가 주목해야 할 주요 개념 식별

Tim은 개발자가 연구할 필요가 있을 주요 개념을 식별해야 한다고 설명합니다. 이메일, SQL, 사용자 정의 이벤트, 오류 처리, 인터페이스, 무작위 순서를 나열합니다.

사용자 정의 이벤트가 라운드 완료를 감지하고 이메일과 같은 기능을 발생시키는 데 사용될 수 있는 방법을 설명합니다.

요구 사항을 해치지 않는 추가 아이디어

Tim은 문자 메시지를 가능한 미래의 개선 사항으로 소개합니다. 추가 기능은 핵심 요구 사항을 변경하거나 전달을 지연시키지 않는 경우에만 수용 가능하다고 설명합니다.

이는 개요 계획에서 정의된 규칙을 존중하는 것의 중요성을 강화합니다.

요약 및 다음 단계

Tim은 그의 비디오를 요약하며 결론을 내립니다: 이해 관계자의 질문이 요구사항으로 이어지고, 요구사항은 개요 설계로 이어지며, 개요 설계는 주요 개념을 드러냅니다. 그는 다음 수업이 데이터 설계에 초점을 맞추고, 정보가 어떻게 맞물리는지 도식화할 것이라고 설명합니다.

이 수업은 신중한 개요 계획이 개발자가 코드 한 줄도 작성하기 전에 구조적이며 유연하고 유지 관리가 가능한 앱을 만드는 데 어떻게 도움이 되는지를 보여줍니다.