软工总结——提问回顾与个人总结
| 项目 | 内容 |
|---|---|
| 本作业属于北航 2020 年春软件工程 | 博客园班级连接 |
| 本作业是本课程个人项目作业 | 提问回顾与个人总结 |
| 我在这个课程的目标是 | 提高软件开发能力、团队协作能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 反思个人的学习实践，解决原有的困惑，总结收获 |
一、解答提出的问题
提问博客：https://www.cnblogs.com/kingkongk/p/12431593.html
1）PSP: Personal Software Process：每个人的工作质量直接影响最终软件的质量？
对于这一问题，我原先持有的观点是：团队中能力较强的人会填补落后的进度，因此并不是每个人的工作质量直接影响最终软件的质量。
经过团队项目的实践后，我对这个问题有了新的理解：1）最终软件的质量并不仅由进度决定；2）每个人的工作质量终将影响最终软件的质量，但并非全是直接的影响。
为了在规定时间内完成项目任务，在项目进度落后时，团队中总能够通过适当调整来追赶进度。但是“完成进度的软件“和”每个人的工作质量都有保障的软件“之间还是有一定差距的。前者达到了完成课程任务的最小可用版本，而后者能够让用户获得更好的使用体验。如果某一成员因为时间原因，草率地交付工作或不完成工作，就会有另一成员负责这一份工作的正常运转，而”接盘“的这一位成员就将割舍一部分优化、测试的时间，这造成前一位成员间接地影响了最终软件的质量。
2）技能的反面：技能的反面是problem solving？
在这个问题中，我原有的理解有些歪曲本意。”技能的反面是problem solving“这句话讲的是，精通一项技能的人能够迅速地利用该技能投入生产，而与之形成对比的是，不精通的人还需边学习边应用，效率就显得十分低下。我之前的观点中，将”Problem Solving“独立于语境之外去解析，因此显得不太合理。
在团队项目开发中，我能够切身地体会问题本身。我在团队中负责前端开发，在最初使用Vue、javascript等前端知识进行开发时四处碰壁，想要实现的功能都只能边查边用，开发效率很低，可能写一个可用的请求、修改一个元素的样式就要花上半天时间。但是在熟悉了基本的语法和开发流程以后，就能够独立解决一些相似的问题了。
3）结对编程 测试的极致做法是TDD？
将测试发挥到极致确实是”从测试开始写程序“，结合开发实际与教材思考后，我开始理解这一问题。测试的极限就是覆盖所有编码的逻辑，而从测试开始写程序，就能够让程序始终在已知的区域内开发，最大程度确保测试的完备。
我之前理解的”需求在不断改变，代码的改动将引起测试程序的浪费“存在一定的偏差。如果需要使用将测试做到极致的开发方式，本来就要求需求的变动范围尽可能小，才能在程序的精度上下功夫。此外，代码的改动不一定会引起测试程序的改动，模块化的测试只针对代码完成的功能，一些细节上的代码即使改动，也能保证在覆盖范围之内。
4）敏捷宣言：敏捷求成品，而不需要文档？
我认为敏捷做法与现有软件工程做法的对比中，应该是侧重点的不同，而不是不可共存的关系。反过来想就会发现我原先的观点有些滑稽：如果说敏捷开发只需要可用软件而不需要文档，是不是说现有做法只需要文档而不需要可用的成品？
敏捷开发的做法中注重开发的效率，对于文档的要求则相对较宽泛。我们的团队开发中正是基于这样的理念，PM给出的文档更类似于todo list，能够很清晰地展示当前剩余的任务、待修复的问题以及基本的约束，我们只需要根据文档完成对应的工作即可。
5）画扇面：速成还是求全？
在最初的理解中，我以学生的视角分析了一项作业在不同情况下应采取速成还是求全的策略，不过在分析中，我对于作业项目的定义似乎更偏向于个人或双人的结对项目，因为个人意志较容易影响项目需求。当项目由一个多人团队共同完成时，个人提出的想法就难以在开发过程中影响项目的整体走向。
在我们的团队项目开发中，经常会遇到类似的问题，伴随着开发，创新性的想法层出不穷。本着敏捷开发的理念以及定期的团队交流，好的想法会被记录，等待最初的成品完成后再开发，或是留到Beta阶段；而一些考虑不周全的想法也会及时地被团队成员们指出，从而避免生产力的浪费。这样有组织的开发过程，不仅保证了初步成品的开发速度，而且提升用户体验的优化功能也能得到实现，完成了”速成“和求全”的兼得。
6）创新的迷思 连载(2)：技术创新不一定是关键？
这是一个比较钻牛角尖的问题，技术创新确实能带来一骑绝尘的实力，但是如果无法解决用户的痛点或是给予全新的体验，也无法在一众产品中胜出。就拿我们团队的DDL Killer项目来说，如果在爬虫技术上实现创新，能够秒爬取课程中心，但是用课程中心的样式陈列作业、资源，用户在初试时就会产生这样的疑问：为什么用你们的产品而不用课程中心？虽然我们并没有十分出众，但能够取得一定的客户量，很大一部分原因是因为切中很多同学忘记DDL的痛点。
二、新的问题
1）网站维护时如何保证现有业务不受影响？
这是一个更偏向实践的问题。我们在本次团队项目开发的过程中，经常会遇到一些大大小小的问题，比如当天日程无法完全显示、ddl排序优先级不对等等，这些影响核心使用体验的问题需要尽快修复。而修复完成之后，服务器需要重新编译运行至少一次，在这个过程中如果恰好有用户正在使用，可能长时间的卡顿会直接劝退。
目前能想到的方法是，修改前端添加网站维护提醒，打包静态文件是不需要重新运行网站的，此时用户刷新界面就能看到我们的提醒。不知道业界对于网站的维护有没有更好的办法？初步检索之后没能找到很好的答案。
三、学到的知识点
1）需求
拍脑袋提出的创意难以说服自己和他人，而NABCD模型就是一个比较系统的需求框架，能够清晰地展示一个创意的特点与可行性。由于我们的团队项目在初期就使用了NABCD模型分析课程组给出的选题和自己的创意。以下是DDL Killer最初的NABCD分析：
2）设计
用户界面，用户体验中讲到评估用户界面的十条原则：1）可视性原则；2）系统界面符合现实惯例；3）用户有自由控制权；4）一致性和标准化；5）预防用户出错；6）减少记忆负担；7）使用效率和灵活性；8）易读性；9）帮助用户识别，诊断并修复错误；10）提示和帮助文档。
我们的系统在用户界面的设计考虑了这些评估原则，如针对原则1），失败的操作给予报错提醒；针对原则3），对日程的修改都可逆；针对原则6），提供快捷创建选项；针对原则10），首页清晰的使用教程和板块提示；……
3）实现
在实现阶段，我们更多地遵循敏捷开发的理念，注重个人和交流，快速开发出可用的软件，与用户合作（听取用户给出的意见），响应变化并及时做出修改。
4）测试
在单元测试的基础上构建回归测试十分重要，因为新增功能或修复缺陷的代码有可能影响原有功能的正常工作。回归测试指的是在新版本上运行所有已通过的测试用例，以验证有没有“退化”的情况发生。如果是设计变更，需要修改测试用例以适应新功能；如果确实引起了退化，则需要尽快修复，使系统达到可正常工作的状态。
5）发布
软件并不需要等到等到所有的bug都修复了才选择发布，优秀的软件公司能够找到一个平衡点，即能及时发布能够解决用户问题的软件，又能及时修改软件中的问题。对于一些无关大局的问题，在不影响用户基本使用的情况下，可以不用马上解决，等到下一阶段进行修复。
6）维护
维护阶段随着用户的使用以及反馈，会出现许多需要修复的bug，让修复bug的门槛逐渐提高是一个不错的招式。对于同类的bug、不影响正常使用的bug，可以设置较低的优先级。先去修复那些严重的、优先级高的bug，也许有机会将低优先级bug一同修复。
四、个人心得
4.1 个人项目
在个人项目中，我经历了从需求分析、设计，到编码、测试的一整套代码构建流程，并使用PSP表格预估任务耗时以及记录实际耗时。将开发时间量化后发现，预估的编码时间和测试时间与实际的相差较大，原因分析后为以下三点：1）过分追求速成，疏忽了一些精度、边界问题，导致bug频出；2）编码能力下降，导致处于"Problem Solving"状态；3）分心导致思路不连贯。
个人项目的成绩发布后，我在基础测试用例中丢失了许多分数，反映出测试不够充分。今后在个人开发中，应注意合理分配每一阶段的时间，不能急于求成，也不能认为“只要我不测，就没有bug”，还是要经过充分的测试确保程序的正确性。
4.2 结对项目
结对编程是一个非常有趣的开发方式，不仅能够学习到队友良好的代码规范和新颖的编码技巧，而且有人进行代码复审也降低了错误出现的概率，一些纠结的问题在沟通之后很容易找到答案，而无需花费大量时间在网上分辨信息真伪。
结对编程中存在的问题，一方面使Live Share响应较慢，对方的修改可能有一定延迟才能看到；另一方面，双方初识的状态会带来一定沟通成本或心理障碍，比如担心队友嫌弃自己的编码水平等，需要时间磨合才能达到较好的开发状态。
4.3 团队项目
我们的团队项目是DDL Killer，北航学生作业提醒与资源整合平台。在团队项目中，我体验了团队开发的基本流 程，即 需求、设计、实现、测试、发布、维护六个阶段，并参与了Alpha和Beta两个版本的迭代开发。作为前端的开发人员和维修工，我不仅学习了许多Vue开发网页前端的知识，而且也收获了许多团队协作技能，比如git团队协作。
经过团队项目的开发后，我认为在一个团队中，非常重要的两个因素是团队氛围和团队理念。团队氛围决定了一个团队的开发效率，团队理念决定了项目最终的质量。本学期中，我非常有幸成为软软软团队的一员，虽然我们最终的产品还有许多需要改进的地方，但在开发的过程中，我切身体会到了创造的乐趣。我们的团队氛围十分融洽，经常组织腾讯会议进行“多人结对编程”，互帮互助的同时各司其职。此外，我们团队潜在的理念始终是打造一个好用且长期可用的产品，而非应付作业了事，因此在看到用户量的增加以及反馈，激动的心情难以言喻。在课程展示中，我看到许多团队也制作出了非常优秀的产品，致力于解决人们在各个方面的需求痛点，各个团队的特点、协作方式有值得学习，在这一种追求优质的课程大环境中，我收获颇丰。
