提问回顾与个人总结

提问回顾与个人总结

项目	内容
这个作业属于哪个课程	2021春季软件工程（罗杰 任健）
这个作业的要求在哪里	提问回顾与个人总结
我在这个课程的目标是	初步掌握软件开发技术
这个作业在哪个具体方面帮到我	对本学期软件工程的学习经历进行思考与总结
提问博客	个人阅读作业2

提问与思考

注：斜体字为提问博客中的问题

Q1：结对编程中如何选择搭档

我认为结对编程中搭档的选择很重要，那么选择与自己能力互补的搭档比较好还是与自己能力相近的搭档比较好？

在结对编程中，因为有随时的复审和交流，程序各方面的质量取决于一对程序员中各方面水平较高的一位。（《构建之法》 4.5.2）

在提问博客中我分析了能力互补的搭档和能力相近的搭档分别的优缺点，在结对编程的实践中我认为我的搭档是与我能力互补的。我的代码风格不是很好，而我的队友在这一方面做得非常出色，所以在一开始我的队友花费了很大的功夫帮我改代码风格，为了之后的作业可以顺利进行，我会学习队友的代码风格并且努力向他的代码风格靠拢。我的队友在一些算法设计上会有瑕疵，我在看他的代码时会给他提出一些改进建议。

虽然没有机会体验与能力相近的搭档一起结对编程，但是我对这个问题已经有了一些新的看法。与自己能力相近的搭档合作，大家磨合起来会比较顺利，但是只能达到两个人擅长的方面做得更好，不擅长的方面并不会有改进；与自己能力互补的搭档合作，前期磨合需要花费很大的精力，但是两个人可以互相修正对方的不足，减少项目的短板，同时两个人可以互相学习，对个人提升帮助很大。

因此，我觉得，如果是一个短期的、要求效率的结对项目，和与自己能力相近的搭档在一起合作可以很快的默契起来完成项目；如果项目时间比较充分，那么和与自己能力互补的搭档在一起可以提高项目的质量，并且对自己也有一定的提升。

Q2：敏捷团队中的测试人员的作用

了解到在敏捷团队中，队员的工作内容与传统团队有较大的不同，书中对Scrum Master和开发人员介绍得很详细，所以我对测试人员的工作还有一些疑问。

以前规格说明书由PM来写，测试由测试人员来做，现在每个人都全面负责，自己搞定规格说明书，和别人沟通，同时自己搞定测试。（《构建之法》 6.3）

有敏捷专家建议测试人员可以担负起产品负责人的部分责任，同时掌握验收测试流程，对产品的最终质量负责。（《构建之法》 6.2）

从这两段话，可以看出在敏捷开发中测试人员主要工作是在冲刺验收期，那么在敏捷开发的初期和中期，测试人员需要做哪些工作？敏捷团队中的测试人员与传统团队中的测试人员有什么区别？

在我们的团队中，没有专门的测试人员，而是由后端开发人员同时编写，并且我们团队的开发模式是一边开发一边测试和修改，而不是像传统团队开发后期由测试人员进行测试。这样做一个是可以投入更多的人员在开发上，而开发人员对代码更加熟悉，更容易编写测试代码，这样可以提高整个流程的效率，更加能体现敏捷开发的要求；另一个是在开发中可以及时纠正错误，减小了因为错误对前后端对接以及与该功能有关的其他功能模块的影响，也避免了错误堆积造成修复难度过高等情况。所以，在敏捷开发中开发人员搞定测试也是比较合理的。

Q3：如何平衡软件产品的利益相关者之间的矛盾

在《构建之法》8.2中介绍了很多软件的利益相关方，每一方提出的需求和意见很有可能是有冲突的，书中并没详细说明如何平衡这些冲突。例如，客户的需求是便宜好用的软件，系统/应用集成商需要从软件中牟利，两者需求相悖。当软件需要支付较高费用时，往往会出现盗版软件、破解版软件，反过来伤害了商家的利益。

可以看出，如果不能很好平衡各方的需求反而会对各方利益造成损害，那么应该如何平衡各方需求的尺度，减少类似这种事件的发生呢？或者说，这种平衡应该视具体情况而定，那么是否有一些需要遵循的标准呢？

有关这一点，在本学期的课程中并未涉及到，所以没有新的思考。不过，在团队项目中出现过需求多而时间少的冲突，我们团队面对这样的冲突是按照功能的重要程度先做重要的功能，后期时间不足的情况下会舍弃一些重要程度低的功能。我们对重要程度的定义是用户越想要看到的功能优先级越高，对用户体验感影响越小的功能优先级越低。但是，在真实场景中肯定不能这么随意地删减功能，那么遇到这种情况的解决方法可能只有PM尽力与甲方沟通和加班了。

Q4：“小强地狱”这种按照小强的数量判断是否需要修复bug的评判标准是否合理

我们都是按优先级来进行的，开发新功能的优先级远大于修复小强的。

如果开发人员的小强（Bug）数量超过一规定值，则此君被送入“小强地狱”，在地狱中，他唯一能按做的就是修复小强，直到小强数量低于此阈值。（《构建之法》 11.5.5）

可以看出，“小强地狱”的唯一评判标准是小强的数量。我的理解是，数量不能成为判定是否必要修复小强的唯一标准，有一些bug会影响产品的总体运行，比如导致测试人员不能测试一些相关的技术点，或是对其他人的开发流程产生影响，比如在思路、数据上对他人有误导，我认为这些bug即使数量很少，也需要立即修复，否则会影响团队中其他成员的进度。一些bug不会导致严重的连锁反应，可以考虑积攒起来，用一段时间集中修复，避免在修复bug和开发新功能之间来回横跳，提高效率。

我们的团队开发并没有使用”小强地狱“这种规则，不过在团队开发中的经历让我并不认同书中”开发新功能的优先级远大于修复小强的“这句话。我们在开发中由于时间比较紧张，所以有一个bug因为对现有开发没有造成影响所以没有及时修复，而是带着这个bug继续开发，结果之后的功能暴露了这个bug，当我们再想去修复这个bug的时候，发现修复难度和工作量都比刚开始大很多。

由此看来，一些bug并不适宜积攒起来集中修复，“小强地狱”这种规则还是比较生硬的，单纯凭借数量判断开发人员是否需要修复bug很容易将那些对之后开发产生影响的bug漏掉，反而影响进度，虽然敏捷开发强调开发的效率，但是从保证项目质量的角度来说，我并不认为开发新功能的优先级远大于修复小强的。

Q5：公司的短期实习生应该怎么培养

在项目开始之前, 有很多队员还没有接触过编程语言（例如C#），导致PM在分配任务时很难用时间来衡量，就拿写一个Web Service这一模块来说，一个熟练的程序员可能只需要两个小时，而对于初学者来说，就得先花两天来理解Web Service的实现机制和原理。在有限时间的催促下，导致一些紧急的任务不断向高手集中，而初学者的任务越来越少。这时应该怎么办？ （《构建之法》 11.6）

IT行业是一个强调效率的行业，像假期这种短期的实习生，既不能让其像老员工那样高效的完成任务，花精力培养也不能给公司带来什么效益就实习结束了，所以短期实习生的处境挺尴尬的。也有很多公司干脆不提供短期实习，实习时长至少都是3个月、6个月，平时课业繁重的同学可能只有大四才有机会实习。那么有什么方法可以让公司愿意花精力培养这种短期实习生呢？

通过团队项目以及中间的转会，发现大家学习和上手一个项目的速度都很快，在实习中应该也可以快速上手项目。有关这种短期实习的问题确实比较矛盾，我们能做的就是在平时多找机会锻炼自己，面试前好好准备，在面试时展现出自己的能力，让企业认为你有为他们创造价值的能力。

新的问题：转会后如何快速上手？

在alpha和beta之间有个转会，虽然我没有经历转会，但是我想知道转会后如何快速融入一个新的组，快速看懂这个组之前的庞大的代码，以及快速学习和适应他们的代码风格？

知识点学习

需求阶段

需求阶段学习用NABCD方法来分析需求。

需求分析对于没有经验的新手来说会比较抽象，往往只会考虑到分析Need这个角度，导致分析并不全面。NABCD法给我们了很好的指导方向，让我们从需求、做法、好处、竞争、交付五个角度来进行需求分析，我们可以更加全面的了解和分析自己的产品。

设计阶段

设计阶段需要产生详尽的设计文档。我们队产生了功能规格说明书、技术规格说明书、数据库设计文档和原型图等。通过参与这些设计文档的编写，知道了设计阶段需要进行哪些工作，如何进行设计工作为之后的开发提高效率。

实现阶段

• 技术上，React前端框架，Typescript语言等前端技术。

• 工具上，比如用swagger管理接口，CI/CD实现自动化测试，ESlint_fix自动修复代码风格等，采用husky设置GitHook，实现每次commit时自动进行代码格式的检查和修复。

• 团队合作上，学会了与前端负责人沟通，与PM沟通，与后端对接接口。

测试阶段

前端可以从不同浏览器内核及版本角度进行测试，后端可以进行单元测试，这两个可以在开发过程中边开发边测试边修改。对于整个产品进行压力测试、场景测试等。

发布阶段

• 为了更能体现产品的价值，以及获得更加有针对性的用户反馈，产品的发布和推广应该更加面对该产品的目标人群。

• 使用好的方式对产品进行宣传可以达到事半功倍的效果，我们组做了对产品进行介绍的宣传主页，还有一些组做了宣传视频、宣传推送等，这些都是非常值得学习的宣传方式。

维护阶段

维护阶段已经经历过测试阶段，产品已经没有明显的bug，这时候应该针对发布后的用户反馈以及实际运营情况对产品进行维护。这就需要设计用户反馈的渠道以及监测产品使用情况的方法。我们在产品中提供了用户反馈功能，并且建立了用户反馈群，软件监测方面使用定时器方法来监测活跃用户数。

个人总结

个人项目

个人项目主要是完成了个人阅读作业和案例分析作业。通过个人阅读作业#1，阅读了很多IT人的博客，体会他们的经历与思考，让我对计算机这个专业，以及北航带给我的教育都有了新的认识和思考。通过个人阅读作业#2，我对敏捷开发有了细致的了解，其中学习到的许多理论知识在之后的结对编程和团队项目中都对我起到了很大的帮助。同时，这次作业还引导我们练习CI/CD的使用，CI/CD也成为之后两个项目中得力的工具。案例分析作业指导我从产品功能、市场等多个角度对产品进行分析，这也是我第一次深入且全面地对于产品进行评测、调研产品的背景以及市场情况，也为之后的团队项目的产品的需求分析以及功能设计提供了思路。

结对编程

结对编程让我体验了全新的驾驶员-领航员的开发模式，我和我的队友ljj的技能点差异挺大的，通过不断的磨合慢慢找到了我们配合的方式。我也通过结对编程改变了一些我一直存在的问题，我的代码风格一直比较随意，以前个人编程时不太能体现弊端，但是结对编程时我发现我这种随意的风格给我的队友带来了很大的困难，给我们的代码整合以及迭代工作带来了很大的麻烦，我意识到这个问题后及时与队友沟通，在队友的指导和帮助下我努力将我的代码风格改为比较规范的形式。同时我也从我队友的身上学到了许多，让我感触最深的是有一次我们始终找不到弱测的bug，当时已经临近ddl，我已经是近乎放弃的心态了，但是是我队友的坚持让我们最终找出了bug，通过了弱测，这让我很受鼓舞。

团队项目

团队项目让我体验了比较完整的需求分析、设计、实现、测试、发布、维护的产品实现流程，通过整个团队的合作与努力，我们实现了一个很有意义的项目—— 观隅数据集可视化平台，我觉得非常有成就感。在团队项目开发阶段，我遇到了很多困难，比如没有时间上手技术栈，只能硬着头皮一边做一边学；冲刺阶段撞上考期，两边无法同时兼顾……但是我的队友都非常nice！前端大佬lyl非常耐心的帮我debug，解答我的问题；PM允许我在考期那几天减小工作量，考试结束后再补回。感谢我的队友，让我圆满完成团队项目的开发，也让我感受到我们谜语人队的团结与包容。