软件工程实践总结&个人技术博客
| 这个作业属于哪个课程 | 2021春软件工程实践|W班 (福州大学) |
|---|---|
| 这个作业要求在哪里 | 软件工程实践总结&个人技术博客 |
| 这个作业的目标 | 课程回顾与总结、个人技术总结 |
| 其他参考文献 | 无 |
课程回顾与总结
0.以前提问题的博客链接
1.在双方默契不足或根本不了解对方的前提下，结对编程的效率和质量真的高于独立编程吗？
结对编程的效率与质量更多取决于结对双方自身的能力。经过结对作业二，我对结对编程双方分别要完成的事有了更清晰的认识。编程最后是以模块化的方式实现，前后端分离，在协调方面最容易出问题的是接口调用和需求理解。这个可以借助接口文档来解决，无论是调用形式还是参数传递都有明确的规定，只要双方约定好，就不会产生冲突，而且完成质量是与双方的默契无关的。需求理解关系到结对二人的经验，对业务的理解程度，从这一点看结对的优势仍旧是高于独立编程。一个人对业务的理解是片面的，角度单一的，综合两个人的建议，取其精华去其糟粕，会更有利于需求理解。
整合上面的观点后，可以对问题作出回答。双方默契程度在结对编程过程中并不是最重要的，即使双方默契不足，只要按照软件工程实践规范，结对编程效率和质量一般都是高于独立编程。
提出新问题：经验丰富的小团队和经验不足的多人团队哪个产出的效率和质量更高？换句话说人员规模小但人才质量高的企业，是否会比人多力量大但平均水平不高的企业一定有优势？这个关系到同样成本情况下，企业该如何平衡员工数量和质量。
2.PSP应该支持软件工程师的个性化定制，还是说专家的建议就是最佳的？
这个问题不难解答，PSP虽然是一种专家建议的计划方式，但毕竟要结合开发周期、开发团队对开发重点的认识、不同类型业务的开发难点所在等各方面编写PSP计划。有过几次使用PSP的经历后，我对PSP有了新的理解。专家会给出一个框架，不是为了束缚软件工程师，而是希望软件工程师在科学研究结果的基础上，对PSP表格进行修改，会比重写PSP表格来得更有效。原版的PSP表格未必能直接用在某个具体的项目，但可以适当改造，转化成最合适的。
提出新问题：PSP的阶段并没有细化，只是一个大概的计划，并且与一些文档的规划有很多重合。开发是否真的有必要使用PSP表格，还是说有比PSP好得多的计划方式？
3.IT寡头们会因为拥有了成熟的市场和成熟的技术，就停下创新的脚步吗？
IT科技公司已经凭借成熟的技术获取到充足的资本，资本能够吸引创新点，许多缺少资金的团队会带着自己的创新点加入IT团队。IT寡头在业界有很强的号召力，并且拥有庞大的资本积累，人才自然而然会涌入这样的公司，掌握人才即是掌握了持续的创新生命力。IT行业本身就是迭代更新比较快的行业，这一点IT科技公司都很清楚，只是有没有能力挖掘创新点，并将创新点一一付诸实现而已，当下的趋势为越是大厂越容易创新。
4.在团队中，每个人的水平层次不尽相同，会演变成平等对话的开发模式？还是说有等级差异的模式更符合现实逻辑？
有等级差异的模式比较适用于规模较大的团队，构成类似于树状的结构，每一层都直接管理邻接的下一层，但不越级管理，这样管理效率较高，一个决策传达下去会很快。如果使用平等对话的模式管理大规模团队，决策传递速度很慢，因为是一对一传递，而且没有做最终决定的人，这种模式在意见分歧很多的情况下很难平衡所有人的意见。平等对话的模式不适用于人员数目多的团队，使用于人数较少，小作坊式的开发方式。
提出新问题：平等对话和有等级差异的模式二者是否可以结合？例如对整个团队使用等级差异的模式，下属的每一个小组再使用平等对话的模式，这样的方式会是更佳的模式吗？
5.软件工程和计算机科学很相似，本科可否将二者合并为计算机软件与理论？
计算机科学与技术和软件工程在培养目标和课程设置上还是有很大不同，计算机科学对理论研究会更深入，软件工程更注重实践能力。软件工程的程序设计课会更多，内容会更丰富，计算机科学在算法等方面有更深入的教学；软件工程的培养目标是应用型软件工程专门人才，计算机科学培养目标是研究与应用并重的人才。所以二者还是有较大区别，不能简单地合并为一个专业。
回顾5个阶段
1.需求阶段
需求阶段的主要任务就是分析需求，将交互流程转换成原型，将现实世界的对象转换成类。我主要负责类的设计以及类之间的关系，还有类的属性和方法。类不仅要映射到现实世界，还要关注到实现之后的性能，以及数据库表的设计。类设计的合理性对于后端整体逻辑结构影响巨大。在需求分析阶段，我收获最大的能力就是设计类图与类间关系，以及一些挖掘用户需求的能力。
2.设计阶段
设计阶段的主要任务是系统设计和数据库设计。数据库表并非直接对应类，还要考虑到查询性能、数据库设计范式、是否有数据冗余。由于是第一次做系统的数据库设计，所以在这方面反复推敲了许多遍，在后期实现的时候才深刻体会到数据库设计多耗时是很有必要的，避免了后期实现返工。数据库设计为后端实现服务。
系统设计大多数是顺序图、活动图设计，属于面向交互过程设计。系统设计主要为前端服务。
3.实现阶段
实现阶段我最大的收获就是较为熟练地使用springboot框架，对MVC软件体系结构有了深刻的理解，并且学会了写接口文档，懂得Android、web前端、后端之间是怎么相互调用的。我用springboot实现了后端的衣柜部分和图片上传接口，难点有上传衣物图片、路径拼接和上传图片大小限制等。springboot的特点是用注释简化代码，简化数据库操作，并且集成了一些常用的功能（通过配置文件设置）。使用springboot框架以后再理解一些原理，就会对前后端通信、报文头、json等概念有感性认识，进而更好地读懂源码，比原生的方法更容易理解。
4.测试阶段
因为我负责的是后端，所以收获的是后端的测试方法。借助本学期的知识，对接口进行了黑盒测试（因为基本没有if分支，所以没有进行白盒测试）。划分等价类很经常会遗漏，例如不规范的值，而且测试数据要覆盖尽量多的有效等价类，尽量少的无效等价类。除了黑盒测试，也有使用到自己的经验，算是静态测试。
5.发布阶段
发布阶段需要发调查问卷，方便获得用户体验反馈。用户的反馈结果可能是用户体验情况、程序bug或者其他对下一步修改有指导性意义的说明。
理解与心得体会
1.个人项目
一个人编写项目规模需要关注的东西不少，所以在为编程实现做准备工作时，往往需要列出计划表作为提醒，当时是采用了PSP。独立编程的项目一般不会过于庞大，开发周期不长，太过于精细的计划反而会降低效率。独立编程可以按照个人习惯来规划每个阶段的时间。
词频统计作业当中数据结构是最需要斟酌的部分，用什么类型的数据结构关乎程序的性能。这次作业对性能要求高，我就将大量的时间用在对数据结构以及算法的比较和选择上。是直接用正则表达式匹配，还是说用暂时保存的方式循环读取；是用hashMap还是TreeMap。以上类似的问题都是在性能方面做考量。
此外还有一些细节易于遗漏，比如读取文末单词的时候往往会考虑不周，误将其作为单词统计，这些就是边界值分析法要考虑的事。当时没学软件测试都是用经验观察，现在如果再写一次词频统计，就可以用到白盒测试以及黑盒测试了。
2.结对编程
结对编程的好处是两个人可以互相弥补不足，帮助另一方查看bug。我本身负责后端，后端最主要的还是CRUD和一些逻辑处理。在这个阶段养成了写接口文档的习惯，由于模块化的测试，使得前端在调用接口时几乎没有bug。
论文查询给的完成时间并不长，所以当时前后端并行开发，并且每天交流完成进度，PSP表格也提供了很好的计划支持。在这个过程提高了学习能力，因为之前也不会springboot框架，所以学习成本也算在PSP之内。经过这样一次的学习，其他的框架也可以触类旁通。
后期对论文查询进行了优化，在数据库字段上添加索引或增加视图来提高查询效率。总体流程就是设计————>实现————>测试————>优化
3.团队项目
团队编程是整个软件工程课程收获最大的项目。开发方式类似瀑布模型，前一个阶段做完才开始下一个阶段。以前期工作要完善，才有利于后期开展，本学期团队编程每个阶段的返工次数太多，就是时间充裕的时候没有合理利用，ddl开始修改遗留的问题。合适的计划是开发的第一步。
经过一个较大项目的开发，对业务流程更有把握。步骤细化为需求分析、系统与数据库设计、alpha和beta冲刺。UML和软件测试的课程内容在这里面得到应用。影响最深的是数据库设计，衣物和搭配之间是一对多放在一个表，还是以多对多关联的形式存放，这个组内争论了很久，目的是防止数据冗余，符合设计范式。
编写图片上传接口时出现了一张图片能够上传，但是两张图片就上传不了。根据后端报错查找的方法都不能解决问题。就猜测会不会是图片大小超过上限，修改配置文件后发现果然是这个问题。对于编程人员而言，当报错粒度很大时，只有借助经验才能解决问题，进步的方法就是多编程、多进行软件工程实践。
个人技术总结
概述：用户上传图片需要勾选多张，快捷批量上传。Spring Boot框架继承了Mybatis、简化了配置，实现上传图片非常容易。
