回首往昔，更进一步
| 这个作业属于哪个课程 | 2021春软件工程实践 | W班 (福州大学) |
|---|---|
| 这个作业要求在哪里 | 软工实践课程总结 |
| 这个作业的目标 | 软工实践课程总结 |
| 其他参考文献 | 无 |
回顾与总结
一、提出疑问的博客
二、过去的坑
-
关于代码规范的一个疑问
过去，我对第四章4.2中“断行与空白的{}行”中提到的标准我表示不赞同，并且认为格式C更优于格式D（C是{不换行，D是{换行）。
现在，我认为不管是哪种标准，都是可接受的，正如汪老师所说的，重要的是在团队开发之前确定代码规范，确保团队成员代码风格的统一才是最重要的。团队每个人写的代码如果规范不一，那么整体代码看上去会变得杂乱无章。
-
“从用户的角度考虑问题”具体可以有什么角度？
过去，我对第十二章12.1中“从用户的角度考虑问题”感到疑惑，并且自己去查找资料。一是从书后内容找到了“尽快提供可感触的反馈系统状态”、“用户有控制权”、“一致性和标准化”这些原则。二是网上找到了几个考虑角度：控制感、归属感、惊喜感、沉浸感。
现在，我通过需求分析、发布时的自我感受和收集到的数据进行分析，对这个问题有了更深刻的体会。就拿我们团队的项目举例，“尽快提供可感触的反馈系统状态”，发布信息成功后，需要有个提示信息，提示用户已经发布成功，否则用户无法立即得知自己刚刚发布的信息是成功发出去了还是失败了；”一致性和标准化“，对于同一类事物我们需要统一命名，在首页的二手、任务、活动，在”我的“和”收藏“处，依然命名为二手、任务、活动，有明确一致的称呼；”惊喜感“，我们在发布的时候可以自定义标签，用户可以根据自己的需求自定义标签，也可以根据自己的需要搜索、筛选自己想要的物品、任务、活动。
-
关于书本第十三章“验收测试”中“可用”→“预览版”的疑问
过去我通过查询资料得出来的结论如下：
预览版：尚未稳定的测试版。主要用于软件未来版本的改善与修正。
正式版：总结了之前预览版的BUG并修复完善后的版本。
通过这个定义，大概可以推出一个流程：经过测试确定“可用”→发布“预览版”供用户使用→通过反馈收集测试过程没有发现的BUG问题→修复收集到的BUG信息→修复完毕后发布更加完善的“正式版”。现在，我对这个问题有了更新的看法。正如汪老师在评论所说的，测试版虽然近似正式版，但毕竟还有差别，其中缺少了用户实际使用场景的测试（通常说的β测试）只有经过这个阶段的测试，产品才能过渡到正式版。在编码阶段，虽然已经产生了可用版本，即测试版本，但是因为还没有用户真正在使用，没有实际场景的测试（虽然也有10+个人使用），我们的小程序也只是处于一个测试版。而在发布阶段，我们先把测试版本发布，有了用户实际使用场景，并通过用户使用后给予我们的反馈，我们对存在的问题或需要改进的地方进行了修改，最终才实现了“测试版”到“正式版”的蜕变。
-
书中对于“要成为领域的专家，才能够创新”的反驳，我有其他的看法
过去我和书中观点一样，也不赞同这句话，但我还有其他的看法，创新与是不是领域的专家并没有必然联系。你不是该领域的专家，就能更容易在该领域创新，这句话也显然是错误的。透过现象看本质，你会发现，创新成功的人，最重要的一点是打破了思维定势，只是对该领域了解越深的人，就越容易陷入思维定势罢了，因为你对这个领域太过于了解。所以这个迷思的本质我认为应该是：谁能打破思维定势，谁才有可能能够创新。
现在，我对这个问题看法有了一个新的角度。我认为要创新，打破思维定势是必要的，而打破他的方式，可以是学习其他领域的知识，尝试用其他领域的思维方式去创新。之所以我会这么想，是因为一开始我是学习后端的，但是因为团队的需要加上自己也想学一下前端，所以项目开始后，我开始学习前端知识。通过前端的学习和实践，从侧面更了解了后端应该、可以做哪些事情，也学会了从前端的角度去思考后端，而不局限于后端。 -
作为团队的一个普通成员，要如何顺利的完成阶段的过渡？
过去我的总结是：
萌芽阶段：尽快适应新的团队环境，尝试去了解其他成员，并弄清自己的定位，积极配合领导开始最初的工作。
磨合阶段：如果自身属于技术能力较强的人员，可以适当发挥自己的技术领导能力；注意与队友共事、交流的方式是否存在不妥；不要惧怕团队合作，加强自己的自信心和热情；碰到确实无法解决的困难，敢于寻求帮助。
规范阶段：团队的规矩已经定下，尽量不要试图打破规矩；时刻牢记团队的目标和决心；承认成员之间的差异性，并且要学习尊重成员。
创造阶段：（这个不清楚）现在，在亲身实践过后，我对原本的总结没有异议，但是有新的补充：
萌芽阶段：如果领导确实有安排的不合理的地方，可以提出适当建议。
磨合阶段：如果团队的交流存在障碍或者阻力，要尽可能解决，否则会影响到整个项目的进展，对项目有疑惑也可以提出建议。
规范阶段：每个成员需要把项目当做是自己的东西，而不是别人的东西。
三、做中学
-
需求
需求分析，在这个阶段就要密切关注用户的需求与动向。要首先站在用户的角度去做分析，用户需要什么，用户缺什么，用户想要看到什么。在这个阶段就要收集用户的建议，做调查，针对用户的反馈与建议，调整我们最初的需求，我们的软件是做给用户的，不是我们自己的，所以用户的需求、建议才是重中之重。问卷是个很不错的收集途径，而数据是最有力的话语。
-
设计
我第一个体会就是，我们之前学习的课程，例如UML、设计模式、数据库，这些课程的知识，是切实有用而且是必要的，在设计这个阶段就体现出来了，以前课程上更多的是学习理论知识，而设计这个阶段，就是把之前在这些课程中学习到的知识，转换成实际操作。类图设计、数据库设计、接口设计，种种都需要专业知识的辅佐才能够进行下去。在类图设计的环节中，类图要画的尽可能详细一下，而且要多次复审，是否有不合理之处，还可以思考能否用上什么设计模式来辅佐设计。在数据库设计环节，可以参照前面设计的类图进行，同时，在数据库设计过程中，遇到不合理之处，也可以反过来修改类图。在做大项目的时候，要充分考虑数据库多对多关系的处理，可以适当建立一些关联表来联系不同表。
-
实现
实现阶段，前端我们做了小程序端和web端，小程序端是重头戏。我觉得这个阶段我最大的收获还是学会了小程序开发跟前后端交互，小程序开发算是新学到的一项技能，而前后端交互应该算是学会了一种方法，因为前后端交互不管是小程序端还是web端等等都是必要的，通过请求后端接口获取json数据，并且使用数据进行渲染。
-
测试
测试阶段，正好这学期学习了软件质量测试这门课，把这门课学到的黑盒测试、白盒测试以及系统测试学以致用，第一次用专业的测试方法去测试项目。也学会了小程序的真机调试，用它特有的调试方法，配合学到的测试方法进行测试。
-
发布
发布阶段，真的是吃了很大的教训，因为α阶段有尝试发布过一次线上版，所以觉得没有太大的问题。后面β阶段要发布的时候，却被审核告知内容涉及信息发布，不能申请个人小程序，给我们的发布造成了极大的麻烦。第一次做小程序，精力大部分花在了设计、编码、测试上，对发布的准备没有做足，以后做其他项目的时候，也要吸取教训，发布也是提前做足准备才可以，去了解发布需要什么，准备好发布的条件。
四、心得体会
-
个人项目
- 养成好的代码习惯十分重要。这个时候才有的代码规范的概念，在编码的过程下意识地遵守自己定下来的代码规范。
- 性能问题很重要，代码优化不好的话，面对数据量爆炸的时候，程序可用性就会下降很多。
- 测试很重要，编写单元测试很重要，错误要早发现早解决，到后期才发现问题的话，就要付出数倍、甚至数十倍的代价去解决。还应该注重测试方法的使用，白盒测试、黑盒测试、集成测试等的方法都要学以致用。
- 要善用GIT版本控制工具，对代码的维护、协同开发有很大的帮助。
- 平时做其他事情也可以借用PSP表格的思想，对自己要做的事情做预期的规划，可以提高效率，在事后也更容易发现自己的问题。
-
结对编程
- 讨论很重要，因为不是一个人在做，在开工前就要讨论好一些重要的问题，规划好整个项目，不能走一步算一步，这样的话效率太低，小项目还好，项目一大马上玩完。同时，可以集中两个人的看法，求大同存小异。
- 遇到问题可以上网查找资料，还可以找队友商量解决方案，1+1＞2，两个人来解决一个问题，效率要高得多。
- 分工要做好，谁做什么，要提前安排好，工作才可以有序进行。
- 学会看官方文档是非常重要的学习方式。第一次开始系统的学习前端，开始通过看官方文档慢慢学习，收获颇丰，更重要的是掌握了一种学习方法。
- 每天的目标也很重要，给每天设定一个目标，有条不紊的进行，才不会到最后才匆匆忙忙完成。
-
团队项目
- 编码前的开会十分重要，在开会的时候要尽可能把可能存在争议的问题、需要统一规范的问题给解决了，把分工做细（适当），确保每个人都有明确的目标去做。
- 成员之间的合作很重要，这点在交互的时候尤为突出，交互的时候可能涉及多个人的代码，要解决交互中出现的问题，成员之间需要密切交流并且耐心地面对可能出现的问题，我很庆幸我们团队内部氛围很不错，大家都合作的很愉快，也都很有耐心。
- 很多感想体会已经在团队博客写了，这边就不再复制粘贴，最后，很感谢能成为“那你能帮帮我吗”团队中的一员。（我怎么说了那么多很重要）
个人技术总结
概述：当小程序端需要请求的数据特别多，但是不要求一次性显示出来的时候，可以使用分页，在需要的时候再请求下一页内容。
