个人作业-提问回顾与个人总结

个人作业-提问回顾与个人总结

项目	内容
这个作业属于哪个课程	2022年北航敏捷软件工程
这个作业的要求在哪里	个人作业-提问回顾与个人总结
我在这个课程的目标是	通过实践锻炼工程能力
这个作业在哪个具体方面帮助我实现目标	反思与总结

问题思考

提出问题的博客：个人阅读作业-阅读和调研

Q1：项目内分工原则和管理方法

绝大多数时候根据技术栈、经历、意愿综合考虑分配就足够了。具体特殊情况才需要具体特殊分析。

Q2：词性与分类的关联

在我们团队的实践中，我们对于需求场景中的元素进行了高度抽象与归纳，其类别是扎根于具体意义的，相比于刻板地由命名导出类别具有更直接、更根本的优势。

Q3：任务的组织和计划

任务时间节点具体安排从来都不是一个简单的问题。以并行任务调度问题为例，除非 P=NP，否则该问题不存在近似比小于 3/2 的算法。对于 4 台或以上处理机的情况，该问题是 strongly NP-hard 的。因此，我们对于任务的计划与调度最终只能基于 heuristics。具体到实际情况而言，由每个人自己根据自己的情况决定可能已经是一个较好的选择了。

Q4：个人技术的扩展

在我们团队的项目中，我们尝试了运用其中提到的部分工具对部分指标进行测试。测试结果对于我们评估自己项目发布的可行性起到了重要的参考作用。

Q5：关于社会的发展

我颇为认同老师们和助教们提出的论点，这里不再重复。

各环节收获的软工知识

• 需求：NABCD，可以清楚地概括出项目的特点
• 设计：原型图，可以快速、直观地与他人交流自己对于交互逻辑的设想
• 实现：变更管理，可以在敏捷项目中保证重要信息的转发与传达
• 测试：场景测试，结合目标用户、常见场景测试系统的可用性、交互逻辑的合理性
• 发布：出口条件，帮助团队瞄准发布节点，做好发布准备
• 维护：可传承性，在一个由多代团队共同维护的项目中决定后续的敏捷程度与项目质量

心得

软件工程这门课程给了我一个和许多优秀的同学交流与协作的机会。在软件工程中，我在项目管理、任务协调、事项沟通与对接等方面积累了许多经验，对于 Web 主流技术也有了更深的理解。软件工程中遇到的突发情况与生活中的其他情况相叠加，又很好地锻炼了我的抗压能力。由于我在 Alpha 阶段实际上负责了项目组织工作，在 Beta 阶段又在项目中处于比较摸鱼的状态，因此对于不同方面的不同角色都有一定的体会，下面按照时间顺序流水账记录。其中也有许多事情不是在软工课中才学会的，不过由于比较有意义，故列出。

• 3.11 今年修 OS 的同学有 600 余人，需要尽早对这件事有一个较深的认识。
• 3.15 预先联系资源（域名、服务器）很重要，这可以加速开发上路的进程。
• 3.18 这个年头感觉国内到处都要绑手机，搞个团队公用号挺费劲的。
• 3.25 尽量使用公钥登录服务器，而非使用密码。确保团队内其他人理解这一点。
• 4.4 Vue / Electron 太好看啦！
• 4.8 发现自己对于行数的预估很不准确，需要充分认识到项目中基础交互逻辑的工作量。
• 4.8 共享邮箱时使用 POP/IMAP 有助于优化访问流程。确保团队内其他人理解这一点。
• 4.13 对所有服务实行生产/开发双轨制是有必要的，这保证了数据的完整性与隔离性。
• 4.14 在容器化的部署环境下，不应往部署环境中安装任何开发工具链，尤其是 node/npm/yarn、python/pip、go 之类的。确保团队内其他人理解并支持这一点。
• 4.17 计划阶段最重要的一项任务是日程，这是不可或缺的。
• 4.18 充分利用好 GitLab 的功能能提高项目管理水平，如 issue 的 due date，assignee，tags，milestone 等等。如果单独点击设置太麻烦可以使用 quick actions。
• 4.19 有时候保留完整的概念建模，为后续设计留有接口是必要的。很多东西可能一眼这个可以省了，或者说在目前所列的需求里，省了之后做起来的区别也不大。但项目归根结底不是只做给自己用的，也不是只由这一代团队来维护。把数据模型和事物的对应关系整理得更清晰，是更方便进行开发、维护的。从数据库操作本身来说，这样的保留也可为 API 的实现提供简洁性。这里当下数据模型中的简便性，和可拓展性、清晰性之间的 tradeoff，值得仔细斟酌。
• 4.19 越早进入开发正轨，越早适应敏捷流程，项目进度和完成度压力就越小。应该尽早养成使用 merge request 提交代码的习惯。
• 4.21 当不确定数据库是否能够优化操作到合理的开销时（比如正常的根据 id 连表检索应该是对数时间复杂度），不妨直接用 EXPLAIN 或者 EXPLAIN ANALYSE，这往往能给出最准确的答案。
• 4.21 单元测试框架越早形成越好，因为形成了框架才能形成流程。
• 4.21 例会文档这种东西最好随开随填，这样的成本和时效都是最好的。
• 4.22 使用自动化工具绘制燃尽图能极大地节省人工，而且涉及的工具链也没多难（Vue + ECharts），其实应该在冲刺阶段前两天就分配出去的。
• 4.22 使用较新的工具链很重要，否则会出现部分成员 lockfile 还在 version 1 的情况。最好确保大家都用同一个较新版本的工具链。确保团队内其他人理解并支持这一点。
• 4.22 文档工作单线程效率不见得高，其实由相关人员自己完成可能更敏捷。
• 4.22 所有任务不能依赖主动承担，否则早晚会出现盲区。必须确保团队有可靠的 management 和 push 机制，以帮助团队把握时间紧迫的任务。
• 4.22 讨论结果的固化很重要，尽量形成 wiki / issue / comment 等资源。
• 4.22 Code Review，即 Merge Request 的审核，需要有质量的保证。如果只是为了合并，不对内容进行任何检查，就失去了 Code Review 的意义了。
• 4.24 测试账号的保密工作很重要。高权限账号一般仅限内部知悉并使用，对外只能公开部分低权限账号。否则会有测试环境被恶意攻击的风险。
• 4.24 部署方案（域名、反代）等涉及应用服务访问的设计是比较关键的，确保团队内所有人知悉相关事宜，以帮助大家快速把握应用的部署方案，从现象快速排查、定位问题。
• 4.25 对 API 的路由进行分组是很重要的，这有助于将众多 API 逻辑地系统地组织起来，方便开发与对接。
• 4.30 重要配置与重要数据尽量存有一份备份，以防突发情况。
• 5.1 灵活调整任务安排很重要，可能中期经常需要把暂时不好做的东西往后搁一搁，把现在能做的往前提一提。主要肯定还是跟着需求走。
• 5.2 双轨制中两轨的架构差异不宜过大，否则会带来迁移时的累积风险。
• 5.3 系统里没有自动化的东西，最好都留下文档，比如如何创建第一个用户，创建第一个课程等等。尽量不给下一代团队留下死角。
• 5.6 用项目 Wiki 写文档其实是个不错的 idea。
• 5.9 项目中开发以外的任务也需要以某种形式管理起来，用 issue 感觉有点不够及时，直接在群里发 todo table 又比较耗人工。可能需要一个比 Space 好的管理工具。
• 5.9 对于任务的认识最好对齐，以免大家合作完成同一任务时因理解上的偏差导致采用的态度与方式不同而产生其他后果。
• 5.11 grep / sed / sort / uniq / wc 真好用！
• 5.11 特殊部署环境下尽量避免使用 CDN 等资源，以免断网访问不畅。
• 5.17 在子项目脱离自己的责任范围时，最好对相关事宜保持关注，保留个人意见，但不宜过度强化个人意见。
• 5.27 遇见暂时无法解决的问题时，需要尽快思考备选方案，避免在问题中迟滞过久，影响项目整体进度。
• 6.1 例会上形成的设计共识最好固化并保证传达至每位成员，以免后续由于部分成员遗忘出现摇摆不定的情况。
• 6.2 随时把握和聚焦当下重要、急迫、核心的任务，避免分散精力。开会应以精简为主，只说最重要最值得讨论的事。
• 6.2 对于项目全局性更改，即便更新了 readme 或在例会上提及，仍然需要 explicitly 通知所有项目成员。
• 6.17 awk 真好用！