アプリを正しい方法で計画する：Tim Corey のレッスン 01 のインサイト

アプリケーションの計画は、ツールを選択することやコードを書くことではありません、それは何かを構築する前に問題を明確に理解することです。 "C# App Start to Finish"のレッスン01では、Tim Coreyが初期計画に全体的に焦点を当て、このフェーズがアプリケーションが成功するか、後で苦労するかを決定する理由を説明します。

このレッスンでTimは、構文、フレームワーク、または高度な機能についての議論はしません。 代わりに、アプリケーションを賢く計画し、要件を識別し、作業を論理的なタスクに分解し、最初に正しい質問を行う方法を説明します。 この記事は、Tim Coreyのレッスンに対する深い洞察を提供し、彼の説明を注意深く追い、ビデオからの流れと論理を使ってそれらを拡展します。

レッスンのコンテキストと目標の設定

ビデオの最初に、Tim Coreyはレッスン1を紹介し、このレッスンが最初の計画についてであると説明します。 彼は、アプリケーションのシナリオを定義することと、開発を始める前にそれが何をする必要があるかを理解し始めることが目標であることを明確に述べます。

Timは、このレッスンは基礎的であると説明します。 それはプロジェクトに続くすべてのことのための準備を設定します。 コーディングに飛び込むのではなく、彼は視聴者が作業を整理し、複雑さを管理し、正しく計画することによって集中を維持する方法を理解することを望んでいます。

計画の前にシナリオを理解する

0:53で、Timはプロジェクト全体を駆動するシナリオを紹介します。 友人がトーナメントトラッカー - ゲームを管理し、対戦を決定し、単一排除ブラケットで勝者を追跡できるアプリケーションを求めます。

Timは、このシナリオがNCAAのMarch Madnessトーナメントに似ていると説明します。 システムは自動的にプレイヤーに対戦相手を知らせ、結果を追跡し、最終的に勝者を識別すべきです。

彼は、単独でのこの説明はアプリケーションを構築するには不十分であるが、計画を始めるには十分であると強調します。 多くの開発者がこの短い説明に基づいてすべてを理解していると仮定して間違いを犯してしまう場所です。

なぜ要件がコーディングの前に来るのか

1:33で、Timはどのアプリを計画する際の最初の実際のステップが要件を定義することであると説明します。 彼は一般的な新人の間違いに警鐘を鳴らします: アプリケーションのアイデアが明白であると見ているからただコーディングを始めること。

Timは、アプリが単純に聞こえるかもしれないが、計画なしでコーディングに飛び込むことはバグ、やり直し、そして後の混乱を招くと説明します。 彼は意図的にいくつかのレッスンをコーディングを遅らせます、なぜなら強固な基盤が開発をより簡単かつ効率的にするからです。

このアプローチは、優れたプロジェクト管理がどのように機能するかを反映しています - 作業を実行する前に明確に定義し、タスクを管理し、組織化するためにします。

アプリを最初のタスクと責任に分解する

2:06で、Timは既に知られていることをリストし始めます。 彼はシステムが以下のことをしなければならないと説明します:

• プレイされたゲームを追跡する

• 各ゲームの勝者を追跡する

• 次のラウンドに進む人を決定する

彼は4人のプレイヤーの例を使い、勝者がどのように進むかを説明します。 これがアプリケーションが内部タスクとロジックをどう管理するかの明確化に役立ちます。

Timはさらに既知の要件を追加します:

• 複数の競技者をサポートする

• トーナメントプランを作成する

• ゲームをスケジュールする

・負けた後、プレイヤーを排除する

・最終勝者を識別する

これらのポイントは、アプリケーションの基本的なタスク管理を形成します。 ティムは、リストが短くても書き留めることで、システムが何に責任を持つかが明確になると説明します。

なぜ質問することが重要な計画スキルなのか

3:32で、ティムはプロジェクトには隠れた要件があると説明します。 利害関係者は難しいわけではなく、単に技術的な用語で考えていないのです。

ティムは、計画の一部として次のことを明らかにするために質問することが含まれると説明します：

・何が最も重要か

・何が重要でないか

・どの仮定を避けるべきか

ここでは、計画がコードのことよりもタスクの整理、明確化、およびコミュニケーションに関するものとなります。

プレイヤー数とトーナメントサイズの処理

4:15で、ティムはトーナメントが何人のプレイヤーを処理する必要があるかを尋ねます。 彼はこれがシステム全体の構造に影響を与えると説明します。

彼は固定対変動プレイヤー数を議論し、2の累乗でない数字がなぜ複雑さを生むのかを説明します。 これは、どのシステムでも不十分な計画がスケジュールとワークフローを破壊する方法と似ています。

4:51で、ティムはプレイヤーが足りない場合の対処方法について説明します。 彼は、"不戦勝"のアイデアを紹介し、システムがこれをサポートするか、明示的に防ぐ必要があると説明します。

試合の順序設定とスケジュールの作成

6:13で、ティムは試合をランダムにするべきか、順序設定するべきかを議論します。 彼は、この決定がアプリが内部でタスクを作成しスケジュールする方法に影響を与えると説明します。

その後、ゲームスケジュールに移り、2つの可能なアプローチを説明します：

・プレイヤーが好きなときにプレイする

・特定の時間にゲームがスケジュールされる

ティムは、この決定がシステムが時間、進行、フローを管理する方法に影響を与えると説明し、プランナーアプリが日次スケジュールと時間ブロックを処理する必要があるのと同様です。

進行とゲームフローの制御

7:26で、ティムは後のラウンドゲームが以前のラウンドが完了する前にプレイできるかどうかを尋ねます。 彼はこれを許可することで柔軟性が生まれるが、複雑さも生じると説明します。

この議論は、ルールがシステムの動作に影響を与える方法を強調しています。 ティムは、これらのルールを事前に決定する必要があることを強調し、アプリケーションが正確にタスクを管理し、無効なアクションを防ぐことができるようにします。

結果とタスクの詳細の保存

8:22で、ティムはシステムが勝者のみを保存するか、スコアも保存するかを尋ねます。 彼は、より多くの詳細を保存することで価値が追加されるが、複雑さも増すと説明します。

これは、システムが追跡する情報の量を早期に決定し、不要にオーバーロードされないようにするという広いプランニングの原則を反映しています。

インターフェースに関する仮定を避ける

8:54で、ティムは別の初歩的な間違いである、フロントエンドの種類を想定することに対して警告します。

彼は、尋ねることなしに：

・デスクトップアプリか？

・ウェブサイトか？

・モバイルアプリか？

開発者は推測せざるを得ません。 ティムは、推測が手直しにつながることを強調します。 計画はこれを避けます。

データ保存、資金、および報告

9:37で、ティムはデータ保存を紹介します。 彼はデータがどこにあるかを尋ねることで利害関係者と重要な会話が始まると説明します。

後で彼は次のことを議論します：

・参加費

・賞品

・支払い

・結果の報告

これらの機能はすぐに必要ではないかもしれませんが、ティムは、それらの計画をすることでプロジェクトの長期的な方向性が形作られると説明します。

アクセスレベル、通知、チーム

12:11で、ティムは誰が結果を入力できるか、およびアクセスレベルが異なるかどうかを議論します。 これは、誰がどのタスクを実行できるかを制御することに関するものです。

12:51で、彼はシステムがユーザーに今後のゲームについて通知するべきかを尋ね、それがしばしば将来の機能のアイデアを明らかにすることを説明します。

13:42で、ティムは競争者が個人かチームかを尋ねます。 彼はこれがシステム内で参加者がどのように表現されるかに影響すると説明します。

ティムの最終計画アドバイス

15:20で、ティムは重要なリマインダーで締めくくります：完璧である必要はありません。 ただし、できるだけ多くの情報を事前に集めるべきです。

彼は、良い計画が開発者が整理され、複雑さを管理し、自信を持って前進するのに役立つと説明します。 目標は明確さであり、完璧ではありません。

ティムは、これらの質問への回答がアプリケーションの全体的な方向性を導くレッスン2を紹介することで終えます。

締めくくりの考え

レッスン01において、ティム・コーリーは、アプリの計画はコードを書く前にタスクの理解、構造、およびフローに関することであると示しています。 要件を定義し、思慮深い質問をすることで、開発者は効率的な開発、バグの少なさ、より良い結果を伴う準備を整えます。 このレッスンは、すべての成功したアプリケーションに適用されるマインドセットを確立します：まず計画し、それから構築する。