規劃應用程式的正確方式：來自 Tim Corey 第一課的見解

計劃應用程式不是關於選擇工具或編寫程式碼，而是關於在開始建構之前明確理解問題。 在"C# App Start to Finish"第01課中，Tim Corey完全專注於初步計劃，解釋為什麼這個階段決定了應用程式的成功與否。

在這節課中，Tim不討論語法、框架或高級功能。 相反地，他展示了如何智能地計劃應用程式、識別需求、將工作分解為邏輯任務，以及事先提出正確的問題。 本文深入探討了Tim Corey的課程，緊隨他的解釋，並運用他自己的流程和影片中的推理進行拓展。

設置課程的上下文和目標

在影片一開始，Tim Corey 介紹了第 一節課，並解釋這節課是關於初步計劃的。 他明確表示，目標是定義場景並在開始開發之前了解應用程式需要做什麼。

Tim 說明這節課是基礎課程。 它是專案中所有後續內容的基礎。 與其直接進入編碼，他希望觀眾了解如何通過正確的計劃來組織工作、管理複雜性以及保持專注。

在計劃前了解場景

在 0:53，Tim介紹了將推動整個專案的場景。 朋友要求開發一個比賽追蹤器——一個能管理比賽、決定對陣，以及追蹤單淘汰賽程中勝者的應用程式。

Tim解釋這個場景類似於NCAA三月瘋狂比賽。 系統應自動告訴玩家他們的對手，追蹤結果，最後確認勝者。

他強調僅憑這個描述是不足以建構一個應用程式的，但足以開始計劃。 這是許多開發者犯錯之處——以為根據簡短的描述就能理解一切。

為什麼需求應該在編碼之前

在1:33，Tim解釋了任何應用程式計劃的第一個真正步驟是定義需求。 他警告一個常見的新手錯誤：僅因為應用程式想法顯而易見就開始編碼。

Tim解釋即使該應用程式聽起來簡單，不計劃直接開始編碼會導致後期出現問題、重做和混亂。 他有意拖延幾節課的編碼，因為堅實的基礎使開發更容易且更高效。

這種方式反映了良好的專案管理——在執行之前清楚地定義工作，以便使任務易於管理和組織。

將應用程式分解為初始任務和職責

在 2:06，Tim 開始列出已知的內容。 他解釋系統必須：

＊ 追踪已進行的比賽

＊ 追踪每場比賽的勝者

＊ 確定誰晉級下一輪

他使用四名選手的例子並解釋了如何讓勝者晉級。 這有助於澄清應用程式如何管理其內部任務和邏輯。

Tim 然後增加了更多已知需求：

＊ 支持多個競爭者

＊ 建立比賽計劃

＊ 排定比賽

＊ 在失敗後淘汰玩家

＊ 確認最終勝者

這些要點構成了應用程式的基本任務管理。 Tim 解釋即使清單很短，寫下來有助於澄清系統負責的內容。

詢問問題為核心計劃技能的原因

在 3:32，Tim 解釋每個專案都有隱藏需求。 利害關係人不是故意刁難——他們只是不以技術術語思考。

Tim解釋計劃的一部分是通過提問以揭示：

＊ 什麼是最重要的

＊ 什麼是不重要的

＊ 哪些假設應避免

在這個地方，計劃不再是關於程式碼，而更多是關於任務組織、清晰度和溝通上。

處理玩家數量和比賽規模

在 4:15，Tim 問比賽應該處理多少玩家。 他解釋這影響系統的整體結構。

他討論了固定與可變玩家數量，並解釋為什麼並非2的冪次方的數字會帶來複雜性。 這類似於任何系統中不良規劃會破壞排程和工作流程。

在 4:51，Tim 討論了如何處理玩家不足的情況。 他介紹了輪空的概念並解釋系統必須支持此功能或明確阻止之。

安排比賽和排程工作

在 6:13，Tim 討論應該隨機還是按序安排比賽對陣。 他解釋這個決定如何影響應用程式內部建立和排程任務。

他然後深入遊戲排程，說明了兩種可能的方法：

＊ 玩家可以隨時進行比賽

＊ 比賽安排在特定時間進行

Tim解釋這一決定如何影響系統管理時間、進度和流程——類似於計劃應用程式如何處理每日排程和時間塊分配。

控制進度和遊戲流程

在 7:26，Tim 問是否可以在前幾輪比賽完成前進行後幾輪比賽。 他解釋允許這樣做會提高靈活性，但也增加了複雜性。

這次討論強調了規則如何影響系統行為。 Tim 強調必須事先決定這些規則，讓應用程式能正確管理任務並防止無效操作。

儲存結果和任務詳細資訊

在 8:22，Tim 問系統應該儲存勝者還是也儲存比分。 他解釋儲存更多詳細資訊增加價值但也會增加複雜性。

這反映了更廣泛的規劃原則：早期決定系統需要追踪多少資訊以避免不必要的過載。

避免對介面的假設

在 8:54，Tim 警告另一個新手錯誤：假設前端的型別。

他解釋如果不詢問：

＊ 它是一個桌面應用嗎？

＊ 一個網站嗎？

＊ 一個移動應用嗎？

開發者們不得不猜測。 Tim 强調猜測會導致重做。 計劃避免這個問題。

資料儲存、金錢及報告

在 9:37，Tim 提出了資料儲存。 他解釋詢問資料存放位置引發了與利害關係人的重要對話。

稍後，他討論了：

＊ 參賽費用

＊ 獎品

＊ 支付

＊ 報告結果

這些功能可能不是立即必需的，但Tim解釋計劃這些有助於塑造專案的長期方向。

存取級別、通知和團隊

在 12:11，Tim 討論誰可以輸入結果以及是否有不同的存取級別。 這關於控制誰可以執行哪些任務。

在 12:51，他問系統是否應通知使用者即將到來的比賽，說明這個問題通常揭示未來的功能想法。

在 13:42，Tim 問參賽者是個人還是團隊。 他解釋這影響了系統中參與者的表示方式。

Tim 的最終規劃建議

在 15:20，Tim 用一個重要的提醒結束：您不需要做到完美。 不過，您應盡可能多地收集資訊。

他解釋良好的規劃幫助開發者保持組織，管理複雜性，並自信地向前推進。 目標是清晰——不是完美。

Tim以介紹二節課的簡介結束，這些問題的答案將引導應用程式的總體方向。

結語

在第01課中，Tim Corey展示計劃應用程式是在編寫程式碼之前了解任務、結構和流程。 透過定義需求和提出深思熟慮的問題，開發者能為高效的開發、更少的漏洞和更好的結果做好準備。 這節課建立了一種思維方式，適用於所有成功的應用程式：先計劃，再建構。