软件工程第一次作业-阅读与提问

个人作业-阅读与提问

项目	内容
这个作业属于哪个课程	2023年春季软件工程（罗杰 任健）
这个作业的要求在哪里	个人作业-阅读与提问
我在这个课程的目标是	学习软件工程方法，提升解决复杂工程问题的能力
这个作业在哪个具体方面帮助我实现目标	学习书本知识，深刻理解软件工程中的思想和设计方法

阅读提问

问题一：from 概论章节 （不完全认同的观点）

说到商用软件和爱好者写的程序的区别，我们还可以看看这个例子：如果一架民用飞机上有一个功能，用户使用它的概率是百万分之一，你还要做这个功能么？你会选择：

• 根本不考虑
• 如果没时间实现这个功能就算了
• 做了，但是不用告诉用户
• 做了，而且不厌其烦地告诉用户如何使用

谜底是飞机的安全功能乘坐飞机时，你会看到乘务人员不厌其烦地给你介绍飞机有几个出口，如果氧气罩自动掉下来，应该怎么做。你身下的坐垫是可以漂浮的，飞机还可以在水面上降落，逃离飞机的时候应该怎么跳到气垫上……

在这段话中，作者举了航空安全的例子来印证其观点：如果用户使用一个功能的概率是百万分之一，也需要实现该功能并不厌其烦地告诉用户如何使用。

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

问题二：from软件工程师的成长 （疑惑）

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

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

在这段话中，作者提高了该如何提高个人技能：低层次的问题达到熟练，才会有时间去解决高层次的问题。

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

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

问题三：from 结对编程 （疑惑）

如何结对编程：

• 驾驶员：写设计文档，进行编码和单元测试等XP开发流程。
• 领航员：审阅驾驶员的文档、驾驶员对编码等开发流程的执行；考虑单元测试的覆盖率；思考是否需要和如何重构；帮助驾驶员解决具体的技术问题。
• 驾驶员和领航员不断轮换角色，不要连续工作超过一小时，每工作一小时休息15分钟。领航员要控制时间。

在这段话中，作者罗列了部分如何结对编程的方法。“驾驶员”承担主要任务，“领航员”起到建议、协助的功能，并且要在一定时间周期内进行角色的转换。

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

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

问题四：from敏捷流程 （疑惑）

每日例会：

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

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

• 实际剩余时间（Remaining Hour）：每个团队成员所有任务的剩余时间的总和。
• 预估剩余时间（Projected Remaining Hour）：根据每个人每天的理论进度推算的剩余时间。
• 实际花费时间（Completed Hour）：实际花费的时间。

在这段话中，作者提到了敏捷流程的问题和解法，通过每日例会去分配任务、协调进度、技术交流。同时为了避免“狗熊”式的流于形式的例会，作者提出了记载每个任务还需要多少时间完成。

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

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

问题5:from需求分析 （疑惑）

做过头了会怎样？我们有这么多各式各样的工具，互联网给我们带来了用户和数据，这是好事，但也会有副作用。世界上能访问用户数据，并根据数据做分析和改进的公司，大概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的矛盾，以一种合理的方式解决问题呢？例如，计算机专业的学生就热衷于将问题逻辑化，用数据说话，颜色好不好看我们就去分析用户的评价数据，这样就很容易产生文中Google的哭笑不得的故事。