个人作业3-提问回顾与个人总结

个人作业-提问回顾与个人总结

项目	内容
这个作业属于哪个课程	2023年春季软件工程（罗杰 任健）
这个作业的要求在哪里	个人作业-提问总结与个人总结
我在这个课程的目标是	学习软件工程方法，提升解决复杂工程问题的能力
这个作业在哪个具体方面帮助我实现目标	回答开学时阅读书本提出的问题，回顾结对、团队项目开发
阅读与提问作业博客链接	软件工程第一次作业-阅读与提问

提问回顾

在开学阅读教材时，主要有针对性地提出了五个问题。现在，在经历了结对编程、Alpha版本开发、Beta版本迭代后，我对敏捷软件工程有了更加深入的认识，所以，在此对此前提出的一些问题进行解答，无新问题的提出。

问题一：概论章节

说到商用软件和爱好者写的程序的区别，我们还可以看看这个例子：如果一架民用飞机上有一个功能，用户使用它的概率是百万分之一，你还要做这个功能么？你会选择： 根本不考虑 如果没时间实现这个功能就算了 做了，但是不用告诉用户 做了，而且不厌其烦地告诉用户如何使用 谜底是飞机的安全功能乘坐飞机时，你会看到乘务人员不厌其烦地给你介绍飞机有几个出口，如果氧气罩自动掉下来，应该怎么做。你身下的坐垫是可以漂浮的，飞机还可以在水面上降落，逃离飞机的时候应该怎么跳到气垫上……

问题

在软件中，虽然也存在类似的微小漏洞造成极大损失的案例发生，我的疑惑在于书中的说法是不是有些过于极端了？对于安全性的问题，我们自然是需要不遗余力地开发并介绍给用户。但是对于其他使用率低且可有可无的问题，我认为，我们可能还是需要根据时间安排进行开发，例如在后续的软件版本上加上这部分功能。

解答

安全性的问题自然是需要毫无遗力地解决的。对于其他的功能，这样开发并宣传的行为是很好的捕捉了用户的心态，有时甚至会成为“杀手级”功能，用户在购买商品、使用同类软件前会看一些介绍，虽然他们确实很难用到一些功能，但却会产生一种“这个功能多，就要这个”的心态。在我们的团队任务中，似乎没有这样使用概率很小的功能，所以我下面用华为手机来举例。在当下移动基站几乎全覆盖的情况下，华为手机的卫星通信似乎显得有些鸡肋，普通人使用到的概率并不大，但是却成为了区分华为和其他品牌手机的一个关键因素。综上所述，开发并宣传使用概率很低的功能是十分有现实意义的，在网络时代，大样本下总能够有使用者接触到该功能，一条赞美的微博、朋友圈就可能让产品成功“出圈”。

问题二：软件工程师的成长

那怎么提高技能呢？答案很简单，通过不断的练习，把那些低层次的问题都解决了，变成不用经过大脑的自动操作，然后才有时间和脑力来解决较高层次的问题。

年轻学生都志向远大，上了一些课，就很想解决高层次的问题。一些学生非常想做高层次的“科研”，觉得“工程”是基础，没意思。而且他们认为“我已经知道怎么做了”。

问题：

我的疑惑在于如何划分高层次问题和低层次问题，我们该以什么标准去衡量高层次问题和低层次问题呢？例如对于高年级学生来说，算法是高层次问题，代数、积分计算是低层次问题；但是对于低年级学生来说，数学分析、线性代数才是他们眼中的高层次问题。

书中后面的一句话中，将“工程”问题看作是基础，也即是低层次问题。但是根据自身的经验和观察来说，学生似乎更执拗于编程等工程性问题，认为理论才是工程的基础。我的疑惑在于学生当下的这种观点是否与书中所说相悖呢？

解答：

高层次和低层次的问题并没有严格的划分，因人而异。对于我们的团队开发，我们在不同的阶段会将任务当作是不同的层次。例如Alpha版本我们为如何实现容器的资源监控绞尽脑汁，但是到Beta版本中，对于容器的了解更加深入，这个问题很快就迎刃而解了。所以，衡量高层次和低层次的问题还是取决于个人的能力和经验。

并不相悖。在软件工程课程中，我们学习的开发模式、测试方法就是我们团队任务的基础，这是理论与工程的关系。而对于工程和科研来说，如果没有工程能力、没有开发软件的能力和经验，又何谈更高层次的“科研”。

问题三：结对编程

如何结对编程：

• 驾驶员：写设计文档，进行编码和单元测试等XP开发流程。

• 领航员：审阅驾驶员的文档、驾驶员对编码等开发流程的执行；考虑单元测试的覆盖率；思考是否需要和如何重构；帮助驾驶员解决具体的技术问题。

• 驾驶员和领航员不断轮换角色，不要连续工作超过一小时，每工作一小时休息15分钟。领航员要控制时间。

问题：

如赛车一样，驾驶员和领航员都是要到达同一个目标，在旅途中承担着不同的职责。我的疑惑是，结对编程中的角色交换是否会存在一个交接过度期，导致工作效率的降低呢？例如汽车行驶中途更换驾驶员，需要找到合适的地方停下来，然后新的驾驶员需要时间去知道现在在哪、接下来该往哪边走、汽车的油量等，一通操作下来几分钟就过去。

文章前面提到领航员是要实时“跟踪”驾驶员的行为，是对我上面的问题的一个回复。但是，我又产生新的疑惑，轮换角色的根本原因是要避免“驾驶员”观察力和判断力的下降，让他们得到休息，但是“领航员”的工作真的能让他们如愿休息吗？

解答：

在结对编程中，交替性地担任担任者和审阅者是有助于提升编程效率的。对于传统的单人开发模式来说，在完成自己的任务后，可能还需要成倍的时间去与小伙伴交接以完成组队任务，尤其是在API的设计、测试等部分，并不是凭一己之力能够完成的。而结对编程就很好的改善了这一点，开发者始终处于开发或审阅工作中，可以全方位地了解到开发进度和接口的设计，有效避免开发完成后漫长的对接调试时间。所以，虽然结对“轮换”制虽然并不能让领航员得到充分的休息，但是当赛车（开发过程）到达终点后，驾驶员和领航员都可以快速对车辆（程序）进行维护。

问题四：敏捷流程

每日例会：

如果流于形式，无论多么敏捷的每日立会也会被忽悠。一个改进是，定义好任务究竟是什么？任务的完成（Done）到底意味着什么？每个人的任务必须是明确定义的，狗熊们不能笼统地说“我在掰棒子”，而是要说明标号为123的棒子现在是什么状态，你做好之后交给谁了。另一个改进是，要在每一个任务中记载我们完成这个任务还需要多少时间。已经花了多少时间虽然重要，但那不是关键（那是沉没成本），关键是要看我们离最后目标有多远。

有三个每天跟踪的时间值：

• 实际剩余时间（Remaining Hour）：每个团队成员所有任务的剩余时间的总和。

• 预估剩余时间（Projected Remaining Hour）：根据每个人每天的理论进度推算的剩余时间。

• 实际花费时间（Completed Hour）：实际花费的时间。

问题：

我的疑惑在于，如何去计算预估剩余时间，也即是如何知道我们离最后目标有多远？我在查找资料后看到了任务拆分、合理认知时间、预留buffer、回头看等方法步骤。

但是开发过程中不可避免的会遇到一些问题，出现bug，有时可能需要花费很多时间去解决他们，当出现这样的delay，我们该如何预估呢，这又会对我们的进度产生怎么样的影响呢？我联想到了“虚假的进度条”，刚开始很快，然后就卡在后面动弹不得，给用户很不好的体验。所以我认为评估开发时间是一个重点也是难点，因为软件开发中的一个环节延期了，可能会导致后面的各个环节都要顺延，造成损失。

结对：

在实际的团队开发工作中，预估开发进度确实是需要很多的开发经验。在Alpha版本中，确实是因为一些Bug和服务器的问题导致了开发偏离了预估的进度。但是在Beta版本中这一问题就得到很大程度的缓解，我们在预估进度时就会充分考虑特定部分可能会出现的问题和期望解决时间，以此平衡修复bug对开发进度的影响。总而言之，随着开发的进行，开发者会对敏捷软工的模式有更加深入的认识，在经验的帮助下可以很好的预估开发时间。

问题5:需求分析

做过头了会怎样？我们有这么多各式各样的工具，互联网给我们带来了用户和数据，这是好事，但也会有副作用。世界上能访问用户数据，并根据数据做分析和改进的公司，大概Google是其中翘楚，这种以数据为中心的做法做过了头，也有悲剧发生。道格拉斯·鲍曼曾担任Google的视觉设计主管，2009年的一天，他受不了了：

Yes, it's true that a team at Google couldn't decide between two blues, so they're testing41 shades between each blue to see which one performs better. I had a recent debate over whether a border should be 3,4, or5 pixels wide, and was asked to prove my case. I can't operate in an environment like that. I've grown tired of debating such minuscule design decisions...

当公司要求你用数据来证明41种蓝色到底哪一种更好，或者为一条边框宽度是3、4或5个像素而争执不休，纷纷表示要拿数据来证明时，你怎么办？

问题：

我的疑惑在于，有必要对软件中颜色等微小细节，进行数据分析吗？Google的员工不会意识到他们的争论是“愚蠢却有趣”的吗？同时，在结对、团队工作中，我们的队友往往来自相同专业，有着相同的思维方式，如果也在类似的问题中出现了争议、辩论，我们又该如何避免Google的矛盾，以一种合理的方式解决问题呢？例如，计算机专业的学生就热衷于将问题逻辑化，用数据说话，颜色好不好看我们就去分析用户的评价数据，这样就很容易产生文中Google的哭笑不得的故事。

解答：

而对于软件中的微小细节，做数据分析是十分有必要的。在大型软件中都会有严格的A/B测试，以保证从科学可论证的角度证明其有效性。例如颜色这样与用户体验息息相关的问题，一部分用户的反感就足以产生巨大的损失。所以，这样“斤斤计较”的争论虽然令人苦笑不得，但是，这是开发者负责人的表现。在实际开发中，由于软件规模、开发团队人数、开发时间的限制，其实也没有出现这一类的争论。

“做中学”

需求阶段

学习到了如何寻找潜在的用户并与之交流，理解用户需求，并确定关键功能以及各个功能的优先级，方便后续确定开发进度。此外，还学会了如何分析同类型的软件产品，并确定我们的“杀手级”功能。

设计阶段

主要学习了软件架构的设计。包括软件前后端的组成部分、接口定义、交互方式等，为实现阶段做好保障，保证软件的可扩展性、可维护性。

实现阶段

• 逐步掌握后端开发Django框架以及路由的配置

• 更加熟练掌握Git的使用，如merge、pr、rebase等，更加规范地进行团队开发

测试阶段

学习使用了单元测试，在结对作业中使用了Google的gtest，在团队作用了使用了Django的单元测试框架，保证了模块基本功能的正确性。但是单元测试也有局限性，覆盖率不能达到100%，有一些bug需要联调才能发现。

发布阶段

对CI/CD（Continuous Integration/Continuous Delivery）的流程有了更多的了解。CI/CD是加速软件开发和交付的实践方法，通过自动化流程和持续集成、持续交付的理念，帮助团队提高软件质量、加速交付速度。通过组内队友搭建的CI/CD，我们能够自动化地完成新版本的发布，以实现产品的快速迭代。

维护阶段

在维护阶段，主要学习到了如何根据用户的反馈快速定位和解决软件中存在的一些小bug。

此外，我对项目的可持续性有了一定的了解。在开发完成后，我们也是编写了很多开发文档、使用文档、部署文档帮助新的开发者整体了解项目的框架，以达到持续开发、交付的目标。

个人理解与心得体会

在一个学期的课程和开发任务中，我对敏捷软件开发模式有了很多自己的理解和心得体会。

• 敏捷软件开发强调团队协作和沟通能力。在Alpha和Beta版本中，团队前后召开了14次例会，相互之间及时交流，不断沟通开发进度。从个人体验来看，团队的沟通交流很大程度上提升了开发效率，相较于以前的团队编程“各做各的”的模式，有了显著的提升。高效的敏捷团队需要有明确，通过实践，对团队角色定位（前端、后端、测试、PM等）、沟通方式（飞书）、冲刺会议（飞书）和协作工具（Github）的使用有了更加深入的了解。

• 质量保证。在团队开发作业中，这确实是一项痛并快乐着的事情。一方面，在开发仓库中的PR设置自动化测试、覆盖率要求、代码风格管理很好的提高了代码和软件的质量；另一方面，PR的要求让代码很难push上去，不写单元测试不准PR。

• 迭代开发与开发进度规划。在Alpha和Beta版本的迭代开发中，逐步学习到了如何规划和管理迭代周期、冲刺和发布，亲身体会了如何设置合理的迭代目标、任务估算、追踪和调整计划。

• 单元测试！深刻意识到了单元测试的重要意义，无论是在结对编程还是团队编程任务中，单元测试都是十分重要的一部分，能够有效保证模块功能的正确性，能够避免盲目自信导致的Bug（说自己）。