凡是过去，皆为序章。
| 这个作业属于哪个课程 | 2021春软件工程实践|W班(福州大学) |
|---|---|
| 这个作业要求在哪里 | 作业要求 |
| 这个作业的目标 | 回顾与总结实践历程 |
| 其他参考文献 | 《构建之法》 |
课程回顾与总结
回顾问题
回顾自己列出的5到10个问题：尝试解答、继续分析、提出新问题
以前提问题的博客链接
- 问题1
在软工实践课程中，我们究竟会以怎样的程度让之前、或是下学期所学的知识得到应用？
在软工实践的过程中，我理解到：应用所学的知识与否完全取决于自己。与软件工程实践相关的先修或者本学期同步修习的课程包括：面向对象分析与设计、软件设计模式与体系结构、Web程序设计、软件质量与测试、软件项目管理、人机交互以及基础编程语言课等等。印象比较深的比如：在系统设计阶段应该主动去思考能否应用适合且有效的设计模式；软件质量与测试课学到的（或本就会的）测试手段与度量标准等在个人、团队作业的测试阶段也得到了应用；个人作业对编程基础的小锻炼，结对作业2与团队项目开发也让我回顾了Web程序设计的技术；还有软件项目管理这一过去不常接触到的领域，在项目管理课程中我选用了本次软工实践的项目作为答辩题材，理论知识得以应用到了团队冲刺的管理过程。这些都让我学到了不少东西。
很多东西不是依赖于课程要求你去做，而是要主动思考能否应用得上，并且软件设计本来就要求以上的所有这些东西（还不止）。
- 问题2
《构建之法》第五章开始提到团队合作的重要性，但每个人的开发能力高低各异，因此在以往的实践课中团队工作分配常常是一个头疼的问题，试问作为尚未就业的软件工程学生，该如何更好地锻炼团队分工协作能力？
实践过程中我们团队的沟通是比较良好的，也确实是一个“个人的开发能力高低各异”的小组，分工协作方法简单来说就是一开始每个人提出自己能做到的，主动认领分解后的子项任务。能力较强的同学可以负责较难的技术攻关，多做一点；能力较弱的同学可以负责其他难度适中的部分，查缺补漏。最后每个人的工作量多少也很公正的反映到了绩效评分上。而开发过程中要为人坦承，及时沟通，有不会的大可虚心求教。
通过这些，我觉得我的团队分工协作能力确实得到了锻炼，这大部分也归功于组长和队员们人都很好。具体的在本篇博客的团队项目的经历心得中还会提到。
- 问题3
关于PSP表格的疑问
对于在本次作业中第一次接触到的PSP表格，它有何意义？
引用老师的评论：之所以第一次作业就引入PSP，并在每次作业中要求PSP表格，就是让同学们在一次次作业中学会任务分解、事前对子任务预估时间、子任务安排、事后回顾总结，这样的工作习惯。
谈到工作效率与时间管理，这涉及到在书中学到的一个“二八法则”，其中时间维度的解读是：“花20%的时间会产生成果的80%。”，这就告诉我们把有限的时间，拿来处理最为重要的事情，不要浪费时间的重要性。而PSP表格便是进行这一步的一种工具，在实践中呈现为我们记录每次的工作环节，预期计划与实际耗时，从而度量我们的学习、工作效率，总结出现的问题（效率低下的环节），吸取有效的经验（做得较好的部分）。
这与其实早在中学时代就出现的，我们统计做考卷各类题目的用时，考察自己哪个模块薄弱，不断改进以求更优异成绩的环节是一致的，只是现在应用到了更实践性的事物里了。
- 问题4
TDD通过明确的流程，任务分解、列Example，让我们一次只关注一个点，思维负担更小。且先写测试可以帮助我们去思考需求，并提前澄清需求细节，而不是代码写到一半才发现不明确的需求。
但是我还是不太懂，我的困惑是:
如何做任务分解？第一步如何开始，实践经历较少，脑袋中有点小空白。
通过其他课程与软工实践的配合学习、实践。我了解到了三种任务分解方法：类比方法、自顶向下、自底向上。以及在软件测试中还有驱动模块、桩模块这两种辅助模块来配合渐增式集成测试。
在实践中我们多采用自底向上的组装方法来进行产品结构设计、任务分解等；也有参考过往届优秀小组的经验，结构设计或者任务分解方式、结果，我觉得这可能算是类比方法吧。个人觉得第一步最重要的是要明确自己要做什么、能做到什么。
以下经验摘自个人作业2评论区：
ranh941：
接到任务后，第一步是理解任务，这个任务是做什么，你的理解与你的上级的理解是否一致，这个很重要。你需要主动去跟上级沟通，沟通之前需要把你要沟通的材料准备好，比如你的疑问、你对任务的理解、你也许要做的尝试，同时需要注意到任务的截至时间；
第二步则是初步分解任务，按照自己的理解将任务拆分，按技术难点或者按业务逻辑，再根据任务时间倒排你拆分的子任务，再将拆解的结果主动报告给你的上级，同时自己也按拆解的任务表推进任务；
第三步则是按照拆解后的任务表推进任务的执行，在执行的过程也可以对已经拆分的任务再进行调整，这都是合理的。
- 问题5
《构建之法》第六章为我们介绍了敏捷流程。试问在软件开发行业中，敏捷开发的可行性高低如何？应该更适合配合默契，经验丰富的程序员才对？（采用敏捷开发，开发团队的人员素质要求比较高。敏捷开发的首要任务是快速，目前提出的"全栈软件工程师"，它要求软件开发人员在开发的各方面：从需求，设计，编码，测试一直到部署都要求是行家里手，可以减少因彼此沟通带来的时耗，这才能保证他在一个Sprint中能独立完成产品中某个特定的任务。显然这样的软件开发人员的素质一定要求很高的，而在软件开发行业中，人员流动率高，新手多的情况下，要做到这一点似乎是比较困难的。 这应当是敏捷开发的缺点之一。）
当时提出这一问题主要还是觉得自己能力不足，到了结对或者团队项目中会拖后腿，跟不上节奏（在github实训那天确实发生过）。现在的体会就是：素质有高低对比，能力有不足之处是必然的，不能因为自己不会做什么什么就害怕、完全不去做某事。体现在计算机专业就是：不能因为自己不会一个技术，就不敢去学习、不敢去编程（好像在哪里看到这个说法，忘记出处了）。
今后不管处在什么领域，遇到不擅长、不会的事物的情况一定很多，且肯定是有没法逃避掉的工作等，此时，养成主动学习、终身学习的习惯才是解决问题的关键。
做中学
5个阶段中，每个阶段收获最大的知识或能力是什么？
-
需求
需求分析阶段需要定义一个用户场景，关键不在于设计者本身想要做什么，而在于用户想要什么；生活或工作中的某一环节遇到了什么困难；现在有怎样的解决方案、效果如何；我们的软件产品要提供怎样的解决方案以、预期结果如何。还有做用户故事分析时，时间地点人物等关键信息要尽可能明确，不要太宽泛随意或者模糊，这样对后续设计参考有帮助。 -
设计
自底向上的方法，问题4中有提到了。将我们离散的功能需求一一列出，看看哪些最小子模块可以结合在一个模块/界面里，或者有无冗余可删去的，最终逐层向上组装，完成功能模块层次的设计；
还有学到了就是数据库设计阶段一定要提前想象想象实现阶段可能会遇到的坑，多阅读阅读所选用技术、平台的文档，看看是不是有些数据难以获取、微信官方接口如何使用等，否则后期会挺头疼，要返回去做改动；后端某处做出改动之后，要注意接口文档保持一致性（以及通知队内所有人）。 -
实现
收获最大的就是vue语言的编写锻炼，采用UniApp+UView（基于Vue）来编写了小程序前端，完成了前期的界面实现与后期的接口对接以及修复缺陷工作,熟悉了vue中的生命周期、路由跳转、引用、缓存等基础。还有问题2与问题3中提到过的，时间管理与分工协作沟通能力得到了锻炼。其次，掌握了teambition的使用。 -
测试
锻炼了单元测试与自动化测试工具（前端：Selenium IDE）的使用，应用了软件质量与测试课程里的小部分知识和技能，收获了黑盒测试、系统测试（压力与性能测试）等经验。以及锻炼了通过真机线上测试，发现并复现bug，调试并找到问题根源所在的能力。 -
发布
学到了：微信小程序发布前夕，涉及到用户隐私获取、用户发布文字、图像、视频等信息、商家资质等功能的政策一定要提前了解，不能等要发布了才去研究；可以提早deadline数天尝试提交审核并发布线上版本，这样出现意外问题可以及时解决，对用户体验调查也有利。
理解与心得
结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得
个人项目
部分语句摘自个人作业总结
- 作业开始的前几天就实现了题目的输出正确性要求，但代码跑得很慢，为了优化性能，做了很多有用或无用的尝试，深感最开始的设计中，选取简单与效率兼备的解决之道很重要。后来在评论区老师的指点下，认识到了自己的不足（滥用API），也对代码进行了改进，感想就是个人作业可以提前截止日几天提交，让老师助教多来点评点评，发现不足之处，这样在最终提交前还有时间进行改进。
- 自动化的单元测试虽方便，但编写代码时候接口的设计还是会很头疼，这又涉及到最开始的需求分析、设计上了，即一开始决定数据结构、参数如何传递时就要考虑好之后的扩展性，或直接从编写单元测试开始。不然一直返工、改来改去很痛苦。
- 严谨是一件非常重要的事情，即使是字符统计中的\r\n，有效行统计中的空行判断等小细节也是几经思考，尝试了好几种处理方法才得到了最终的代码。
- 个人作业最终得到了80多的分数，在正确性方面扣掉了，可能是正则表达式写的不够完善，没有考虑到所有的可能情况，因此在一些随机量大的测试样例中，结果没有全对。心得就是：黑盒测试还是不要做的太草率了，可以参考软件质量和测试课程中的等价类划分法、边界值分析法等，简单应用到这里，且要多思考特殊情况。既锻炼了测试能力又能提高正确率。
结对编程
部分语句摘自结对作业总结
- 结对第一次作业，原型设计：结对编程，潜藏于每个环节中的“沟通”这一动作，相较于个人作业要花费更多的时间成本，但以此换来的是整体效率上的提升。两个人互相盯着，一有问题就马上指出，帮忙修改，比预想的更快完成了，因此认为这个交换是值得的。
- 结对第二次作业，网站实现：遇到困难多查开发手册、开发者社区；遇到无法逾越的困难多求助别人，互帮互助，自己死磕效率不高。因此两人结对，在git上可能会遇到一些冲突解决有关的小问题，但开发上的问题就好解决了。有些东西就是自己打死都做不出来，队友用同样的时间一下就完成了；遇到了坑、bug，两个人可以从不同的方向尝试解决它，总会成功一种的，效率较高。一旦解决了坑，那么心态就会比自己一个人死磕要好点。
团队项目
项目各阶段历程的心得体会在本博客“课程回顾与总结”的“做中学”模块已经叙述了，接下来补充总体上的感想：
- 没有必要只做文案与项目管理相关的工作，每位组员都可以尽量地参与到代码编写里去，不会就学一点。这样更有参与感。
- 很多作业，实现过程和最终结果的重要程度是同样的。因此有时不必纠结于成果的完美性，也要考量过程的严谨性与合理性、记录与总结，留下可供参考的经验。
- 最终分数其实只是你努力的一个附带成果，真正的收获都在过程中（锻炼代码能力等）。deadline赶不及就赶不及吧，没必要做抄袭或者超时提交等事情，对团队不好对自己也不好，最终老师和助教都不会太为难同学的（分数上）。
- 同上条提到的，不要做不诚信的事情。
个人技术总结
博客地址
概述
用户在投诉的时候可以拍摄、多选上传最多5张的照片，达到上限时，隐藏上传按钮；用户可以预览、删除所选图片，添加或删除后的图片数和预览小图要及时、正确地反映到界面上；最终图片与投诉文字一起提交。难点：在已有组件的基础上改进为自己想要的样子。
