Windows Calculator 新功能开发全流程指南从 Feature Pitch 到合并主线【免费下载链接】calculatorWindows Calculator: A simple yet powerful calculator that ships with Windows项目地址: https://gitcode.com/gh_mirrors/cal/calculatorWindows Calculator 是随 Windows 预装的现代应用由 C 与 C# 混合编写持续通过 Microsoft Store 定期发布新版本。开源后社区不仅能够提交 bug 修复还可以参与新功能的完整生命周期。本文以仓库中的 docs/NewFeatureProcess.md 为骨架系统讲解新功能从想法提出、规划评审、代码实现到最终合入 master 分支的四阶段流程并结合本仓库的源码、测试与配置文件说明每个环节的实操要点与可验证依据。读完本文你将掌握用户可见改动的提交流程、Feature Pitch 的撰写要点以及微软团队在技术评审中逐项检查的完整清单。一、想法从哪里提交Feedback Hub 与 GitHub 双通道新功能想法有两个提交入口两者并行不悖Feedback Hub任何 Windows 用户即使不是 GitHub 用户都可以在 Feedback Hub 中提交建议并为已有建议投票计算器团队会定期review这些建议当决定投入开发时会以feature pitch的形式在 GitHub 上创建 issue。这也是 CONTRIBUTING.md 推荐的反馈路径——Feedback Hub 报告会自动附带计算器版本等诊断数据便于团队复现与定位。GitHub Feature Pitch使用 Feedback Hub 并不是必须的任何人都可以直接在 GitHub 上提交 feature pitch issue。仓库中的 CONTRIBUTING.md 明确要求除非 PR 关联了标记为triage approved的 issue否则不要提交 PR其目的就是在实现投入前先就想法达成共识。团队通过 Feature Tracking board项目看板跟踪所有正在开发的功能及其所处阶段同时用 docs/Roadmap.md 上的路线图2021 年重点包括基于 Fluent Design 与 WinUI 迭代设计、向 C# 迁移代码库、将无限精度引擎发布为独立包、添加设置页面等来裁决 pitch 是否与产品方向一致。二、哪些改动必须走此流程流程不是对所有改动一视同仁其分界线是用户是否会注意到不需要走流程bug 修复、性能改进、开发工具改动。这类贡献只需先在 issue 中讨论拟议变更然后直接提交 pull request 即可。必须走流程任何用户会注意到的改动尤其是新功能和重大视觉变化。这条分界线背后有明确的工程理由bug 修复与性能改进的边界清晰、风险局部可控可以走轻量路径而新功能会引入新的交互方式、新的资源字符串、新的本地化条目甚至影响启动路径与依赖清单必须经过规划与专项评审。从仓库结构看一次完整的新功能往往横跨多个工程CalcManager计算引擎、CalcViewModel视图模型与状态管理、CalculatorXAML 界面与资源、GraphControl/GraphingImpl图形渲染因此提前对齐设计与影响面尤为关键。三、Step 1Feature Pitch——写好一份提案Feature Pitch 以 GitHub issue 的形式提交使用仓库预置的 Feature Request 模板。团队鼓励在开放的 issue 上讨论讨论过程中会不断编辑 issue 描述来收敛想法直到其可进入评审。评审的标准是看 pitch 是否与 docs/Roadmap.md 上列出的产品方向广泛对齐。被批准的 pitch 会被移入 Feature Tracking board 的 planning规划列。这里有几个提升通过率的实践要点在提交前先到 Feedback Hub 检查是否已有相似建议并点赞汇聚社区声量明确描述用户场景与预期行为而不是直接指定技术实现方案说明该功能与现有功能标准、科学、程序员、日期计算、单位/货币换算、历史与内存之间的关系避免重叠或冲突。四、Step 2Planning——从想法到规格说明规划阶段的核心产物是规格说明specification它描述功能将如何工作必要时辅以设计渲染图与代码原型。原 issue 继续跟踪功能的整体进度而规格文档在 Calculator Spec 仓库中创建并迭代。规划过程中团队可能对提案有新的认知届时会编辑或关闭原始 pitch。社区在整个规划阶段都欢迎参与——团队明确表示最好的想法往往来自尝试许多想法因此鼓励在把设计做到像素级完美、把代码做到健壮可维护之前先用粗糙的草图甚至纸笔快速实验。这一理念在本仓库的工程实践中也有体现例如图形计算器功能的引擎在开发者构建中使用 src/GraphingImpl/Mocks 的 mock 实现基于 src/GraphingInterfaces 的公共 API让社区可以在不依赖微软专有引擎的前提下先打磨 UI 与交互。当 spec review 完成后issue 会被移入 implementation实现列。某些情况下一个想法能完整、简洁地记录在原始 pitch 中此时可以直接跳过规格阶段进入实现。五、Step 3Implementation——实现与专项技术评审功能可由原始提交者、微软团队成员或其他社区成员实现代码贡献与测试帮助都受到欢迎。实现前请在 issue 中告知大家你正在积极开发以避免重复劳动。原型阶段的代码可能被复用但通常需要额外工作使其健壮、可维护。代码就绪后即可开始提交 pull request具体流程参见 CONTRIBUTING.md。与 bug 修复一样新功能代码在合入 master 之前必须经过微软团队成员评审但新功能需要比 bug 修复更彻底的技术评审。评审中至少逐项检查以下内容完整清单并结合本仓库给出对应的证据与落地方式5.1 可访问性与全球化处理Accessibility checklist可访问性检查清单的全部项目。仓库中的实证src/CalcViewModel/Common/Automation 目录提供了 NarratorAnnouncement讲述人播报、LiveRegionHost 等辅助功能基础设施src/Calculator/Controls/CalculationResultAutomationPeer.cs 与 src/Calculator/Controls/OverflowTextBlockAutomationPeer.cs 为结果展示控件实现自动化对等体。处理Globalization checklist全球化检查清单的全部项目。仓库中的实证src/Calculator/Resources 下按语言分目录维护了 60 余个区域的CEngineStrings.resw与Resources.resw任何新增 UI 字符串都需要同步到这些资源文件src/CalcViewModel/Common/LocalizationService.cpp 负责本地化解析与数字格式如小数点、千分位、RTL 布局处理。5.2 版本兼容与 API 使用在应用支持的最老版本 Windows上测试。最低版本号位于 AppxManifest.xml 中本仓库的 src/Calculator/Package.appxmanifest 声明TargetDeviceFamily NameWindows.Universal MinVersion10.0.19041.0即 Windows 10 2004任何高于该版本的 API 调用都应条件启用version-adaptive 模式发布版清单 src/Calculator/Package.Release.appxmanifest 同样如此。仅使用受支持的 API。若对旧版或未文档化 API 的使用存疑应运行Windows App Certification KitWindows 应用认证工具包进行校验。应用被**挂起suspend与恢复resume**时应保存用户进度相关代码需在 Visual Studio 调试器中测试这些生命周期事件。仓库中的实证src/Calculator/Common/AppLifecycleLogger.cs 记录生命周期事件主题等用户偏好通过ApplicationData.Current.LocalSettings持久化见 src/Calculator/Utils/ThemeHelper.cssrc/CalcViewModel/Snapshots.cpp 负责状态快照。若改动针对特定设备家族做了定制appxmanifest 中可见desktop4:、iot2:等命名空间扩展例如SupportsMultipleInstances属性需要在对应设备家族上测试。5.3 主题、窗口与依赖在最小窗口尺寸下测试应用窗口缩放。在浅色、深色与高对比度主题下测试并遵循用户偏好的强调色accent color。src/Calculator/Utils/ThemeHelper.cs 展示了主题的读取与持久化实现SelectedAppTheme存入 LocalSettings。若新增库或其他依赖随应用打包的库应测量二进制体积增大的幅度非微软维护的库团队需制定计划监控上游库的变更如安全修复按开源许可证使用的库必须遵守许可证并适当致谢第三方。仓库现有依赖管理可见 nuget.config 与 src/Directory.Build.props。5.4 启动路径、日志与数据若改动增加启动路径上运行的代码或新增启动时加载的 XAML 元素需运行性能测试测量启动时间增量并尽可能将工作移出启动路径。应用启动与页面加载逻辑可参见 src/Calculator/App.xaml.cs 与 src/Calculator/Views/MainPage.xaml.cs。若增加日志所有日志应使用TraceLogging。仓库中的实现见 src/TraceLogging/TraceLoggingCommon.cpp它创建名为MicrosoftCalculator的 LoggingChannelprovider GUID0905CA09-610E-401E-B650-2F212980B9E0并按SEND_DIAGNOSTICS编译宏控制关键字位——未定义该宏时MICROSOFT_KEYWORD_LEVEL_*全部置 0从源头关闭诊断上传不必要的日志事件应移除或配置为仅在排查问题、度量功能使用率时收集。GetTraceLoggingProviderEnabled()的提前短路判断见 src/TraceLogging/TraceLoggingCommon.cpp 与 src/Calculator/Common/AppLifecycleLogger.cs正是为了在 provider 未启用时零开销跳过。若改动读取文件或应用设置中的用户数据验证旧版本应用保存的状态可被新版本使用状态向前兼容。若改动发起网络请求微软必须规划在应用生命周期内可能长达数年保持这些依赖安全可用在部分网络请求缓慢或失败时应用应完全可用。仓库中的相关实现包括 src/CalcViewModel/DataLoaders/CurrencyHttpClient.cpp货币汇率获取与 src/CalcViewModel/Common/NetworkManager.cpp可用 Fiddler 等工具模拟慢速或失败请求进行测试。开发者构建中汇率数据使用行星命名的 mock 数据见 src/CalcViewModel/DataLoaders/DefaultFromToCurrency.json不会因网络不可用而崩溃。5.5 评审之外的配套要求CONTRIBUTING.md 补充了新功能评审外的配套要求与上述清单共同构成合入门槛代码风格需尽量贴近周边代码本项目混合了老代码与 C/WinRT 新组件新组件优先遵循 C Core Guidelines 与 C/WinRT 语言投影模式尽可能附带单元测试与 UI 测试仓库中的测试工程包括 src/CalculatorUnitTests/CalculatorUnitTests.vcxproj引擎与视图模型单元测试如 src/CalculatorUnitTests/RationalTest.cpp、src/CalculatorUnitTests/StandardViewModelUnitTests.cpp与 src/CalculatorUITests/CalculatorUITests.csproj基于 WinAppDriver 的 UI 自动化测试覆盖标准/科学/程序员模式、历史、内存、货币换算等场景自动化不可行处使用 docs/ManualTests.md 的手动测试用例遵循 GitHub flow开发直接在main分支上进行复杂改动需先整理分支历史如用 git rebase 压缩提交PR 合并时通常 squash 为单个提交提交 PR 前需签署微软开源项目 Contributor License AgreementCLA机器人会自动将 PR 分类为cla-not-required或cla-required。六、Step 4最终产品评审与合入主线技术评审完成后产品团队还会对成品进行最终评审确认最终实现已准备好发布给 Windows 用户发布节奏见 docs/Roadmap.md随 Windows 版本预装并约每月通过 Microsoft Store 更新。至此一个功能走完了从 Feedback Hub 投票、GitHub pitch、规划、实现、专项评审到产品放行的完整闭环。七、给新功能贡献者的行动清单把上述流程压缩为可执行的检查清单在 Feedback Hub 或 GitHub 提交/寻找 feature pitch与路线图docs/Roadmap.md对齐等待团队评审pitch 获批后进入 planning若想法足够简洁可直接进入 implementation在 issue 中声明开始开发避免与社区重复劳动实现时同步准备单元测试src/CalculatorUnitTests与 UI 测试src/CalculatorUITests更新资源文件src/Calculator/Resources与手动测试用例docs/ManualTests.md对照技术评审清单逐项自查可访问性、全球化、最低版本兼容、挂起/恢复、主题与最小窗口、依赖合规、启动性能、TraceLogging、状态兼容、网络容错遵循 CONTRIBUTING.md 的提交规范提交 PR等待微软团队的技术评审与产品团队最终评审后合入 main。这套流程的价值在于它把新功能这一高风险的贡献类型拆解为可评审、可迭代、可验证的四个阶段让社区贡献者与微软团队在同一套质量标准下协作——这正是 Windows Calculator 能够长期保持每月发布节奏、同时持续吸收社区功能如设置页面、无限精度引擎独立打包等路线图事项的制度保障。【免费下载链接】calculatorWindows Calculator: A simple yet powerful calculator that ships with Windows项目地址: https://gitcode.com/gh_mirrors/cal/calculator创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
