C# 應用程式概覽規劃：學習大局觀與 Tim Corey

總覽規劃介紹

在影片開始時，Tim Corey介紹了第02課並解釋該課程聚焦在總覽規劃，也就是應用的大圖景。 Tim解釋這一步驟是在深入細節之前奠定應用的基礎。 他強調雖然這一課程可能比其他課程感覺更簡單，但它在建立可管理、可擴展和可維護的應用中扮演了關鍵角色。

Tim解釋總覽規劃不是關於功能或撰寫程式碼。 而是要了解應用將如何整體運作，使用者將如何與其互動，以及開發者應如何著手構建。

復習利益相關者問題

Tim解釋在繼續之前，他必須重溫上一課中提出的15個問題。 這些問題旨在從利益相關者—要求應用的人—收集更多資訊。Tim模擬真實世界情景，開發者向利益相關者回溯，提問以澄清問題，並收集更詳細的答案。

他指出這一過程反映了真實的商業環境。 開發者常常需要問多個問題並且細化需求，因為使用者不總是知道如何用技術術語描述他們的需求。

可變的玩家與比賽規模

Tim開始回顧答案並解釋應用必須支持可變數量的玩家。 比賽追蹤器不應限制於固定數量。 無論是兩名還是更多名玩家，應用都必須能夠處理。

這一要求直接影響應用的功能、資料結構和邏輯。 Tim解釋開發者不能硬編碼關於玩家數量的假設。 相反的，應用必須能根據參與者的數量動態管理使用者和遊戲。

處理不完美比賽中的輪空

Tim解釋比賽並不總是擁有理想的玩家數量。 當總數不能均分時，應用必須分配輪空。 在這一點，Tim強調一個重要規則：輪空必須隨機分配。

這引入了應用不斷需要處理的技術要求之一——隨機化。 應用必須公正地管理使用者，隨機選擇誰將晉級而不需比賽。 這一要求形成了關於工具、邏輯以及應用內事件後續決定。

玩家的隨機排序

Tim繼續解釋誰對誰比賽的順序也應隨機化。 應用不應依賴使用者被輸入的順序。 當所有玩家新增完成後，應用隨機化名單。

這確保公平並避免偏見。 Tim明確指出隨機化是一條規則，而非可選功能。 它成為應用的核心規則之一，必須在開發過程中被尊重。

靈活的比賽排程

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通過總結過程來結束他的影片：利害關係者的問題導致需求，而需求導致總覽設計，總覽設計揭示關鍵概念。他解釋下一課將聚焦於資料設計，繪製出資訊的結構。

該課程顯示謹慎的總覽規劃如何幫助開發者建立結構化，靈活且可維護的應用程式—即便在撰寫一行程式碼之前。