提问回顾与个人总结
提问回顾与个人总结
一、作业要求
我们在学期开始的时候布置了阅读作业，要大家快速阅读，同时提出自己的问题。
现在一个学期过去了，同学们完成了一个结对项目，两个阶段的团队项目，中间还经历了转会环节。
正所谓"实践是认识的来源、目的、动力以及检验认识真理性的唯一标准"，在经历了一个学期的学习和实践后，请大家写一个提问回顾与个人总结的博客。
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 博客园班级链接 |
| 这个作业的要求在哪里 | 提问回顾与个人总结 |
| 个人博客作业 | 初窥软件工程 2020BUAA软件工程⋅个人博客作业 |
| 我在这个课程的目标是 | 获得成为一名软件工程师的能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 总结回顾 |
二、问题解答
问题1. 单元测试时如何有效拆分单元？输入数据和输出数据如何构造？
答：单元测试的粒度，依项目而定。例如在团队项目中，我们做的知识路书web应用，其前端的单元测试是以任务功能进行划分的，输入的数据即为覆盖该功能模块全部逻辑的一组操作。对于结对编程项目，单元测试应该以函数或类为单位，输入输出的数据即按照类的构造函数或函数的输入参数进行。
问题2. 即使用了源代码管理工具，也很容易忘记某个版本究竟是干什么的，如何更好地通过message提示自己？
答：使用集成开发环境的git GUI工具，可以更加方便地编辑message，甚至支持markdown语法。还可以github平台的pull request功能，能够更加清晰地写清某次代码迁入做的功能是什么。团队开发时，要商议好commit的message和Pull request的message格式规范，例如我们的敏杰开发团队规定的commit格式为：姓名：功能1；功能2；...
问题3. 怎么在源代码管理工具中更优雅地改bug?
这个问题理论上可以使用git rebase的方法进行，但是容易出错，不是很安全。在我们的团队项目开发过程中，直接使用顺序commit式bug修复，由于很少使用代码回滚，维护的最新版代码始终是当前功能最多、bug最少的版本。
问题4. 多人合作时，如何解决push冲突问题
不同开发者尽量不要同时修改相同的文件，每个Issue和Pull request的粒度尽可能细就可以更好地保证这一点。如果真的赶上了必须要修改相同文件的话，二者需要一起合并代码，保证双方的更改不出现冲突。在我们团队项目的实际开发过程中，每个人负责开发的部分几乎少有文件重叠，当然也有少量情况出现了代码冲突的情况，我们是通过有冲突的开发者共同解决冲突的办法处理的。
问题5. 如何解决开发基础差的问题？软工课上如何解决？
对于我们的团队项目知识路书的开发初期，只有hdl一名同学拥有开发经验，其它成员都是开发小白，但是我们队伍的成员都有很强的快速学习能力，我们经历了2年的编程训练，已经有很好的编程功底，经过熟悉开发的成员一带，很快就掌握了基本的开发技术，之后就是滚雪球式的技术积累了，在完成了alpha阶段的开发任务后，我们的开发技术就都可以满足我们项目的需求了。
问题6. 初创公司如何找到技术创新与营销经营的平衡点？
对于技术初创公司，技术固然重要，但是一定不能掉进唯技术论的怪圈，只顾技术，永远在迭代产品、优化产品，而不去想推广、想营销。企业总归是要以营利为目的的，推广、营销可以带来更多的用户，带来更多的用户反馈，使团队更清楚产品的真正需求。同时推广营利可以招揽更多人才，有更多优秀且志同道合的人加入，同样会进一步促进技术的发展。
问题7. 软件工程有没有什么解决不了的问题？软件工程的痛点在哪？
软件工程解决不了的问题是现有的管理学理论无法很好解决的问题，无法抽象成统一的理论，这类问题的解决要因人而异、因事而异。不同的开发团队、不同的开发产品都会有不同的解决方法，所以说管理学是一门艺术，软件工程管理亦是如此，一个软件工程项目的成败、管理好坏，软件工程理论固然重要，但产品经理、项目负责人的管理艺术往往更能决定产品的命运。所以，软件工程的痛点也在于此，只有将软件工程理论，和实践、经验深刻结合、互相补充，才能早就一个优秀的产品经理，形成优质的团队管理文化。
三、新的问题
1. 当团队成员对价值观念、产品方向有不同观点时，应该如何解决观念上的不一致？
在《人件》中介绍了有凝聚力团队的概念，大家都秉持相同的价值观念、产品观念，团队整体的力量将大于个体之和。但是当团队成员对价值观念、产品观念有不同观点时，应该如何解决观念上的不一致、重新回到一个有凝聚力的团队整体呢？
当观点可调和时，采用讨论分析等办法可以得出一个最优的解决方案，让团队中的所有成员认可。但是当观点矛盾不可调和时，又该怎么办？独裁？分裂？还是...
2. 何时放弃？
当一个产品的实现难度、投入资源、预期收益等与原定设想不符时，团队会倍感沮丧，凝聚力和干劲都会大打折扣。作为项目负责人，有抉择坚持还是放弃的责任，在何种条件下可以下定决心放弃？有没有理论上的一种条件，达到这种条件就应该放弃，坚持就是浪费资源？
四、习得知识点
在团队项目中，我们在实践中学到很多软件工程的知识点，下面分类进行介绍。
1. 需求
需求分析是一个软件工程项目的第一步，抓住一个好的需求往往是项目成功必要条件。我们敏杰开发团队，经过若干次会议的头脑风暴，碰撞出了几个有痛点的需求，当时的选择有三：
- 基于深度学习的字体自动生成
- 医学、化学在线实验平台
- 图形化文献管理工具
经过NABCD分析，我们最终得出，图形化文献管理工具这个需求我们团队更能驾驭，我们本身就是该项目的目标用户，可以更直接准确地分析出需求。于是我们选择了知识路书——图形化文献管理工具这个项目作为我们的开发目标。
2. 设计
通过撰写技术规格说明书和功能规格说明书，我们更加清晰地描述了整个项目的设计。在实际操作中，我们在组会中共同绘制ER图，成员一起在一份ER图上添枝、加叶、修改，最终共同碰撞出了一份完整、清晰的项目架构，团队成员也都明确了项目的总体设计。在确定了项目的总体设计后，我们讨论了实现上的设计，由于目前web端应用的受众广、可移植性强、移植性好，我们选择了基于web平台的实现设计，并进一步确定了选择的前后端框架、平台、工具等，大家开始了前期的学习准备工作。
3. 实现
我们首先根据项目特点进行人员分工，我们的项目主打前端应用，后端主要提供CURD等api支持，所以前端共4名成员，后端2名，1人PM兼自由人，可以根据开发进度补充至前端或后端。在开发过程中，我们采用增量式敏捷开发工作流，在alpha阶段完成了最核心的功能，完成了一个最小可用版。在beta阶段，持续重构与优化alpha阶段的工作，并增量式添加新的功能。在开发中，类似每日构建原则(daily build)，我们做到了实时构建(always build)，我们保证每一次提交都必须可运行，在代码互审时，不仅仅要展示所改动的模块是否工作正常，还应简要回归测试原有功能，保证产品时刻可运行。
在项目管理中，我们学到了非常多的知识，在beta阶段新成员进组时，我们向其介绍了我们团队的整个项目工作流，让其颇为惊叹，这才是软件工程。关于我们的项目管理可以参考我的这篇博客使用Github进行软工开发管理
4. 测试
由于是敏捷开发，在测试中也采用敏捷开发的风格，我们的实时构建(always build)原则能尽可能保证前端在开发过程中的持续测试，每位成员在开发自己功能的时候，都可以不经意地测试网页其它部分的功能，一旦发现问题，立即写入Issue。由于开发过程中已经针对功能进行了较多的单元测试，在实际测试阶段我们重点进行了场景测试，将用户的使用流程分成若干个工作场景，对软件进行整体测试，保证用户不会触及最明显的bug，另外还可以以用户的身份体验产品，得到新的改进需求。
对于后端，我们采用了覆盖率测试，使用成熟的测试框架，使测试覆盖率达到90%以上，保证了后端api的稳定与精准。
5. 发布
我们在alpha阶段的推广出现了一些失误，导致了推广效果不佳。主要原因是选错了“目标用户”，我们的产品主要面向有科研需求的研究生、博士生、导师等，而在alpha阶段，我们重点向本科生进行推广，导致我们没有达到预期用户量。在beta阶段，我们根据目标用户的使用特征，定向地推广给实验室的研究生，让他们在组会中尝试使用我们的软件，获得了不错的推广效果。另外我们还做了针对本科生科学方法论课程的杀手功能，可以利用这个功能，让同学们更方便地完成该课程的要求，我们在科学方法论课堂上展示了我们的产品，也收获了不少的用户。所以，对于软件工程，开发技术固然重要，推广的技巧也必不可少，不然就只是写程序，而不是写软件了。
6. 维护
对于维护，用户的bug反馈十分重要，我们在开发初期，就在页面中加入了bug反馈入口，在两个阶段的开发中，已经收到了大量的反馈信息，其中不乏对于bug的反馈。
另外，成熟的文档也必不可少，我们分别针对前端、后端、用户写了三份详细的文档，保证了后续接手的开发人员和维护人员可以快速上手。
五、心得体会
一学期的软件工程课收获满满。软件工程课就应该在做中学、学中做。团队项目中，我从一个开发小白的身份在alpha开发阶段一点点摸爬滚打，从我们的前PM大佬学到了很多开发技术、项目管理方法。进入beta阶段后，我有幸接替原PM大佬的工作成为PM，和团队成员一起不断完善我们的产品。PM的经历让我实践了更多软件工程领域的学问，我学会了如何与人沟通、如何分配任务、如何督促监管任务的执行、如何与团队合作等等。看着我们的产品从无到有再到基本健全、收到用户的积极反馈，真的是一件无比享受且欣慰的过程。我会珍惜这次软件开发经历、珍惜一起结对编程的小伙伴、珍惜在北航度过的软件工程时光～
2020.6.14 补充：最近中国若干高校被封锁了matlab软件，引起了国内社会的不小争议。我觉得类似Matlab这种重要的科研软件，我国需要投入人力和资金进行研发，对于这类大体量软件的开发，软件工程理论的指导不可或缺，国内的各大高校计算机专业和软件专业应该更加重视软件工程课程的质量，培养更多优秀的软件工程技术人员。
