软件工程实践总结———浮出水面

081900317_李楷鸿学生 2022-06-26 20:39:44

这个作业属于哪个课程	2022年福大-软件工程、实践-W班
这个作业要求在哪里	软件工程实践总结&个人技术博客
这个作业的目标	课程回顾与总结
其他参考文献	CSDN博文，构建之法（邹欣第三版）

Q:1.2.2 大陆高校中的计算机专业与软件专业是否并不像书中说的那样雷同？

Last Answer:在我看来在计算机专业与软件专业确实有雷同之处，也有不同之处。其实在本科计算机专业与软件专业的学习课程基本相同，计算机专业涉及面可能更广，但是深度我觉得与软件专业是相同的，计算机专业并不意味着涉及更多的理论，而是与软件工程专业一样。计算机专业的毕业生大部分是投身于解决工程问题，虽然计算机偏理论，但是毕业生由于就业前景好，对科研没有兴趣，也不会投身解决理论问题，而更多投身解决工程问题。
Current Answer:经过一个学期软件工程课程学习，这应该是三年学习中与软件工程专业比较有关联的课程，但是也仅限于软件工程实践，从结对项目到团队项目，软件的需求分析，概要和系统设计，开发，运营以及维护，真正意义上涉及更多与人的交流。其他课程而言，更多的也是偏向理论的课程。当然计算机专业并不意味着涉及更多的理论，他们也有很多偏向实践的课程。其实计算机科学和软件工程有很多交汇的领域，因此计算机专业与软件工程还是有许多雷同之处。但是正如《构建之法》所说“不再纠结"科学"与"工程"的问题，而是在不同的学习与工作阶段，投入到最适合的项目类型中去。”
原问题链接
Q:1.2.4 软件的行为和用户的期望值不一样，就一定是 Bug 吗？

Last Answer:是否是bug取决于用户、开发者的不同角度。但是软件的行为就是为了满足用户需求，如果软件只是开发人员在预计的时间内发布的“足够好”的软件，不能满足用户期望值，就是存在Bug。因此，软件的行为和用户的期望值不一样，就是存在Bug。
Current Answer:在团队项目需求分析阶段，根据用户需求，指明具体功能以及验收标准，在alpha阶段和beta阶段结束后分别进行了测试，包括单元测试，接口测试，以及功能测试。而功能测试，正是根据需求规格说明书中的具体功能和验收标准进行测试。如果不满足功能性需求，意味着存在Bug。因此，软件的行为和用户的期望值不一样，就一定是Bug。需求是来源于实际的，所以应研发出满足用户需求的软件。类似于在后端接口开发过程中，由于系统设计没有充分指明前端需要的返回值，而在实际开发中，后端接口不满足前端的要求，即存在bug，就要修改。
原问题链接
Q:2.1 单元测试由最熟悉代码的人来写是否足够呢？

Last Answer:足够，最熟悉代码的人了解代码的目的、特点和实现的局限性，让熟悉代码的人来写单元测试是足够的，这样单元测试就能体现API的语义，如果让不熟悉代码的人来代劳，语义的准确性不能得到保障，会产生歧义。
Current Answer:在团队项目开发中，负责后端接口开发，而对代码进行单元测试，主要由自己进行。在我看来，单元测试应该由最熟悉代码的人来写。在实际单元测试中，设计测试用例要满足相应的条件覆盖、判定覆盖等，而这些要建立在对代码逻辑熟悉的基础上。如果由其他人对代码进行单元测试，没法保障单元测试的效率以及正确率。而黑盒测试，不需要了解代码逻辑，可以有专人进行测试。
原问题链接
Q:2.1 如何提高单元测试的覆盖率（尤其是对于经验不足的新人）?

Last Answer:对于经验不足的新手，提高单元测试的覆盖率，应该从以下几个层次入手，函数的覆盖，语句的覆盖，分支的覆盖，条件的覆盖，分支覆盖是强有力的测试依据，必须测试公开的和私有的函数/方法，提高覆盖率。
Current Answer:刚开始进行单元测试是在个人实战过程中，一开始对于单元测试无从下手，但是了解一些单元测试后，设计测试用例满足判定覆盖、条件覆盖，提高了测试的覆盖率。而单元测试也占用了个人实战的一大部分时间，提高覆盖率并没有那么容易。当然对于新手而言，单元测试要测试API的每一个方法及每一个参数，同时要从多个层次入手，这样才能提高单元测试覆盖率。一味的追求代码覆盖率，并不能保证正确性。
原问题链接
Q:2.1 单元测试中作者自己测试最好吗，单元测试使用随机数真的没有意义吗？

Last Answer:单元测试由作者自己测试最好，代码的作者最了解代码的目的、特点和实现的局限性。单元测试应该产生可重复、一致的结果，如果某个随机数导致程序出错，但是下一次运行又不能重复这一个错误，则于事无补，所以单元测试使用随机数没有意义。
Current Answer:单元测试由作者来完成，肯定是最好的，作者理解代码的逻辑，能够在保证覆盖率的同时保证正确性，此外效率也得到保证。团队实战过程中进行单元测试，使用随机数进行单元测试的话，程序报错，测试点无法通过，但是也仅限于此，根本无法准确定位错误，意味着要重新进行测试用例构造。单元测试过程中，设计测试的过程中，使用确定的值，一旦测试用例无法通过，就能够重复这个错误。不然下次运行又不能重复这个错误，所以单元测试使用随机数是没有意义的。
原问题链接

新问题

Q:6.2 怎样在一开始制定一个较为合理和较弹性的计划？对任务优先级和依赖关系的权衡有什么标准吗？

A:因为团队开发过程中，一开始指定地计划，到后期都很难按时完成，都需要加班加点。考虑到可能我们软件的功能较多，但是人员数量是不足的。但这不是唯一的理由。其实在一开始，就应该考虑到工作量和任务数，而不是按照模块进行划分，应该充分考虑各种因素，进行任务划分，这样的话，就较为合理。同时要设置缓冲时间，前紧后松这样就会更有弹性。此外要考虑到任务的优先级和依赖关系，对于有前后关系的任务，尚未完成，就会影响后面任务完成的，就应该有较高的优先级，这样不会使得进度延迟。当然也需要全盘考虑各种情况权衡优先级。
问题链接
Q:13.2 单元测试应该在什么时候开始做？

A: 在团队开发过程中，单元测试都是在代码完成后开始做的，根据代码设计的逻辑，去设计单元测试的测试用例。但是《构建之法》中提出，"单元测试应该在功能完成之前就已经完成了设计，即事先定义好接口和规范的输入输出，而不应该根据写完的代码写单元测试。应该测试的预期的功能和数据处理，如果预期功能发生变化，单元测试也应该发生变化，代码是应该与设计一致"。单元测试在开发之前设计会比开发完成后设计有更多好处，能够指导开发，定义规范，会起到较好的效果。
问题链接

五个阶段的实践收获

需求

在结对项目，以及团队实践过程中，需求分析阶段，都使用到了NABCD模型进行竞争性需求分析，可以很有条理地进行需求分析。从N（Need，需求）、A（Approach，做法），B（Benefit，好处），C（Competitors）到D（Delivery，推广），通过该模型可以很好地描述当前打算开发软件的优点，以及实现的必要性，同时又能很好的进行需求分析。
此外在团队实践过程中，负责将用户需求转换成用况图以及类图。很好地锻炼了面向对象分析的能力，同时巩固了UML软件使用，以及类图的设计。

设计

数据库设计，通过将需求分析阶段的类图，从数据库的逻辑设计到物理设计，通过ER图，体现了实体之间的关系，转换成数据拓扑图，到数据库的字典设计，最终设计出完整的数据库。通过数据库的设计的实践，让我对数据库设计有了更深的理解。当然，数据库设计阶段一定要满足需求分析，不然在后续的开发过程中，会导致事半功倍。数据库的设计一定要在开发之前就要统一，不然在开发过程中再去修改数据库，会导致开发人员有抗拒情绪，修改数据库意味着要修改代码。
系统设计阶段，对后端接口文档进行定义，明确接口实现的功能，以及请求与响应的参数。这也是十分重要的，不然前后端无法统一进行开发，最终只会让前后端对接变得十分困难。

实现

团队实践主要负责后端接口开发，正好与自己开学初顶下的学习路线一致，正好可以对自己学习过的技术进行实践，技术栈是SpringBoot、MyBatis-plus以及Redis。在开发过程中，也很好地对执行了代码规范，不再是先写代码再执行规范。同时也学会了SpringBoot图片上传接口的实现，自定义异常处理机制，以及jar部署Liunx服务器对图片上传进行测试。此外,还了解了一些SpringBoot开发规范，可以很好地进行开发。除了基本的层次以外，可以添加DTO层，用于封装sql语句返回的复杂内容，以及VO层，对前端请求参数进行封装。使用springboot自带的@validated注解，对前端参数进行校验，会更方便。
在开发过程中，要不断地与前端进行对接，锻炼了沟通能力，以及如何与前端沟通技术上的问题，让对方更容易理解。同时也发现了，前后端主要问题都出现在，需求不一致上，因此在设计阶段，数据库设计和系统设计就要做到统一，这样能起到事倍功半的效果。

测试

后端接口开发过程中，主要进行了单元测试、接口测试、以及性能测试。通过Junit5对后端代码进行单元测试，也理解了之前提出的问题。使用了ApiPost进行接口测试，发现了接口存在的一些问题。同时也使用PerfTest，基于Junit5进行性能测试，相比于Jmeter测试工具而言，PerfTest使用起来会更方便一些。

发布

发布阶段，主要负责，将后端代码打包成jar,并部署到服务器上。由于服务器是第一次部署，所以要在Liunx系统上搭建环境。
因为部署jar包，所以要安装JDK，因为是SpringBoot项目，jar中自带tomcat，所以不需要安装。然后要安装mysql，将数据库导入。此外项目还使用了redis数据库，对token进行缓存，因此要安装。考虑要将redis运行在服务器的守护线程上，因此要修改配置文件。这样部署jar包的前提环境都配置好了，要通过服务器管理平台安全组将端口对外访问的权限打开，这样将jar启动，配置在后台运行，就正式完成了。当然在多次换服务器之后，以及进一步让我对，liunx服务器常用命令，以及常用环境搭建非常熟悉。当然这都是建立在不断失败的基础上走过来的。

软工实践的理解和心得

个人项目

个人项目完成北京冬奥会奖牌榜及每日赛程输出的控制台程序，在开发过程中使用IDEA开发工具，项目管理工具gitCode，此外还接触了单元测试Junit，使用PSP表格进行耗时记录，从项目接口的封装到不断地进行性能优化，再到单元测试，最终达成jar包，初步了解了一个软件开发的全过程。此外，需求的不断变更，也让我们深刻理解了，在客户需求不断变更的同时，我们应当保持理性，有更多的沟通。

结对编程

结对编程使用Axure进行原型开发，此外使用Vue脚手架搭建单页应用程序。在原型开发过程中，初次使用Axure，在学习过程中遇到了不少困难，但是也在和队友的讨论中不断解决问题，包括奖牌榜如何设计更加方便，美观。当然，也在使用RP9的团队项目进行团队协作。通过实现需求，也是第一次接触了前端的框架开发，学习了vue，bootstrap等等。因为没有开发后端，于是便持久化存储在localstorage中。在结对项目中，更多要学会如何与队友进行沟通与协作，互帮互助，才能有所提高。在这里还是要感谢我的队友，给我提供了很多技术上的帮助。

团队项目

团队项目应该是大学以来，组队合作完成的最大的项目，从一开始的需求分析、数据库设计和系统设计、git实战、alpha冲刺，再到beta冲刺，一路走来，不光是技术上有许多进步，同时也与队友有着很好的沟通。git实战，一天之内要完成前后端的开发，虽然说起来很简单，但是当真正多人合作起来，并没有那么容易。虽然最后忙活到截止时间以前，我们都没有完成前后端的对接。这也给了我们后面两次冲刺有了很多帮助，一开始就要确定好分工，指定好各模块的截止时间，在保证前后端的进度的前提下，要先做好前后端对接，这样才不会拖到最后完不成。alpha,beta冲刺主要负责后端开发，其实遇到最艰难的问题不是接口开发，也不是前后端的对接，而是我们在需求分析，数据库设计和系统设计阶段没有设计好，而导致的开发难题。这也意味着，下次开发要做好这一点。当然，在与队友一起合作开发的时间是美好的，也感谢队友的理解。

课程目标掌握程度

序号	课程目标	掌握程度（百分制）	理由
目标1	理解软件工程师的职业道德规范和实践要求，了解国情社情民情，理解软件产品对社会、健康文化等影响，树立积极向上的软件开发理念。	95	即将成为一名软件工程师，很好地理解了职业道德规范和实践道德，有着积极向上的软件开发理念，在团队开发过程中，很好地完成接口开发，并进行测试，不会随意地进行开发，满足用户地需求。对软件满足用户需求，社会需要有较深刻地理解。
目标2	掌握需求分析的全过程，能辨别客户表述的多样化要求，熟练使用需求表达工具，能够规范、准确地表达客户的需求，构建需求分析模型。	90	在结对项目与团队项目的需求分析过程中，很好掌握了需求分析的全过程，能够将用户的需求很好地转化成用况图和类图，以便后期的设计与实现。同样也能用原型设计工具，将用户的需求很好的表现出来，但是原型设计，和构建需求分析模型方面还有待提高。
目标3	掌握软件开发的全过程，遵循体系结构设计方法和基本设计原则，通过正式的技术评审，完成从体系结构设计模型、数据设计模型和构件级设计模型，形成面向高效可靠的服务组件设计方案或软件系统设计方案。	90	在团队项目开发过程中，很好地掌握了软件开发的全过程，完成了从体系结构设计模型、数据设计模型，形成了高效可靠的软件系统设计方案。但是没有很好地遵循体系结构设计方法和基本设计原则。
目标4	能够执行从组件到软件系统的技术评测，具备设计模型的评判能力，具有创新设计意识，能够优选设计方案。	80	初步具备了设计模型的评判能力，能够择优选择设计方案，但是还没有创新的设计意识，还需进一步提高。
目标5	遵循软件开发各阶段文档标准，采用规范的表达，掌握需求规格说明书、系统设计说明书、系统测试报告等文档撰写方法，具备与业界同行交流能力。	95	在团队项目文档编写过程中，负责了需求规格说明书、系统设计说明书、系统测试报告等文档撰写，当然文档也都是由我负责整合的，对于软件开发各阶段文档标准有了很好的理解。初步具备了与业界同行交流的能力。
目标6	具有良好的团队意识和合作技能，能够与其他成员开展有效的沟通和协作；能够组织、协调或指挥团队开展工作。	85	在结对项目与团队合作中，锻炼了如何与队友如何更好地沟通，培养了良好的团队意识和合作技能。在后端接口开发中使用了源代码管理工具git，有效的进行协作。同时在前后端接口的对接上，很好地通过技术进行沟通。当然在组织、协调或指挥团队开展工作方面还有所欠缺。
目标7	能够辨别具体软件项目管理中涉及的构成要素，掌握软件规模和工作量的估算方法，能够选择合适的工具规划软件进度并对项目管理过程进行配置，具备初步的管理复杂软件工程项目的能力。	80	在结对项目中，很好地掌握了软件规模和工作量的估计，因此在分工方面十分合理，在进度要求的前提下，保质保量的完成任务。团队项目中，使用了teambition规划软件进度，当然主要负责后端开发，完成了后端的接口开发进度安排，也提前完成了任务。对于整个软件项目的管理还是需要进一步提升。