提问回顾与个人总结
Author: 17373015 乔玺华
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 2020春季计算机学院软件工程(罗杰 任健) |
| 这个作业的要求在哪里 | 提问回顾与个人总结 |
| 我在这个课程的目标是 | 学习软件工程的开发知识，初步具备多人开发软件的能力 |
| 这个作业在哪个具体方面帮助我实现目标 | 分析自己目前的需求以及对未来的展望，还有对过去的反思 |
| 提问博客链接 | BUAA 2020 软件工程 个人博客作业 |
目录
- BUAA 2020 软件工程 提问回顾与个人总结
一、对自己提问的回答
问题一
Q1：单元测试必须由程序的作者本人来编写吗？
《构建之法》在2.1.2节中提及
单元测试必须由最熟悉代码的人（程序的作者）来写
我承认这个观点存在优越性，代码作者必然是最了解代码各部分的功能实现，了解每一行代码的目的和局限性，而且单元测试有时候需要开发对代码进行部分重构才方便进行，开发自己做这些重构也比较顺手。
- 但同时我认为开发工程师自己编写单元测试存在一下几个弊端：
- 大部分的开发人员缺少优秀的测试思想，单元测试很有可能只是十分简单的测试样例，能够通过单元测试发现bug的几率极低，这样的单元测试更加倾向于形式而不具有实际价值。
- 开发人员有可能在编写程序的时候，就对某个知识点存在错误的认知，这也会导致他在编写单元测试时仍然带者错误认识，即无法编写出能够发现该错误的单元测试
- 开发人员写业务代码的时间就已经十分紧迫，缺少足够的编写优秀的单元测试的时间。
- 组内测试人员为开发人员编写单元测试存在以下优势：
- 测试人员编写的单元测试能够保证用力的覆盖和全面性，拥有丰富的测试经验以及发现漏洞的敏锐能力
- 编写单元测试能够帮助测试人员更加了解具体代码的架构、流程等，为日后的测试打下良好的基础。
单元测试确实应该由最熟悉代码的人来编写，只有代码的编写者才知道自己代码段内的各个环节，以及测试的时候应该对哪些部分进行严格测试，单元测试相对于测试人员进行的产品测试来说，更倾向于是一个门槛测试，只是为了简简单单对产品进行一下测试，查看是否有一些十分明显，甚至不需要给测试人员测试就能发现的bug，这样的测试可以极大的减少由于开发人员自身的某些失误或粗心导致的bug数量，算是对自己代码的一个检验，目的并不是为了消除代码中的全部bug，而是为了对自己进行一下检验，让自己有一定的信心能够把代码给测试人员进行测试。
问题二
Q2：结对编程中两人的角色是否需要不停的轮换？
《构建之法》4.5.4节中提及
- 驾驶员和领航员不断轮换角色，不要连续工作超过一小时，每工作一小时休息15分钟，领航员要控制时间。
在赛车越野比赛中，并没有出现过领航员与赛车手不断轮换的情况，这是因为赛车手擅长驾驶汽车，而领航员擅长分析比赛路线以及周围情况，做出准确及时的判断，在结对编程中，我认为亦然。只有当结对编程双方能力相近，擅长领域相似的时候，才存在轮换的可能性，而在大多数情况下，必然是一人水平高出另一人，且两人必然擅长各自擅长的领域而没有太大的交际，驾驶员-领航员模式下，若是让水平较低的一方担任领航员，很有可能最终的结果是水平较高的乙方分饰两角，而水平较低的一方只能干坐，被动的接受。这种情况对于编程效率的提高没有任何帮助。
保持原有想法不改变，结对编程时，两个人的角色并不需要太多的互换，虽然是两个人，但也是一个团队，在进行工作时，完成自己相对擅长的工作，远比定期轮换，要学习新知识，做自己没有接触过或是不擅长的工作来的更加高效。工作进行到一半，角色的互换往往会带来小组工作效率的下降，若有一人对于目前的工作产生了困难，可能还需要咨询另一名队员，而此时不仅会导致个人效率的降低，同时拉低了队友的效率，造成恶性循环。这样的作法或许对个人的提升极为明显，毕竟四舍五入每个人都接触了结对编程工作的几乎全部内容，但软件开发，更甚者敏捷开发讲究的是高效，迅速，更倾向于工业上以做出成品为第一目标，因此我还是偏向结对过程中，保持个人角色，有始有终。
问题三
Q3：敏捷开发是否需要优质的开发文档撰写？
我通读了《构建之法》第六章敏捷流程，其中的敏捷开发给我留下了深刻印象，敏捷开发讲究的就是高速和高效，每日都开例会（立会），但这一切似乎都是口头一些讲述，似乎并没有提及开发文档的撰写，是敏捷开发为了追求速度的效率，跳过了开发文档的撰写，还是说敏捷开发有一套专属的开发文档撰写方法？如果确实有，那么老师可不可以大致描述一下敏捷开发的开发文档与平时的开放文档有什么区别？若是没有，那么是不是该考虑增加开发文档的撰写，因为一旦有紧急情况发生，原来开发小组的人员出现了缺失，需要新鲜血液补充时，新来人员可能需要一份书面的文档才能更好的了解项目内容，项目进度等，而口头的描述可能会出现遗漏或口误，导致不必要的麻烦。
很有幸，我们组在进行随机人员转会时，我成为了随机数选中的那个人，因此也亲身经历了离开熟悉的团队，参与到另一个完全陌生的团队项目中，由于当时选团队的时候进行了慎重的考虑，第二个团队的任务在beta阶段刚好和原团队类似，都是前端APP的开发，恰好是我熟悉的工作，并且由团队PM给我进行了简单的讲解，目前的团队状况还有进展等，并没有花费太多的时间，我就迅速地开始展开工作了，同样没有阅读以往文档，敏捷开发，注重的就是速度和质量，精美的开发文档可以等到开发结束后进行编写，在开发阶段，就应该全心全意投入到开发中。
问题四
Q4：PM是否需要具有很强的项目相关的专业能力吗？
在阅读了《构建之法》9.5中PM的能力要求与任务后，我注意到作者提及
一个合格的PM，需要..
- 一定的专业能力
个人认为作为项目经理，不仅需要极强的沟通能力，必然需要能够了解项目全貌以及其中大致的实现方式的能力，PM个人需要有过编写项目的经历，如果项目相关的专业能力不够，如何在紧要关头判断出优先级，做出正确的判断；同时项目经理需要知道各种技术的实现难度以及是否能够实现，这样在与客户交谈的过程中，才能够进行有效的交涉，为客户提供令人满意的服务，同时也不会为项目组接来某种极其困难或是根本无法实现的项目功能，合理根据工作量进行分工协作，领导团队的人必然需要有一个全面的知识储备，具体的实现细节或许并不需要太过清楚，但大致思路需要个人有所了解。而书中并没有提及项目相关的专业能力，而仅仅是泛泛而谈了一下
PM的专业就是理解和表达
我认为PM确实需要很强的专业能力，我经历了两个项目的小组，每个小组的PM都实际或多或少的参与到了生产工作中，或许代码产量并不是特别高，但也都利用他们的专业知识，对于整个开发过程做出了不可缺少的贡献，或许他们不用亲自写代码，但他们可以做到对一些问题的评估，在作决策的时候提出自己的专业性意见，并且可以完成代码的review工作。或许这是因为这样的软工团队还不够成熟，在现实工作环境里，可能PM并不需要太多的专业性知识，而是仅仅完成开发与甲方之间的交流、协调。
这样的回答是经历了一个学期的软件开发工程后，在实战以后才能得出的经验，“纸上得来终觉浅，绝知此事要躬行”，这样的诗句不无道理。
二、还不明白的问题
Q5：代码覆盖率测试是否具有实际意义？
《构建之法》13.2.2节中提及
100%的代码被执行了，是不是意味着再也不用写新的测试用例了呢？
答案是否定的。
若是代码覆盖率测试结果无论高低，都需要进行后续的测试，那么为什么要进行代码覆盖率测试呢？我在网上进行搜索后，得到的反馈并不能说服我，如是用来发现没有被测试覆盖的代码，但在构建测试代码阶段必然会针对每个区域进行测试，又何来没有被测试覆盖的区域一说；代码覆盖率可以作为测试自我审视的重要工具之一，但这样的说辞并没有太大实际价值，并且对于后续的测试也不会有实质性的帮助，甚至代码覆盖率高存在让测试人员提前满足的可能性，导致之后的测试被弱化，岂不是得不偿失。
我仍然无法理解代码覆盖率的意义，经过一学期的开发，代码覆盖率对于我们的开发工作而言，形式大于意义，仅仅是一个百分数，在实际开发工作中起不到太多的实际作用，测试的时候都会根据个人的理解进行全面的测试，然后在测试完毕后，为了代码覆盖率达到一定的高度，而去修改自己的测试代码，感觉有一些形式主义，或许是还有一些实际的意义，只是我们开发时间太短、开发项目过简单，导致无法发现，我也期待在以后的开发过程中，能够逐渐理解代码覆盖率的价值。
三、学到的新知识
- 需求
需求方面，可以使用投票网站，找一部分的目标用户群体进行投票，选择优先开发的需求
- 设计
建议先使用某些专业软件绘制出一个大致的demo，这样的在实现过程中，远比个人全靠空想进行布局来的更加高效
- 实现
首先需要对实现方法有个大致了解，即搭建基本框架，细节部分可以慢慢琢磨，但大框架需要在最开始就有一个正确的认识。
- 测试
许多编译器都有一些插件支持代码的测试功能。
- 发布
发布阶段，需要内容足够吸引潜在用户打开链接，进行下载，可以使用文字+图片的方式，吸引用户。
- 维护阶段
维护阶段，在APP内部开设bug报告渠道，及时与用户进行联系，对于bug产生的现场进行还原，尽最大可能迅速修复。
四、心得理解
要说感触最深的，应该就是团队开发阶段，因为我们团队真的有一个很优秀的PM，所以我们的项目被很好的分割成了每一天的大小，每天完成项目的一部分，我很享受每天中午开例会，汇报前一天的工作情况，并且对于自己接下来一天的工作进行一个大致的估计，也很感谢团队的组员，大家都很努力，都会尽可能的及时完成自己的任务，在组员遇到困难时，也都会伸出援助之手，对内氛围十分融洽，这样的经历也让我有了一个深刻的感受，团队合作的力量终究是能够超过个人的，一个团队或许队内组员并不都是大佬，但只要分工明确，努力的结果将会不亚于，甚至可以超过大佬的团队，我也是第一次认识到团队的力量真的可以做到很多，之前可能难以想象的事情。