个人作业-提问回顾与个人总结
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2022 年北航敏捷软件工程 |
| 这个作业的要求在哪里 | 个人作业-提问回顾与个人总结 |
| 我在这个课程的目标是 | 学习软件工程相关知识，提高自己的代码能力与团队协作能力。 |
| 这个作业在哪个具体方面帮助我实现目标 | 回顾课程内容，回顾所学。 |
1. 解答疑问
请尝试对自己曾经提出的问题进行解答，并阐明，是如何通过看书，实践，或者讨论弄清楚的。
问题 1：goto 的使用
对于敏捷开发而言，最重要的是在规定的时间内交付产品。产品要满足用户的基本需求，而设计细节和更多高级需求可以在不断迭代中实现。因此，如果时间紧迫，又有确实需要使用 goto 语句的需求，是可以在代码中使用的，但不要滥用。
在我的写码经历中，由于很早就从老师授课中了解到了 goto 语句的危害，因此也没有再代码中使用过。偶尔想要使用时也会再思考后找出可以替代的语句。
问题 2：单元测试的编写时间 (TDD / TLD)
在实践中（结对编程 & 团队项目），我们都采取了先写代码，后写单元测试的方式。采用这种方式的原因一方面是因为课程要求（比如团队项目中第一周用户调研、二三周代码实现、第四周测试和发布），另一方面是由于敏捷开发中需要先实现功能，采用 TLD 的形式能够较早的完成开发。
不过，并非所有的测试都是在后期完成的。由于组队项目中采用随时部署的方案，因此部分关键的测试代码也被安排在 CI/CD 中，便于满足回归测试条件和项目准出标准。
总的来说，虽然采用 TDD 方式可能可以有助于理解 API 语义、避免重构，但在实际执行中由于工期限制等原因存在一定的困难，据我观察选择 TLD 方式的人更多。
问题 3：单元测试的编写人
在团队项目中，我了解到单元测试只是测试的一方面，且由于需要对每个模块设计单元测试。因此由写代码的人亲自实现在效率上会更高。而测试人员则可以负责更多其它黑盒白盒测试等内容。
问题 4：“典型用户”是否能改善用户体验
在团队项目中，我认识到用户调查和采访比设计典型用户更能真实的了解用户需求。诚然，通过描述典型用户可以让开发者一定程度上站在用户的立场上发现需求，但真实用户的需求往往不是很短时间的头脑风暴就能全部掌握的。以 OSOME 平台为例，在设计初期我们根据以往的经验列举了很多需要实现的需求，但在每次和老师开会时都不免了解到更多需求，有些是需要身为教师，经历多年课程开发和设计才能有切身体会的需求，这些是我们难以提前料想的。因此我认为，想要真实的了解用户需求，改善用户体验还是应该“从群众中来，到群众中去”，通过采访、问卷等形式了解。
问题 5：“结对编程”的效率问题
通过结对编程的实践，我发现结对编程确实可以减少 bug 的发生，但也确实如我想象中那样会降低工作效率。参考其他同学的博客，不少结对组都由于时间和地点的限制采用非结对编程的方式完成任务。
且针对结对编程代码质量更高这一问题。面对一些简单的 bug，如笔误等并不需要大量思维难度的问题，在独立编程时只要即时测试就可以发现。而面对一些复杂的 bug，如算法设计问题等，在结对沟通时也可能两个人都陷入同一个思维陷阱中，且相互确认反而可能盲目自信，在错误的道路上越走越远。因此结对编程的代码质量也不一定就远优于单人编程。
总的来说，在以后的工作学习中，我可能还是会更倾向于一个人编程而非结对。
2. 知识点
- 需求
- NABCD 模型
- N, Need 需求
- A, Approch 做法
- B, Benefit 好处
- C, Competitors 竞争
- D, Delivery
- 用户需求往往比开发者设想中更复杂，在实现前先了解用户需求，可以减少重构和返工
- NABCD 模型
- 设计
- E-R 图绘制
- 实现
- 采用双轨制有助于在保持发布服稳定时更新生产服，在维持正常功能的前提下不断迭代开发
- git 在团队开发中的作用至关重要，需要对重要分支进行保护，避免
force push - 采用 CI/CD 部署和每日构建有助于保证代码质量和可用性。
- 测试
- 对于前端而言，由于不同用户的使用习惯不同，邀请非编写者进行测试有利于发现交互逻辑上的问题。
- 发布
- 发布过程中的宣传很重要，但也不是唯一决定用户量的因素。关键还是要让系统足够吸引人，有足够区分于其他系统的所谓杀手功能，才是保证用户活跃度与粘性的重要因素
- 维护
- 写好代码说明文档可以帮助系统长期维护。同时，团队中需要有至少一个人对整个系统有所了解，便于维护工作的交接和稳定执行。
3. 心得与体会
个人博客作业
个人博客作业促进了我的思考。印象深刻的是对现有软件的调研。调研之初我认为已经发布的产品应该是几乎不存在 bug 的，且功能实现也相对完善。但在调研过程中发现已经发布且有一定用户量的产品也可能会存在不少 bug，且用批判的视角也能发现交互逻辑、界面设计等方面的不足之处，这对我之后自己编写前端代码都有一定的帮助。
结对编程
结对编程对我来说是全新的编程方式，总的来说还是很有意思的。相比于一个人单打独斗，结对编程中遇到困难可以相互讨论，共同面对困难，也可以互相激励，是更加有趣的体验。（感谢我的队友带我 orz）但不能否认的是，这样也会带来一定的低效问题，最终很容易变成两个人在一个地方各自写代码，因此以后可能不会再次尝试。
团队开发
团队开发是软工课程的重点，也是令我印象最深刻的部分。进入这个团队纯属意外，队里的大家也都是巨佬，因此压力还是很大的，总是担心自己会拖人后腿，在听说有换人环节后我更是在很长一段时间都坚信自己肯定是会被踢出去的人。但团队中的大家都很好，遇到问题会耐心的帮我解答。虽然课业压力很重，但大家都把团队项目作为很重要的部分，并在此花费了大量的时间。通过不断的学习，我也掌握了很多前端编写的技巧和方法，也自以为没有成为拖大家后退的人，为此还是很开心的。
在软工之前，实话说我并没有觉得前端开发多有意思，也一度宣称自己以后绝对不要去做前后端工作。但在设计实现中，我发现前端也不是一个很无聊的工作，也有着很多挑战，甚至很多时候会让人停不下来。我发现，想要实现基础的功能往往并不困难，而想要实现一个便于使用，又赏心悦目的前端则需要大量的经验与时间。配色、排版、交互逻辑等都是需要考虑的因素，有时，为了设计出一个有趣的界面也需要程序员的脑洞。我喜欢去编写一个个不同的界面，这让我觉得自己没有在做重复性的工作，也能不断面对新的挑战，是很有趣的体验。
软工课程就要结束了，感谢老师和助教一学期的辛苦付出，也感谢我的所有队友。合作愉快，后会有期~
