提问回顾与个人总结
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2021年春季计算机学院软件工程（罗杰 任健） |
| 这个作业的要求在哪里 | 提问回顾与个人总结 |
| 我在这个课程的目标是 | 学习团队协作，学习产品设计，精进技术 |
| 这个作业在哪个具体方面帮助我实现目标 | 对一学期的软件工程学习历程进行总结和回顾 |
一、提问回顾与新问题
Q1：单元测试必须由最熟悉代码的人来写吗？
“代码的作者最了解代码的目的、特点和实现的局限性。所以，写单元测试没有比作者更适合的人选了。”
——2.1.2 好的单元测试的标准《构建之法》
写单元测试确实没有比作者本人更合适的人选了。
首先，单元测试的目的是对代码的基本行为功能进行测试，从这一点上编写代码的作者对代码所需要具备的行为功能最为了解，能够测试到代码行为的方方面面，包括边界，包括异常测试和捕捉，这点也是在我实际编写单元测试中有所体会的（单元测试的覆盖率）；
其次，单元测试编写的过程，其实也是对代码进行调整和优化的过程，在编写单元测试的同时，编写者也是再一次审视代码，对于非代码作者而言，他需要重新理解代码的逻辑，如果出现bug可能还需要更长的时间来进行调整，而对于代码作者来说，如果出现bug就能够更快地调整，也能够帮助自己二次梳理自己的逻辑。
Q2：充分授权和信任的边界
“在一个高效的团队中，所有的成员都应该能得到充分的授权，他们有权在职权范围内按照自己的承诺完成任务，同时，他们也充分信任其他同事能实现各自的承诺。”
——7.2.3 充分授权和信任《构建之法》
授权是管理者对成员的信任，充分地放权更利于成员的自主安排和开发；反馈是成员对管理者和其他成员的承诺，及时地相互告知进度，相互同步和交流，更利于团队的高效开发。
在团队项目中，团队之间的成员也是如此，由PM分配任务，以两天为单位进行完成，两天内的时间是成员自主安排，但是两天内是需要完成对应的任务，那么“充分授权和信任”就是两天内的时间是自主安排的，“边界”就是在对应的时间节点，能够及时地提供反馈。
Q3：如何评价不符合“用户满意度-投资力度”曲线的产品？
“功能变好，用户满意度就高，功能质量和用户满意度有一个线性的关系...”
——8.5 功能的定位与优先级 《构建之法》
这个问题当时助教已经给我了很好的答案，我当时举的例子是“钉钉”，是属于一种具有用户群体对立性的产品，对于这样的产品不能够简单地用“用户满意度-投资力度”这样的方式去评价，而需要更多地从多个群体的角度去评价和思考。
Q4：顾客真的知道他们想要什么吗？
“MSF强调产品团队与顾客的交流与合作，并不是产品团队拿到合同之后，就闭门造车，直到产品完成才告诉用户，给他们一个惊喜（通常“惊”大于“喜”）。”
——7.2.9 与顾客合作《构建之法》
其实顾客不一定知道他们想要的是什么，但是作为软件产品的研发团队，你可以先猜想用户可能想要的东西，然后让用户去进行选择，就是产品团队提供解决方案，用户选择他们偏好的方案。在这次团队项目中，我们题士也是先一一列举了用户可能希望我们产品研发的功能，然后发放调查问卷，让用户对这些功能的需求程度进行打分，我们再从用户的反馈中选出我们想要完成的功能。
产品功能的调研，是需要和顾客紧密合作交流的，切不可闭门造车。
Q5：结对编程在企业中是否真的有得到很好地应用？
4.5.4 如何结对编程《构建之法》
这个问题我目前是没有得到答案，但是从自己的结对编程的经历来说结对编程是有它的好处，但是结对编程也确实存在效率偏低，两个人磨合等一系列问题，所以我更倾向于在企业中，更多的是个人独立开发模块，然后由他人复审这样的流程。
新的问题
Q1：企业中如何量化一个人在团队中的贡献度？
在本次团队项目中，我们主要是通过代码量和其他工作的方式来衡量一个人的工作量，但是实际的工作量还与类似工作难度等内容相关，在实际中应该怎么更合理地去量化呢？
Q2：敏捷开发的最后会变为什么样子？
比较好奇敏捷开发后的项目会如何继续迭代，敏捷开发给我的印象是先发优势，是大量的沟通交流和繁重的开发任务，那么等产品基本定型后，对于产品的维护和迭代是遵从继续敏捷开发的思路，还是换了其他思路呢？
二、实践中学习的新知识
需求
- 我们使用了NABCD原则来对产品进行需求分析，所谓NABCD就是"Need Approach Benefit Competitor Delivery"，这在我们团队项目的需求分析中也起到了关键的作用，帮助我们快速理清思路，了解为了完成当前的任务，我们需要做哪些事情，具体的需求分析过程可以参考题士——每一位都是在题库中披荆斩棘的骑士。
设计
-
关于设计，我是后端开发，主要参与了数据库和前后端连接接口的设计，感触比较深的地方有，设计过程一定要和前端负责的同学一起分析需求和接口需要返回的内容，不要单独一个后端“自娱自乐”，不然就很容易需要重构
-
结构的设计是至少面向两个开发人员的，一个开发人员的“自以为是”，容易导致后期需要更多的时间来弥补和重构；同时在设计上多花点时间，多讨论点细节的问题，永远不是浪费时间。
实现
- 实现阶段不要轻易修改设计，因为实现一般是前后端按照设计文档自主开始实现，如果轻易修改设计，那么前后端开发人员的信息不一致，可能面临着大量修改，甚至重构
- 要与一起开发某个功能的同学积极沟通，及时进行功能接口的对接，先试着完成一两个接口看看会不会出问题，再继续其他全部的接口，在开发中，我们主要采用两天一次的线下集中开发的方式，所以在沟通和对接上我们做得还是很不错的
测试
- 测试主要分为单元测试和压力测试，能够从单元测试中发现接口没有完善的细节，能够从压力测试中看出哪些接口还有可以优化的地方
- 单元测试和压力测试只能对具体功能进行测试，而功能之间的交互，功能之间的切换还是需要通过实际使用和场景测试来完成
发布与宣传
- 时间节点很重要，发布的早可以有先发优势，但是同时也可能发布得不那么巧，比如我们的目标用户正在考其他的科目，这时候去宣传，可能没有多少目标用户会被吸引过来
- 宣传的方式很关键，如果仅仅是文字宣传，可能看一下就过了，如果配合宣传动画，宣传视频等多种手段，就可能让用户停留更多的时间来关注我们的产品
维护
- 建立用户反馈群，让用户及时反馈问题，团队也可以快速定位和反馈修复进度
三、个人心得小结
个人项目
今年的个人项目主要是三篇博客：2021-软件工程热身阅读作业1，构建之法-个人阅读作业#2和案例分析作业——语雀分析。
在第一篇博客，帮助自己总结了自己这几年的一些学习生活，帮助我进一步思考了未来想要走的方向；第二篇博客是一个阅读作业，是关于项目开发的理论知识的预备，也是之后项目开发的基础；最后一篇是关于具体产品的调研和分析，也让我了解了语雀这个产品，也让我对未来进行产品研发充满了期待，期待能够完成一个为人们提供帮助的好的产品。
结对编程
很开心能够在结对编程中与小树一起合作，我们两个的代码风格差异挺大的，他对于代码风格有更高的要求，这也帮助我改正了以前很多不好的习惯；同时两个人一起交流一起阅读指导书，一起对需求进行设计，这个过程也让我收益匪浅，变得更善于表达自己的观点，表达自己的设计建议。
团队项目
很幸运能够加入删库跑路对不队这个团队，在团队项目开发中，第一次由六个同学一起完成一个项目，从最开始的需求分析到Alpha版本，再到Beta版本，最终完成了“题士”这个产品，并且在考期的时候能够切实给有复习需求的同学提供帮助，这是我莫大的荣幸。
一个好的产品，一定离不开一个好的团队，我非常享受与大家一起两天一次集中开发的过程，很享受产品发布到上线，到获得用户积极反馈的时刻，虽然也常常伴随着修复bug，其他课程冲突等种种问题，但是终归结果是让人满意的。
其实这种团队项目如果能够在没有其他课程交叉，能够专注于项目的开发，我觉得整体的体验应该会更胜。
总结
整体而言，本次软件工程课程的体验是良好的，虽然不乏结对编程和团队项目时的巨大压力，每周完成一次结对项目的迭代，每两天完成一次线下开发，推进进度。累是真的累，但是也是有所收获，从CI/CD部署，issue项目管理，到产品需求分析，产品发布，从个人代码风格修正，到掌握一门新的后端开发语言。
最后由衷感谢结对编程时的小树，感谢题士团队的每一位队友的付出，感谢PM乔佬积极爆肝带动团队前进，感谢助教老师们的认真点评和及时反馈。
软工，完结撒花✿✿ヽ(°▽°)ノ✿。
