提问回顾与个人总结

提问回顾与个人总结

项目	内容
这个作业属于哪个课程	2023年北航敏捷软件工程社区-CSDN社区云
这个作业的要求在哪里	个人作业-提问回顾与个人总结-CSDN社区
我在这个课程的目标是	学习与掌握软件工程的理论与应用实践，学习如何工程化地构建软件
这个作业在哪个具体方面帮助我实现目标	总结本学期在项目开发和课程中学习的内容，回顾之前提出的问题并尝试给出答案。

对之前所提问题的解答

原博客地址： 阅读 《构建之法：现代软件工程》后的疑问_cactus ball的博客-CSDN博客

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

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

实际的项目其实可能确实不好使用一棵逐层划分的树来完全地抽象，但是它也不失为一种比较好的工作划分方式。在本学期的团队项目中，工作被分为前端部分和后端部分。前端部分又被划分为管理员视图、用户视图等，而后端也被划分为数个子模块。

这样基于前后端的划分确实可以较好地分工，但是对于一个具体功能它常依赖于前后端共同完成。基于团队项目中的经验，我认为可以这样理解：WBS可以提供一个维度上的划分，而另一个维度则是通过开发人员之间的交流完成的。如登录注册这一功能涉及前后端的联动，在第一个维度上可以分为注册、登录、注销、修改等交付件，而第二个维度可以分为前端UI和后端鉴权两个部分，第一个维度可以是WBS，而第二个维度可能是通过文档或者接口管理工具来对项目进行管理。

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

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

(p105,5.3.6)

MVP或是MBP有时可能没有选择的余地。比如课程中的项目通常时间都比较紧张。团队项目中我们面临的问题是能否在DDL之前拿出一个可行的产品，而对于可选的功能只能是暂时舍弃。

当下可能快速迭代并接受用户反馈是软件开发的主流趋势，这除了对用户设备的闪存使用寿命不太友好外，对于在产品的竞争中占据优势是十分有利的。像课程项目一样，有时可能确实没有选择的空间，课设想做得尽善尽美会面临DDL的问题。而投入市场的产品也存在盈利的压力。问题中提到的Godot也一样，如果不改为使用快速迭代的版本号，项目的停滞可能导致失去赞助，这样这个开源项目能否继续存活也是一个问题。

Q3：效能过剩？

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

（p362,16.3.4）

其实臃肿的软件应该不是一个技术问题而是一个经济问题，这些软件的目标都是控制尽可能多的流量以从中获取更多利润，所以把功能做得多而臃肿。我认为在应用功能里无节制地做加法确实不能算实质性的创新，但是成熟期的软件如何创新确实仍然是一个问题。对于一个应用，用户常常只希望使用其主要功能，比如对于IM，用户最需要的只是其即时通信功能。而当下额外的硬件资源被用于承载冗余的软件功能，这大概是一种软硬件的双重过剩。

Q4：关于编程语言

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

(p147,7.5, Build To Win)

可能每天都会诞生很多种新的语言或者是工具，它们解决了这样或是那样的问题，又带来了新的问题。很多工具的设计大概都是为了解决某些燃眉之急，而很难去考虑设计得非常完美。比如cmake，虽然大家都不喜欢它但是它为C++提供了一种标准的构建方式。Golang虽然在错误处理、泛型等设计上考虑不太充分，但是它解决了它想解决的问题，比如易于书写并发代码，规范简洁等。众所周知JavaScript存在大量的设计错误，但是它在当时成功解决了实现动态网页的问题。可能重要的不是工具，而是如何使用工具更好地完成相应的任务。

Q5： 关于用户调查问卷

(P157,8.3第4点)

团队项目中我们实现了一个轻量级的FaaS平台，但是可能很多人（包括我）在去专门了解之前都不知道FaaS是什么。除了用户调查问卷，在用户界面的设计等部分对用户的引导都是十分重要的。不能开发出来的软件只有开发者自己会使用。在软件开发前开发者应该对自己的目标用户有清楚的预期，比如团队项目的FaaS平台针对的就是有一定经验的开发者，调查问卷的设计应该针对这个预期进行。

Q6：关于Goto

函数最好有单一出口

(p69,4.3.2)

这个问题可能可以泛化为是否应该使用一些晦涩但是合法的语法结构，团队项目中使用了React框架，它使用jsx书写组件。jsx可以在html里嵌套JavaScript再在里面嵌套html……，再配合互相嵌套的匿名函数，在某些情况下可能会造成不小的认知负担。

还有JavaScript新的异步语法，虽然理论上它比回调简洁但是配合异常处理会使得控制流不太明显，且可能需要花费一些时间来理解async和await的行为。以上都是我们在alpha版本中遇到的问题，在beta版本中我们统一了使用回调函数，且不允许嵌套一行以上的匿名函数。

回到goto，其实defer，带标签的break算是对goto比较好的限制，但是在使用包括goto等复杂晦涩的语言结构时，应该考虑这是否会对其他团队成员造成麻烦，代码不是自己能看懂就行了（可能第二天自己也看不懂了），而是应该符合一定的代码规范。

在项目中学到的知识点

需求

NABCD分析，项目抓住了现有FaaS工具配置过于复杂的问题，提供了简单地部署函数的方法。虽然推广和发布的实际情况和预期差距较大，但是在beta阶段找到了为研究所提供产品的新的方向。这也表明前期确定的需求可能也会随着开发的进行改变。

设计

契约式编程，在结对项目开发前，约定了GUI，CLI和核心计算部分的接口，包括传入参数，返回参数，内存管理等。在团队项目中，接口文档约定了接口调用的HTTP请求报文的方法和格式，调用顺序等。

实现

就技术上讲，学习了React和一系列前端框架和语言的使用。就项目管理上，学习了通过规范的分支，commit，MR流程保证代码的质量。如下图这种分支图大概在之后的项目中不会出现了（下图是软件工程课程之前的项目）。

这是团队项目的分支图，可以看到相比上图在规范程度上有很大的提高。

测试

在结对编程过程中学习了C++单元测试的写法，包括使用gtest检测并提高代码覆盖率，同时使用valgrind检测代码中存在的内存泄露，访问无效内存的错误。在交换自己和其他组的计算模块的环节实践了“黑盒测试”，即在其他组的模块上运行我们的单元测试，并成功找到了其他组存在的bug。

而在团队项目中，主要是针对测试提出的问题提交fix，或是向测试解释自己的代码实际上满足了文档要求的行为。

发布

合理地砍掉功能，在alpha阶段中的Web IDE本来计划提供语言服务器的功能，但受限于时间、资源（需要专门的服务器运行语言服务器）和技术，且因为实现意义不大（Web IDE的体验很难超过VS Code，毕竟其实编辑器就是Monaco Editor）最终没有实现。在beta版本彻底砍掉了这个功能，转而提供Web Shell。对功能取舍的决策大概也算是学到的一个知识点。

维护

在alpha版发布前后存在一些安全漏洞被用户指出，之后的版本修复了这些漏洞，并加强了对安全方面的考虑。这种从用户处及时获取反馈并迭代软件的软件开发模式也是收获之一。

心得体会

软件工程课程花费了我不少精力，也让我有了不少的收获。不仅仅是对一些技术的掌握，更是对一些软件开发的方法论的了解。在这个过程中也面临了不少的挑战，比如在结对项目中，允许使用的两种语言和构建工具我都不熟悉，于是在很短的时间里学习了C++14，gtest，CMake并完成了项目。在过程中还实践了结对编程，这种编程模式感觉很新奇，如果写出的代码有逻辑错误或是不规范旁边的同学可以立即指出，这大概可以较好地提高代码质量。如果有机会在之后可能可以继续使用这种开发模式。

团队项目中也遇到了不熟悉语言和开发工具的问题，在前期交流中我指出我比较熟悉Flutter框架，然而在之后的项目中我被分配的任务是使用React函数式组件构建前端页面，且需求还包括一个Web IDE，这显然脱离了前端增删查改的范畴（嵌入Web IDE的过程非常艰难，React函数式组件引入了函数式编程概念，要求组件是纯的，而Web IDE管理的编辑器实例和状态必须被抽离为副作用）。虽然都是MVVM框架且Flutter和React似乎存在一些借鉴关系，但是我对前端JavaScript，css，html都非常不熟悉。好在投入大量精力一边学习一边开发总算完成了alpha版本。之后的beta版本前端任务较为轻松，主要是因为经过alpha版本的开发对框架已经较为熟悉了且Web IDE最终被砍了。

在课程中除了学习了技术，对软件工程的理解可能更为重要，比如提交和MR规范，这保证了项目的代码质量和稳定。在alpha版本中如上面所说，我几乎是现学现做，所以代码比较混乱，在beta版本中使用eslint对代码风格进行了强制规范，使代码风格更为统一和清晰。在开发过程中，小组的成员提供了详尽的文档，这保证了前端开发能够快速地进行，之后也对其进行了完备的测试，指出了其中的问题。

最后感谢团队项目的所有同学，特别是团队PM，他承担了团队很大的工作量，不仅要协调前后端开发，还要统筹文档的撰写。也感谢结对编程的同学，他顶着二羊也在坚持和我一同开发。