C#应用程序总览规划：与Tim Corey一起学习大图景

当开发人员创建应用程序时，最大成本的错误通常发生在编写任何代码之前。 在《C#从开始到完成：比赛跟踪器》的第二课中，Tim Corey专注于应用程序概述规划——了解应用程序应该做什么，谁将使用它，它将如何运行以及它必须在什么边界内操作。 这节课不涉及编写代码。 Tim相反地讲解了专业开发人员在开发开始前如何退一步设计应用程序的结构、功能和策略。

在这篇文章中，我们通过紧密跟随Tim Corey的视频更深入地探讨了应用程序概述规划。 Tim解释了如何将真实人物（利益相关者）的回答转变为应用程序规则、结构和关键开发决策。 这个概述成为了在未来课程中一致构建相同应用程序的基础。

概述规划介绍

在视频开始时，Tim Corey介绍了第二课并解释说重点是概述规划，也被称为应用程序的大局观。 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解释说集成必须具备灵活性，以便同一应用程序可以从不同来源存储和检索数据而不破坏功能。

参赛费用、奖品和现实世界的模糊性

蒂姆解释说，利益相关者通常提供含糊不清的答案。 起初，对应用程序是否处理入场费和奖品的问题，答案只是简单的"是"。蒂姆解释说，开发者必须深入了解这意味着什么。

然后，他概述了明确的要求：锦标赛可以收取入场费，奖励给多个名次，并确保支付永远不会超过收入。 他还解释了基于百分比的支付和筹款场景。

本节展示了如何通过应用程序概述规划帮助开发人员预见真实的业务规则，而不必过度复杂化应用程序。

报告和显示结果

蒂姆解释说，报告应该简单明了。 应用程序需要显示每轮结果和最终结果，包括谁获胜以及他们赢得了多少。 报告可以以表单显示或通过电子邮件发送。

这避免了构建复杂的报告系统，同时仍然满足用户期望。 重点仍在功能性上，而不是不必要的特性。

用户访问和简化

蒂姆解释说，任何使用该应用程序的人都可以输入比赛结果。 应用程序内部没有不同级别的访问。 这样可以通过避免账户、密码和安全层简化开发。

他解释说，在实际应用中，该应用程序可能驻留在管理员设备上，而其他用户仅通过电子邮件进行互动。

电子邮件通知和自动化

蒂姆强调电子邮件功能的重要性。 应用程序必须自动通知用户有关即将举行的比赛和各轮结果。 这要求开发人员在设计过程的早期理解电子邮件集成和自动化。

蒂姆指出，这一要求多次出现，表明其重要性。

支持团队和群组用户

蒂姆解释说，该应用程序必须支持团队，而不仅仅是个人。 所有团队成员被同等对待并收到相同的电子邮件。 团队还必须有名称。

这会影响如何对用户进行分组、数据的结构化方式以及事件触发通知的方式。

定义大局设计

蒂姆通过绘画类比介绍了大局设计的理念。 他解释说，这个阶段定义了界限，而不是细节。 在18:48时，他概述了结构：一个Windows Forms应用程序、一个类库、SQL或文本文件数据存储，以及同时只有一个活动用户。

这些界限可防止开发者后来陷入不必要的决策。

辨识开发者的关键概念

蒂姆解释说，开发者应该识别他们可能需要研究的关键概念。 他列出了电子邮件、SQL、自定义事件、错误处理、接口和随机排序。

他解释了如何使用自定义事件来检测轮次完成并触发功能，例如电子邮件。

在不打破要求的条件下实现额外想法

蒂姆提出将短信作为未来可能的增强功能。 他解释说，只有在不改变核心要求或延迟交付的情况下，附加功能才是可接受的。

这强化了在概述计划中定义的规则的重要性。

总结和下一步

蒂姆通过总结流程结束他的视频：利益相关者的问题导致要求，要求导致概述设计，概述设计揭示关键概念。他解释说，下一个课程将聚焦于数据设计，绘制出信息如何组合在一起。

本课显示了如何通过细致入微的概述规划，帮助开发人员在编写任何代码之前创建结构化、灵活且易于维护的应用程序。