[I.1] 个人作业：阅读和提问

项目	内容
这个作业属于哪个课程	北航软工
这个作业的要求在哪里	[I.1] 个人作业：阅读和提问
我在这个课程的目标是	学习如何以团队的形式开发软件，提升软件工程能力
这个作业在哪个具体方面帮助我实现目标	阅读《构建之法》，详细了解软件开发的流程

一.书中第7页的问题“如果民用飞机上有需求，用户使用概率是百万分之一...”，我认为文中飞机安全问题的类比不是很恰当。

​ 在民航系统中，飞机的安全问题关乎着人们的生命安全，我们需要搞清楚这个功能的前提，这不能仅表示为一个“用户使用概率是百万分之一的需求”，而应当表示为“用户登机的先决条件”，是因为没有人希望成为那百万分之一，它的后果是巨大的厂商才必须需要满足这个需求。放在我们的软件工程中，相似的场景应该是用户的个人信息与数据的保护，一个没有密码系统与安全保护的软件是难以让人安心使用的。对于这样极端的场景付出肯定是必要的，但是在没有先决条件时，对于一个软件的平凡的需求，厂商需要对用户的使用概率进行评估，如果需求是稀缺的，企业一定不会在通用版的软件上上线这样的服务，而是放弃该功能或是有针对的对特殊人群提供服务。
​
​ 总而言之，我认为作者对“用户使用概率是百万分之一的任务“的举例有失偏颇，这部分应当直接表述为商业软件与爱好者写的程序的区别在于商用软件面向的是广大的软件使用者，作为商业软件应当考虑到更广泛的安全性与隐私性的需求，这些是爱好者写的程序不曾考虑过的。

二.我看了第40页的问题“如果多用户使用这个系统会出现什么问题”。对此我有一个一直以来的疑惑，为什么高并发会对系统产生影响，多用户是通过什么来影响我们的软件系统的？

​ 通过查询网上资料，我了解到高并发对系统的影响本质上是多用户请求在短时间内集中争夺有限资源，导致系统在多个层级出现瓶颈。下面是一个简单的HTTP请求处理流程：用户请求 → 网络传输 → Web服务器 → 应用服务 → 数据库/缓存 → 返回结果。下面我将以该流程为例子进行分析多用户的并发请求产生的连锁压力：

1. 网络层冲击
   • 连接数过载：每个用户请求占用一个TCP连接，服务器端口数或Nginx等反向代理的worker_connections有限，超出后新连接被拒绝。
   • 带宽耗尽：若用户上传大文件或拉取视频流，网络带宽可能先于服务器CPU成为瓶颈（如直播平台突发流量）。
2. 应用层线程竞争
   • 线程池过载：Tomcat等Web服务器默认线程池约200线程，若并发用户超过此数，请求将排队等待，延迟飙升。
   • 上下文切换开销：操作系统频繁切换线程（尤其IO密集型任务），CPU时间浪费在调度而非处理业务（如CSwchs/s监控值异常高）。
3. 数据层持久化瓶颈
   • 数据库连接池耗尽：假设MySQL配置的连接池为100，高并发下所有连接被占用，新查询必须等待，引发ConnectionTimeoutException。
   • 磁盘IO争抢：即使使用SSD，密集的写日志（如订单入库）会导致IO等待队列堆积，磁盘延迟从毫级升至秒级。

三.我看了40页的这一段文字“如果系统正在使用中，如何降低软件的下线时间”，我产生了一些疑问，我记得系统的更新可以通过热补丁与冷补丁来实现，其中热补丁不需要系统下线，为什么不全部使用热补丁对系统进行更新，还是说二者的使用场景有明显不同？

经查资料我得知：热补丁和冷补丁的主要区别在于应用补丁的时间点以及对系统运行的影响。

• 热补丁 进行实时在线的更新，在应用程序还在运行的过程中安装新的补丁。热补丁通常用于关键服务或系统中，它会先备份旧的代码，然后替换掉部分或全部功能模块，最后恢复系统到新版本。因为是在运行时操作，可能会导致短时间的服务中断或者不稳定，需要精心设计以尽量减少影响。
• 冷补丁相比之下则在系统停机期间进行更新。这意味着需要先将系统下线，关闭所有相关的服务然后再安装和激活补丁这种方式不会直接影响用户服务，风险相对较低，但会导致一段时间的系统不可用。
  在一般情况下，会尽量选择热补丁来进行更新以维持系统正常允许，但是当热补丁无法解决遇到的问题时（例如不是简单的改写函数就可以的，需要改写全局变量，内存中的代码段也重新改换，代码重新汇编），就需要冷补丁来解决。冷补丁会重新更换内存中的全局变量、代码段、补丁区，而这些又不能简单的改写就运行，必须通过复位来解决。

那么面对文中的图书馆模块更新问题，是否符合热补丁的使用范围，可以通过使用热补丁来在系统不下线的情况下进行更新？

四.我看了第123页这一段文字“所谓极限编程，就是把一些认为重要和有效的做法发挥到极致”，我有一些疑问，这一部分段落标题是敏捷总结，在这里突兀的提起极限编程，二者是否是同一个概念或是相关概念？

​ 通过查询资料我得知：敏捷开发(Agile)是一种软件开发方法，它鼓励快速迭代、适应性强的规划、进化式的开发和交付以及灵活性和响应性。敏捷方法反对以文档为中心和重量级的开发流程，转而侧重于代码及用户协作。而极限编程(XP)则是对敏捷开发方法论的具体实践，它特别强调技术实践，以提高软件开发质量和生产力。除极限编程以外，敏捷开发还具有许多方法论，例如：FDD、Scrum与Kanban。
​ 这些方法论同属敏捷开发的思想，它们之间的区别主要体现在哪里？

五.书中第212页提到这一段文字“PM的M就是Manager，但是P有这几种：Product Manager、Project Manager，Program Manager(微软专称)在不同的行业与公司他们的作用各不相同”，产生了以下问题，在国内的计算机大厂中。例如：腾讯，阿里 他们的这些PM的工作任务是什么？

我查询了资料，在腾讯PM(Project Manager)的个人自述中提到：

​ PM，是Project Manager的缩写，也就是项目管理的意思。项目管理的主要负责人就是项目经理、项目主管，作为项目的管理者，PM通常会参与到一个或多个项目的管理与决策工作中。主要工作要求即在有限的资源约束下，运用系统的观点、方法和理论，对项目涉及的全部工作进行有效地管理。PM项目经理作为项目团队的领导者，主要的作用就是需要带领项目团队实现项目目标；项目经理尤其是IT行业的项目经理，往往都是从技术转型，所以很多时候项目经理本身的技术思维与片面的认知，会给项目带来潜在的风险。

​ 与书中微软的PM(Program Manager)相比，腾讯的PM是从技术岗位发展而来，不同的是，腾讯的PM会远离具体的技术工作，其主要任务是与客户进行项目对接以及带领项目团队实现项目目标，在这一点上与微软大有不同。在二者差异的对比下，腾讯的PM模式与微软的PM模式哪一个更有利于企业软件的完成？

六.书中第244页提到了“每日构建”，我产生了以下问题，”每日构建“中的”构建“一词指的是什么，是编写软件功能还是成功运行软件，以及为什么构建会有失败的情况？

我查询了资料，每日构建有如下定义：

​ Daily build 就是把一个软件项目的所有的最新的代码从配置库中取出,然后从头进行编译,链接和运行。更甚者可以再运行测试包对软件的主要功能进行测试，发现并报告错误的整个过程。通常由工具自动完成。Daily build 一般是在每日下班后半夜进行，前提是员工check in 最新的code到配置库中。所以可以把Daily build 戏称为 nightly build。然后在第二天上班时分析build 的log，找出error并mail给所属模块负责人，敦促解决（如果这一步能自动完成就更完美了）。按照上面的解释，Daily build 译为“每日构建”，是很合适的。但Daily build 的另一个重要功能就是验证软件中各模块关系是否正确，也可称为“每日集成”。

​ 在我的实践中，我的构建问题一般是由环境与配置问题引起，但是我还是不太清楚在真正的软件工程中每日构建的失败可能是由什么原因导致的呢？一般环境配置完成之后就不会产生相关问题了，那么为什么每日构建会产生问题呢？

七.书中第316页提到“测试的角色需要独立出来吗”的问题，我产生了以下问题，QA与Test在前文中提到了二者有很大不同，后面书中也提到“软件团队中应该有独立的测试角色。所有人都可以参与QA的工作(报告 Bug什么的)，但是最后要有一个角色对QA这件事负责”。这里的测试与QA是否重合，或者二者负责人是否指的是同一个人，我觉得这里讲的有点模糊，也没有交代QA与Test的根本区别。

因此我查询了资料，在岗位任务上：

​ 软件测试（software testing）就是我们最常见的测试岗位，工作职责是根据客户对软件产品的要求，对软件功能、性能、稳定性、安全性、易用性等进行测试，通过明确测试规范，编写测试用例，使用测试工具等方法，发现软件存在的缺陷，并反馈给开发人员完成修改，以确保软件产品能够正常运行，从而符合客户的要求。

​ QA （Quality Assurance）即质量保证，从软件过程和工作方法的角度来帮助项目确保质量。QA工程师从立项开始就会进入到项目组，通过开展质量控制和保证活动，在项目执行过程中尽早发现软件生命周期过程中的薄弱环节及其相关工作产品存在的问题，QA工程师可以通过分析项目常见的风险和问题，总结出通用的优秀实践和工作方法，形成组织级工作流程规范，使项目成功与否更加整体系统化，不会因为个人因素影响项目的进度！

而在国内公司中，各个组织对于QA和软件测试的定义不尽相同，大概分为三类：

• 大部分公司，QA=软件测试

• 少部分公司，QA>软件测试，除了测试以外还负责流程改进等工作

• 极少部分公司，既有QA，也有软件测试。QA负责流程，产品等方面的工作，软件测试则仅仅负责测试方面的工作。

​ 总结来说，QA职责在于系统层面的完善，侧重于问题的防范及对已发生问题的根源的探究及其对策的实施，从而降低（避免）未来项目中问题的产生测试工程师是发现已有的问题。既然QA本质上并不等于软件测试，那么为什么大部分公司还采用的QA = 软件测试的模式，是否以后这样的等式会有所改变呢？

八.在书中第312页讨论了“软件工程的质量如何衡量”的问题，我产生了一些问题，软件Bug是难以穷尽的，在之前的文章中也说过Bug少于一定水平就好了，但是如何判断软件的质量已经达标了？

​ 查询资料，阿里开发者认为一般可以通过 代码段/模块/时间段内的Bug数与代码覆盖率来判断软件质量，在继续阅读本书后，我发现后面作者讲解了ZB(Zero Bug Build)的概念(每天的版本都要把48小时前的Bug修复完全)，这是否也可以作为评判软件质量的参考标准？