Tim Corey의 레슨 01에서 적절한 앱 계획: 통찰력

레슨의 맥락과 목표 설정

비디오의 가장 시작에서 팀 코리는 첫 번째 레슨을 소개하고 이 레슨이 초기 계획에 관한 것이라고 설명합니다. 그는 명확하게 목표가 시나리오를 정의하고 개발이 시작되기 전에 애플리케이션이 무엇을 해야 하는지를 이해하는 것이라고 설명합니다.

팀은 이 레슨이 기초적인 것이라고 설명합니다. 이것은 프로젝트에서 이어지는 모든 것의 무대 설정을 합니다. 코딩에 뛰어들기보다는, 그는 시청자들이 작업을 구성하고, 복잡성을 관리하며, 올바르게 계획하여 집중할 수 있도록 하길 원합니다.

계획 전에 시나리오 이해하기

0:53에서, 팀은 전체 프로젝트를 이끌 시나리오를 소개합니다. 친구가 토너먼트 추적기를 요청합니다 - 게임을 관리하고, 매치를 결정하며, 싱글 엘리미네이션 브래킷에서 승자를 추적할 수 있는 애플리케이션.

팀은 이 시나리오가 NCAA March Madness 토너먼트와 유사하다고 설명합니다. 시스템은 자동으로 플레이어에게 그들이 누구와 플레이하는지를 알려주고, 결과를 추적하며, 결국에는 승자를 식별해야 합니다.

그는 이 설명만으로 애플리케이션을 구축하기에는 충분하지 않지만 시작 계획을 세우기에는 충분하다고 강조합니다. 이것은 많은 개발자들이 짧은 설명을 기반으로 모든 것을 이해했다고 가정하는 실수를 합니다.

왜 요구 사항이 코딩보다 앞서는가

1:33에서, 팀은 어떤 앱을 계획하는 첫 번째 실제 단계가 요구 사항을 정의하는 것이라고 설명합니다. 그는 일반적인 초보자 실수인 앱 아이디어가 명확해 보인다고 해서 코딩을 시작하는 것에 대해 경고합니다.

팀은 앱이 간단해 보이더라도 계획 없이 코딩에 뛰어들면 나중에 버그, 재작업 및 혼란을 초래한다고 설명합니다. 그는 강력한 기초가 개발을 더 쉽고 효율적으로 만들기 때문에 코딩을 여러 레슨 동안 의도적으로 지연시킨다고 말합니다.

이 접근 방식은 좋은 프로젝트 관리가 작동하는 방식과 유사합니다 - 실행 전에 작업을 명확히 정의하여 작업이 관리 가능하고 조직됩니다.

앱을 초기 작업 및 책임으로 나누기

2:06에서 팀은 이미 알고 있는 것을 나열하기 시작합니다. 그는 시스템이 해야 할 일을 설명합니다:

• 플레이된 게임을 추적합니다

• 각 게임에서 누가 이겼는지 추적합니다

• 누가 다음 라운드로 진출하는지를 결정합니다

그는 네 명의 플레이어 예를 사용하여 승자들이 앞으로 나아가는 방법을 설명합니다. 이것은 애플리케이션이 내부 작업과 논리를 관리해야 하는 방법을 명확히 하는 데 도움이 됩니다.

팀은 그런 다음 알려진 요구 사항을 추가합니다:

• 여러 경쟁자를 지원합니다

• 토너먼트 계획을 만듭니다

• 게임을 일정에 맞춥니다

• 손실 후 플레이어를 제거합니다

• 최종 승자를 식별합니다

이것들은 애플리케이션의 기본 작업 관리 형성합니다. 팀은 이 목록이 짧더라도 시스템이 책임져야 할 내용을 명확하게 하는 데 도움이 된다고 설명합니다.

왜 질문을 하는 것이 핵심 계획 기술인가

3:32에서 팀은 모든 프로젝트에 숨겨진 요구 사항이 있다고 설명합니다. 이해 관계자가 어렵게 행동하는 것은 아닙니다 - 단순히 기술 용어로 생각하지 않기 때문입니다.

팀은 계획의 일부가 다음을 밝혀내기 위해 질문하는 것이라고 설명합니다:

• 가장 중요한 것은 무엇인가

• 중요하지 않은 것은 무엇인가

• 피해야 할 가정은 무엇인가

이것이 계획이 코드보다 작업 조직, 명확성 및 의사 소통에 관한 것이 되는 지점입니다.

플레이어 수 및 토너먼트 크기 처리

4:15에서 팀은 토너먼트가 몇 명의 선수를 처리해야 하는지를 묻습니다. 그는 이 구조가 시스템의 전체 구조에 영향을 미친다고 설명합니다.

그는 고정 vs 가변 플레이어 수를 논의하고 2의 거듭제곱이 아닌 숫자가 복잡성을 어떻게 초래하는지를 설명합니다. 이는 어떤 시스템에서든 잘못된 계획이 일정과 워크플로우를 깨트릴 수 있는 것과 유사합니다.

4:51에서, 팀은 플레이어가 충분하지 않은 상황을 어떻게 처리해야 하는지를 논의합니다. 그는 부전을 도입하고, 시스템이 이를 지원하거나 명시적으로 방지해야 한다고 설명합니다.

매치 순서 지정 및 작업 일정

6:13에서 팀은 매치업이 무작위로 지정되어야 하는지 또는 정렬되어야 하는지를 논의합니다. 그는 이 결정이 앱이 내부적으로 작업을 생성하고 일정을 잡는 방법에 영향을 미친다고 설명합니다.

그 후 게임 일정을 짜는 두 가지 가능한 접근 방식을 설명합니다:

• 플레이어는 원하는 시간에 플레이합니다

• 특정 시간에 게임이 일정됩니다

팀은 이 결정이 시스템이 시간, 진행 상황 및 흐름을 관리하는 방법에 영향을 미치는 것을 설명합니다 - 이는 기획 앱이 일상 일정을 관리하고 시간 차단을 처리해야 하는 방법과 유사합니다.

진행 상황 및 게임 흐름 제어

7:26에서, 팀은 후반 라운드 게임이 이전 라운드가 완료되기 전에 진행될 수 있는지 여부를 묻습니다. 그는 이를 허용하면 유연성이 생기지만 복잡성도 증가한다고 설명합니다.

이 논의는 규칙이 시스템 행동에 어떻게 영향을 미치는지를 강조합니다. 팀은 이러한 규칙이 처음에 결정되어야만 응용 프로그램이 작업을 올바르게 관리하고 잘못된 작업을 방지할 수 있다고 강조합니다.

결과 및 작업 세부사항 저장

8:22에서 팀은 시스템이 단순히 승자를 저장해야 하는지 또는 점수도 저장해야 하는지를 묻습니다. 그는 더 많은 세부사항을 저장하면 가치를 더하지만 복잡성도 증가한다고 설명합니다.

이는 시스템이 추적해야 할 정보를 너무 많이 감당하지 않도록 미리 결정해야 한다는 계획상의 원칙을 반영합니다.

인터페이스에 대한 가정 피하기

8:54에서 팀은 또 다른 초보자 실수인 프론트 엔드 유형을 가정하는 것에 대해 경고합니다.

그는 묻지 않으면:

• 데스크탑 앱인가?

• 웹사이트?

• 모바일 앱?

개발자는 추측해야 한다고 설명합니다. 팀은 추측은 재작업으로 이어진다고 강조합니다. 계획은 이를 방지합니다.

데이터 저장소, 돈, 및 보고

9:37에서 팀은 데이터 저장소를 소개합니다. 그는 데이터가 어디에 존재하는지를 묻는 것이 이해 관계자와 중요한 대화를 촉발한다고 설명합니다.

나중에 그는 다음을 논의합니다:

• 참가비

• 상금

• 지급

• 결과 보고

이러한 기능은 즉시 필요하지 않을 수도 있지만 팀은 계획이 프로젝트의 장기 방향을 정의하는 데 도움이 된다고 설명합니다.

접근 레벨, 알림 및 팀

12:11에서 팀은 누가 결과를 입력할 수 있는지 및 다른 접근 레벨이 있는지를 논의합니다. 이는 누가 어떤 작업을 수행할 수 있는지를 통제하는 것입니다.

12:51에서, 그는 시스템이 다가오는 게임에 대한 사용자 알림을 제공해야 하는지를 묻고, 이 질문이 종종 미래의 기능 아이디어를 드러낸다고 설명합니다.

13:42에서 팀은 경쟁자가 개인인지 팀인지 묻습니다. 그는 이것이 시스템에서 참가자들이 어떻게 표현되는지에 영향을 미친다고 설명합니다.

팀의 최종 계획 조언

15:20에서 팀은 중요한 알림으로 마무리합니다: 완벽할 필요는 없습니다. 그러나 가능한 한 많은 정보를 사전에 수집해야 합니다.

그는 좋은 계획이 개발자들이 조직을 유지하고 복잡성을 관리하며 자신 있게 앞으로 나아갈 수 있도록 도와준다고 설명합니다. 목표는 명확성입니다 - 완벽함이 아닙니다.

팀은 이러한 질문에 대한 답변이 애플리케이션의 전체 방향을 안내할 레슨 2를 예고하며 끝맺습니다.

마무리 생각

레슨 01에서 팀 코리는 앱을 계획하는 것이 코드를 작성하기 전에 작업, 구조 및 흐름을 이해하는 것이라고 보여줍니다. 요구 사항을 정의하고 신중한 질문을 통해 개발자는 효율적인 개발, 더 적은 버그 및 더 나은 결과를 얻을 수 있는 준비를 합니다. 이 레슨은 모든 성공적인 애플리케이션에 적용되는 사고방식을 확립합니다: 먼저 계획하고, 그 다음에 구축합니다.