阅读 《构建之法：现代软件工程》后的疑问

阅读 《构建之法：现代软件工程》后的疑问

项目	内容
这个作业属于哪个课程	2023年北航敏捷软件工程社区-CSDN社区云
这个作业的要求在哪里	个人作业-阅读和提问-CSDN社区
我在这个课程的目标是	学习与掌握软件工程的理论与应用实践，学习如何工程化地构建软件
这个作业在哪个具体方面帮助我实现目标	阅读教材，了解软件工程地基本方法，记录自己的一些思考和问题。

通过这本教材的阅读我了解了现代软件工程的一些方面和一些构建软件（一个人或者一个团队）的基本方法，一些方法可能是软件工程独有的或者首创的，比如敏捷开发等，还有一些可能是管理学一些通用的方法，比如WBS，看板等。在阅读过程中也对自己之前参加的团队项目进行了一些反思，它们有一定的工作量，由多名同学协作完成（都能够进行开发，但对于软件工程几乎没有了解）。这些项目的开发流程都接近于所谓“一窝蜂”模式，各种问题层出不穷，往往在截至时间前不能完成既定目标。比如最近的数据库实验需要实现中等规模应用，在实践上前后端同时开工，没有任何spec（或者存在几行描述不清的需求文本），最后连接口都对不上。再比如之前某项目使用git管理版本，引入了一定的CI工具，但是实践上没有签入流程的规范，导致版本不一致的问题层出不穷（如下图，我现在也看不懂哪个分支是干什么的）。

数据库实验的"spec"总共找到以下三行，这显然无法指导项目开发：

可以写成存储过程的服务：
用户给自己的店铺添加一个物品，要同时将该物品加入store_good表、good表
删除店铺内的一个物品同理

提问

以下页码章节均指《构建之法：现代软件工程》（第三版）书中相应部分。

Q1：WBS：Work Breakdown Structure的具体实践问题

WBS通常从最终的产品开始，一层一层往下，把大型交付件分割为小型、具体的交付件。
（p178,8.7）

WBS方法在经济管理课程的管理学部分也曾提到过，大概是举了制造汽车按照零件逐级划分的例子，网上查询的结果也显示WBS不仅仅应用于软件工程，而是一个管理学的方法。但是就像单继承的树形结构一样，树可能既简单又美好，但是很多实际问题可能不太好抽象成树，比如书上例子：

假设这个购物网站是用MySQL+SpringBoot+Vue开发，那么对于上图叶节点的各个功能，都可能需要在前端，后端以及数据库同时修改实现，比如对于用户注册登录，需要在前端使用Vue构建页面，发送表单，在后端处理表单进行用户认证，但是WBS的逻辑把这些任务分开，也就是本来除了WBS显示的基于任务的维度，还有一个传统的基于前后端分离的维度，并且除此之外，任务之间可能还有依赖关系，那么WBS对项目工作的抽象是否有些局限？

Q2：MVP（最小可行产品）和MBP（最强最美产品）的选择

把产品最核心的功能用最小的成本实现出来，然后快速征求用户意见……
(p105,5.3.6)

MVP指导把产品最核心的功能用最小的成本实现出来，同时也强调产品的核心价值（相对于竞品），并以此快速获取用户反馈进行迭代。但是按照MVP指导思想实现的产品可能确实在核心特性上可能优于竞争对手，但是由于对于其他功能以最小成本实现可能劣于已经在市场上存在的其他产品，作为一个整体其成熟度和功能完善性可能也不如其他，那么这样的产品怎样才能吸引用户呢，对应的若使用MBP指导，可能预算花光甚至做不出产品。

考虑一个最近我比较关注的开源游戏引擎Godot，作为一个开源项目，它需要持续吸引更多的用户和开发者以维持项目的存续，且它有一个明显的强大竞品Unity（几乎垄断了中低端市场），Godot的优势在于宽松的许可协议（MIT），相对于Unity凭借垄断地位高额的授权费用；集成的制作工具，TileMap，2D动画等，不需要额外的插件。但是这也带来了问题，前面提到作为开源项目Godot需要持续吸引更多用户和开发者，所以Godot正式发布时接近于最小可行产品，而它又倾向于在功能上大包大揽（这也是其一个核心价值）这导致它包含很多bug，进而导致了用户的流失。

在最新的major version中，项目维护者进行了大量的重构优化（可能接近于的“最强最美产品”），但是2019年开始开发，2020年开始alpha测试，现在才RC4，发布时间的延后也导致用户等不及转而使用其他项目，大概维护者也意识到这一点，提前了版本的发布，但是成熟度仍然是一大问题。

可以看到一些breaking bug都打算推迟到下一个版本了。

那么要开发一个市场上已经存在竞品的项目，如何在开发成本（时间……）和产品质量（bug，功能完善度……）之间取舍？

Q3：效能过剩？

……但是没有一种技术生来就是维持性技术，那么如何判断一种技术已经到了维持性阶段呢？一个重要的特性就是效能过剩。
（p362,16.3.4）

作者提到的效能过剩确实普遍存在，作者举的例子包括CPU，内存，闪存容量和字处理软件，但是我感觉这可以分成不同的两方面，一方面是软件方面，特别是移动端App，集成了大量功能，很多时候不是在满足用户的需求，而是在为用户创造需求，一个音乐软件，一个短视频平台都会集成一个电商平台，更有甚者如某国内知名IM应用集成了一个3D引擎：

（如图libUE4.so）

在软件方面效能过剩确实存在，而另一方面，臃肿的软件又会占用大量的硬件资源，如上图一个UE4的动态链接库就有125MB，那么硬件资源的效能真的过剩吗？或者从另一方面讲，对于产生效能过剩的处于成熟期的软件，如IM，其大量臃肿的功能其实不能算是实质性的创新，那么对于成熟期的软件如何进行实质性的发展与创新？

Q4：关于编程语言

你说PHP不是最好的语言，那哪一个才是呢……Rob说，Go语言是为了解决在大规模软件开发中的痛点……
(p147,7.5, Build To Win)

作者提到无论是编程语言还是框架，流程等等，没有最好的，只有最合适的，并且提到了Golang，由于一些语言设计的原因（错误处理奇怪，不完整的泛型支持），它的名声不怎么好（至少就语言本身而言），但是在工程上Golang无疑是成功的，它解决了它想解决的问题：构建时间过长，那就不优化（虽然生成代码质量一般），模块之间依赖关系不好管理，go module等，不同程序员使用一个语言不同的子集，程序难度，简单的语言设计，强制的通用格式化工具，以及强大的并行支持。

可能可以发现，一些工程上成功并被广泛使用的工具其实乍一看起来设计的很难说完美，比如golang，其语法设计显然不是很好，再比如cmake，虽然已经是事实上的标准但是可读性极差，“一群工程师来公司上班的目的是什么呢？就是尽快把工作做好”。但是把工具设计得更为“登堂入室”大概也可以提高效率，更好地完成工作。那么应该怎样在快速解决工程上的问题和设计更具有统一性，更“优雅”的工具上取舍呢。

Q5： 关于用户调查问卷

(P157,8.3第4点)

作者对调查问卷提出了一些可能的建议以更好地了解用户需求，关于调查问卷我想起了之前看到的显卡驱动的调查问卷，它在一些问题上使用了一些可能不是所有用户都理解的名词（如下图），我感觉这很难得到有效的回答，但是可能这个回答关系到产品开发和迭代的方向。更加泛化地说，不能预期用户在某些方面和开发者具有相同的知识，那么这种情况应该如何设计问题？（针对下面这个问题，其实我也不知道自适应同步技术具体是什么）

Q6：关于Goto

函数最好有单一出口
(p69,4.3.2)

去年有很多同学都写了这个问题，大概是因为从一开始写C无论是老师还是教材都告诉我们goto有害，这一切大概源于Dijkstra的《Go To Statement Considered Harmful》。但是我比较认同在合适的地方使用goto是合理的，除了书上提到的在错误发生时跳转到一定位置清理资源（这是安全且具有较高可读性的），还有在跳出多重循环时使用goto（相反，如果采用提取函数或者使用额外变量的方法感觉可读性都劣于goto），以及可能可以替换一些嵌套非常深的条件分支语句。

int f() {
    int i = 0,j = 0;
    while(i < 5) {
        while(j < 5) {
            if (j >= 3) {
                goto outer;
            }
            j++;
        }
        i++;
    }
outer:
}

int f() {
    int i = 0,j = 0;
    int flag = 0;
    while(i < 5) {
        while(j < 5) {
            if (j >= 3) {
                flag = 1;
            }
            j++;
        }
        if (flag) {
            break;
        }
        i++;
    }
}

int g() {
    int i = 0,j = 0;
    while(i < 5) {
        while(j < 5) {
            if (j >= 3) {
                return 1;
            }
            j++;
        }
        i++;
    }
}
int f() {
    g();
}

一些语言可能会提供一些方法替代这些受限的goto使用，比如golang的defer,以及带标签的break语句。

可能比较好的实践是不要用goto往回跳转？所以在面向过程编程中goto真的是有害的吗？