鲁文澔-提问回顾与个人总结

北航2023软工个人总结

19376309

鲁文澔

一、过往博客链接

鲁文澔-阅读作业

二、过去的问题

1. 问题1

在团队中，不同的成员负责不同的需求，相互之间对负责的业务部分理解并不深入，在这种情况下，Code Review应该如何来有效进行，避免CR由于Review者不清楚所编写的代码所需要实现的功能而流于形式。

在4.4部分中，提到了代码复审的作用与需要注意的地方。

例如4.4.5中复审核查表里概要部分的

1. 代码能符合需求和规格说明么。
2. 代码设计是否考虑周全。

以及设计规范部分的中的

1. 有没有无用的代码可以清除。

不能回答的问题：在开发过程中，我们对于他人负责的部分的了解程度不能保证，在Code Review的过程中，上述三个考察点，如果并不能全面了解被Review的人的思路，则难以把握概要部分中的两个复审要点，以及对无用代码的判断，对于这样的问题，是否有实践方式可以进行参考？

回顾的解答

Code Review并非只由一个人来进行，进行Review的成员应该包括经验更丰富的程序员以及对项目有统筹能力的PM，分别对应对代码编写风格、结构设计的检查和对功能细节考量的检查，对于单一角色的Review来说应该是难以覆盖全面的，但是如果是各司其职的一组Reviewer则可以解决这个问题。

2. 问题2

在书中1.2部分，指出了软件工程的目标

创造足够好的软件

一个项目可能并非从一开始就采用了软件工程中所提出的方法论，但随着规模的增大，暴露出了不规范的开发模式的问题，修复这些问题造成了人力的短缺，引入软件工程方法论，制定流程规范对于人力的节省是否有所帮助，这样对后续的人力节省的节约主要是在哪些部分？将开发也需要额外的人力，在过渡期带来的阵痛，有没有一些好的方法实践？

回顾的解答

使用软件工程中介绍的方法论并不是个人的选择，而是当软件规模达到一定程度后不得不顺应的趋势

节省人力不是目的，目的是构建大型的软件。

3. 问题3

在书中第8.3部分，提到了通过用户调查的方式来获取用户需求。

不能回答的问题：但是当我们所需要构建的软件，源于我们的一个从没有人设想过的场景，既没有具体的需求方，又没有可以参照的先例，这样的软件，应该如何来搜集市场的数据来为软件的需求设计做支持。

回顾的解答

软件是用来解决问题的，如果是从自己面对的问题中引申出来的需求，就可以按照自己的需求先实现一个最小功能版本，推入实际使用后再对市场的反馈进行调整。

4. 问题四

在书中2.1.2的问答部分提到

如果你的模块中的某个错误处理路径很难到达，那你也许要想想是否可以吧这个错误处理拿掉

不能回答的问题：有些错误处理的分支，在测试时很难出现这样错误(例如malloc失败，返回的指针为NULL)，但是实际上这样的错误并非完全不存在的情况，而且这样的情况的兜底措施也十分重要。这种情况下，我们应该怎么对待这一个分支，是应该想方设法执行到这一个分支，还是应该就此放过，静态审查即可？

回顾的解答

我认为并不应该拿掉，但是可以针对这一个部分降低覆盖率要求的阈值，偶发的错误往往一旦发生就会产生严重的后果，这样的兜底策略是不应该被取消的，除非在更高的层面对这一个严重后果进行处理。而需要改进的应该是对应的mock机制，应该拥有不易复现的异常情况的构造模拟能力。

5. 问题5

在书中16.5部分，提到了过去小作坊发家的大企业

• 威廉·休利特和戴维·帕卡德创业的车库，小作坊。HP公司曾是硅谷工程师文化的代表
• 比尔·盖茨和保罗·艾伦最初创业时，连车库也没有，比尔同学驻扎在学校的机房写程序
• Google的两个创始人开始也是用一些简单的机器和网络，搭起了一个搜索的小作坊

不能回答的问题：现如今，软件愈发大型化，复杂化，其规模已经逐渐生长至‘小作坊’式开发者所难以掌控的程度，例如vscode这一软件，虽然他是开源软件，但是其代码规模已经让其他开发者望而却步，在这种情况下，小作坊式的开发是否还有生存的空间。

回顾的解答

小作坊还是有存在价值的，面对一些创新的、原型的产品来说，小作坊会更加灵活和高效，这是大型企业的繁琐流程无法实现的。

但是对于例如云计算、AI大模型等领域来说，小作坊的资源受限，在制作产品时可能会无法负担得起。

但是能以小作坊开始的，都是小作坊能负担得起的方向。

三、学到的知识点

3.1 需求

在需求方面我学到的主要知识点是NABCD模型

NABCD模型分为Need，Approach、Benefit、Competition、Delivery五个部分，涵盖了需求分析里面的需要考虑的主要因素

在以技术出身去考虑功能需求的时候，往往会误入以技术为主导的分析方式上，我要用多么多么炫酷的技术，实现多么多么复杂的功能

但是这些功能可能并不是贴合需求的，只是一些炫技倾向的作品。所以我们需要一个框架或着说大纲来指导对于功能需求进行分析。

NABCD就是一个很好的框架，N是解决什么样的问题，Approach可以分析实现的可行性，Benefit更强调功能的价值，Competition用来分析我们的竞争力和生存可能，Delivery则分析我们的产品应该如何走入市场，是一个梳理从问题发现到方案提出与实现，再到发布与竞争全流程的分析方法。

3.2 设计

在设计部分，我学到了在撰写设计文档的时候会常用的示意图的类型

• 实体关系图：用于描述实体、实体的属性与实体之间的关系
• 用例图：描述用户的使用场景流程
• 数据流图：描述数据在实体之间的流动规则
• 控制流图：表达操作与逻辑判断的流程图
• UML：一个较为统一的表达方式

3.3 实现

在实现阶段，我学到了对基础设施建设的重要性，就像博客现代软件工程讲义 7 开发 开发阶段的日常管理里面比喻的“脚手架”

在Beta版本里面，对于自动化部署的基础设施建设被放到了最后来实现，在其间更换开发环境的时候，配置环境每次都需要至少半天的时间

但是在最后完成了自动化部署的设施后，部署一次只需要半小时，如果在开始就准备好基础设施，能够节省很多时间

3.4 测试

在测试阶段，我学到了测试矩阵的知识。

测试矩阵将两个维度变量综合起来展现测试结果的表达方式。

一般常见的测试矩阵两个维度的变量可以是，不同的测试环境条件之间，或者测试方法和测试条件之间等关联。

3.5 发布

发布阶段我学到的知识点：发布的软件并不要追求完全的零缺陷

发布的时候是可以有已知的缺陷的，但是需要做到心中有数有预案

如果一味地追求毫无缺陷，可能会错过最佳的时机

3.6 维护

维护阶段我学到的知识点主要在于数据采集和日志的存储

数据采集方面我觉得爱杰团队的数据采集框架使用的很好，采用了成熟的框架进行统计

而日志的存储就需要考虑很多东西，包括日志的输出位置、聚合、区分，以及考虑磁盘压力的日志滚动功能

缺少这些设计可能在初期不会体现出来，但是当运行一定时间后可能会造成比较严重的后果。

四、个人的体会与收获

对这学期的软工课，我主要有两个期望

• 完成之前设想的FaaS平台
• 锻炼一下自己的产品思维，不能只有技术思维

虽然阴差阳错的还进行了一些项目管理的锻炼，但是以上的两个期望也都得到了满足。

回到一开始的产品思维上来，从我过去的项目经验来看，技术出身的开发者在完成一个作品的时候，往往不自主地由于希望实现功能的强大而忽略了用户的体验，我在掩饰的时候部署的一个前端项目，实际上是22年暑假我完成的一个前端低代码工具。

这个工具很强大，维护了一个和React的JSX组件一致的数据结构实现了对画布中DOM树的管理，自定义的DOM节点属性和CSS样式属性

理论上来说可以完成几乎和编写前端一样的功能，但是问题在于，这个的复杂度并不比直接编写代码的低，这个工具根本没有典型的用户和使用场景

还有一个偏硬件的项目，一个迷你示波器项目，这个项目是出自自己的需求完成的，在典型用户上并没有太大的问题。

但是太追求极致了，屏幕设计的太小了，导致体验上比较糟糕，如果换上稍微大一些的屏幕会更不错一些

所以在这次软工的项目里面，通过原型等手段对用户体验进行了一些设计，但是由于沟通上出现了一些问题，Alpha版本的用户体验也不是很好。

Beta版本改进了一些，达到了比较好用的程度。但是软工课程教会了我典型用户和典型应用场景的分析方法，能够针对用户和使用场景去设计用户体验，来做出好的产品。

最后则是项目管理的一些经验，也算是意外之喜，这次让我理解到了项目管理的重要性，从前看我mentor分配任务，询问进度游刃有余觉得是很简单的事情，但是真正自己做了才发现并非一件易事。这次的软工的项目管理踩了一些坑，出现了几次延期的风险，让我意识到项目管理不是易事，但是一次的实践想要完全掌握还是比较困难。希望之后能有更多机会训练这一能力。