问题回顾
- A/B 测试：A/B 测试只设置了一个变量。若为了同时测试多个变量，是否能做多变量的测试呢？
不应该对过多的变量进行测试：
- 过多的变量导致待测产物过多，不好收集反馈
- 假设有 $n$ 个变量，那么如果对一个用户而言只呈现一种产品，则他能看到的待测产物比例是 $\displaystyle\frac{1}{n!}$
- 软件开发流程：在 Web 应用开发时，团队往往采用前后端分离的架构。这意味着一些成员开发前端，一些成员开发后端。前端需要与后端交互，是否意味着前端要等后端开发好了再开始开发呢？
应当对核心 API 做周全约定（契约式开发）后前后端再开始同步开发，期间遇到的小型 API 可由前端提需求
- 工程师的职业发展：若某人身体有缺陷，他/她还能做一名合格、甚至是优秀的工程师吗？
如果不影响此人掌控工程开发的要诀，应该是没有太大问题
- 代码复审：注意到有 todo/bug 等标记，个人认为这种标记不应该出现在代码里。
都应该使用 issue 进行管理
- 代码风格：注意到书上有关 public/protected/private 的叙述甚少，这里以面向对象的视角，个人对 public/private 的用法都比较了解，也经常使用，但对 protected 的了解不多。
此问题暂时未解决
实践中的学习
- 需求：在需求分析阶段，我们“大本钟下你和我”团队积极与 OS 课程组的沃老师沟通交流，研究需求，形成 NABCD 分析文档。
- 设计：多与开发队员交流，避免概念理解、设计不一致等问题。
- 实现：使用 CI/CD 工具自动检查代码风格、回归测试、构建部署。
- 测试：
- 单元测试：高覆盖率不能说明少 bug，很多 bug 往往不是单元测试能够检查出来的。但需要对重要功能保证充分的单元测试，以供回归测试。
- 压力测试：保证高并发场景下前端资源、API 等的服务正常。
- 场景测试：自己成为用户，体验用户操作的流程。
- 发布：
- 注重用户反馈，及时修复缺陷。
- 注重产品宣传，注重文案润色。
- 维护：
- 使用 Docker 容器技术在服务器上启动多个服务，保持服务环境的一致性。
- 后端与评测端记录日志，从而尽可能展示事故发生时的现场。
软工经历与总结
结对开发
结对开发要求使用 Windows 下的 Visual Studio 进行开发，这对 Linux 用户相当不友好。开发后期，我直接切换到 Linux 下使用 Jetbrains Rider 完成了剩余的 C# 开发任务。个人认为，使用跨平台 IDE 才是当今开发的主流选择，而且 Jetbrains Rider 的开发体验远胜 Visual Studio（除了 Win Form GUI 开发必须依赖 Windows 平台），希望未来课程组能将眼光聚焦到 Jetbrains 的软件上（教育邮箱可免费使用），使用跨平台 IDE 指导软件开发。
结对开发中，两人的互相提醒能够有效避免低级错误，从而减少 bug 的发生。但我个人认为，在大型软件的开发中，使用「合并请求+代码复审」的开发流程或许是更好的选择。团队成员不会总是写 bug，往往是 90% 时间写正确的代码，10% 时间写出错的代码，没有必要安排一个领航员捕捉那 10% 的出错现场，只需要考虑让代码编写者自己设计单元测试、让代码复审者认真查看代码，基本上能够保证代码不出错。
团队协作
先说开发 IDE 的选择，我们全部采用 Jetbrains IDE 进行开发，统一了开发环境，极大提高了代码质量（Jetbrains IDE 的代码建议总是非常到位）与开发效率。
再说代码质量控制，我们严格采用「合并请求+代码复审」的机制进行贡献代码，确保每一份代码都经过编写者本身、至少一名复审员查看，且确保通过回归测试与代码风格检测等自动化测试，确保代码质量。
另外，我们使用「Dev+Prod」双轨开发机制进行开发与发布，严格区分开发服务与生产服务，确保开发过程中生产服务不中断不变更，可给开发者与用户同时提供服务，极大提高了生产效率与服务质量。
再者，我们使用 Docker 容器技术制定软件运行环境，每一个服务均运行在 Docker 容器中，确保了软件的测试、构建、运行环境不被污染；同时由于采用了 Docker Regsitry 来管理评测服务镜像，我们就可以非常方便地为评测服务进行手工扩容，提高了系统的弹性。
最后，我们在每一阶段初均制定明确的分工表与任务时刻表，给任务划分 issue 后团队成员自行领取 issue，并使用燃尽图方便地管理任务进展情况，同时使用 Gitlab 的「动态」页面方便地查看近期项目的活动，这极大提高了项目管理者的管理效率。
在团队协作过程中，我熟悉了这些项目运行、维护流程，更理解了软件开发的真正的主干问题——不是如何写代码，而是如何管理代码与人员。领导一个团队去干一件事情，最需要考虑的是如何推动建设治理能力现代化，如何推动团队内技术能力互相学习的内循环，如何推动外界先进生产力、管理水平的引进与革新。明星团队从来不缺明星，往往缺的是一个能够将明星们聚起来形成合力，共同推动团队项目健康进步的「领航员」。
由衷感谢大本钟下你和我团队同学们的倾力合作。
尽心尽力，无问西东！
