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在視頻中總結了整個過程：利害關係人的問題引 lead to requirements, requirements lead to overview design, and overview design reveals key concepts. 他解釋說，下一課將專注於數據設計，繪製信息如何互相契合。

這一課展示了透過謹慎的概覽規劃如何幫助開發者創建結構化、靈活且可維護的應用程式——還未寫出一行程式碼。