勇敢牛牛，不怕困难
| 这个作业属于哪个课程 | 2021春软件工程实践 -W班 (福州大学) |
|---|---|
| 这个作业要求在哪里 | 软件工程实践总结&个人技术博客 |
| 这个作业的目标 | 课程回顾、个人技术总结、技术分享 |
| 其他参考文献 | 《构建之法》 |
课程回顾与总结
回顾问题
回顾自己列出的5到10个问题：尝试解答、继续分析、提出新问题
问题博客链接
- 问题1
在进行一个较大的项目时，我们经常会进行合作完成，这样的话就会加快项目的进程，但是此时成员之间交流想法分配任务以及每个人完成任务后在整个项目的整合中会有很多问题，我们如何解决这些问题呢？
尝试解答：就说说这次的软工实践项目，这个项目算是一个较大的项目，至少对于我来说是，然后我们团队在开发过程合作的可以说是相当顺利，各个阶段的任务完成的很不错。这都离不开团队中每个人的努力。现在来说说我们团队间如何交流想法分配任务以及最后的项目整合。首先应该是解决前后端分配问题，组长先请大家发表自己的观点，一轮下来后端人数明显居多，这个时候为了不影响进度就要有人做出牺牲，没记错的话组长由后端改到了前端；其次是任务分配，我们小组采用的是自取方式加组长分配，这样子每个人可以选择自己比较感兴趣的部分，如果重叠的话再进行协商，如果没人领取的话组长在进行分配。能力较强的可以负责较难的部分；能力较弱的可以负责难度适中的部分。都是在学习的过程中，能力较弱的也是可以选择难的部分，不懂的虚心请教并不丢脸。（大家都很积极，我记得alpha冲刺后面我还去要了些任务做，差点给队友都做完了）；最后就是项目整合，我们小组解决的方式是集中开发，这样子能够较好的对接，负责某一后端接口的与负责前端对应部分的成员对接，如果出现双方都解决不了的问题时还可以求助其他成员来更快的解决问题。
渠道：软工实践经历
继续分析与新问题：上面所述的解决方法只是我们小组在软工实践中采取的，那如果是公司内团队，也可以采用上面的方法解决问题吗？对于不同公司不同制度而言，结论应该是不同的吧。
- 问题2
在软件开发之前如何去了解它是否符合大众生活需要？
尝试解答：一个好的软件，很大程度上取决于对要解决的问题的认识，以及如何准确的表达用户的需求，需求分析就是要解决这个问题。访谈、情景分析，编制系统规格说明文档，创建原型等，是获取真实需求了解软件是否符合大众生活需要的有效方法。
渠道：软工实践经历
新问题：除了上述说的方法，我们还有其他方式去了解软件是否符合大众生活需要呢？
- 问题3
用户体验与产品质量为什么会冲突？一个好的软件是应该追求好的用户体验，还是应该所追求好的产品质量，或者是折中？
引用老师的评论：有些bug很少的高质量产品，用户体验却很差。
尝试解答：我记得老师评论过后我还是不能理解，我依旧认为：高质量的产品无疑具有较高的性能和很少的bug，而bug的多少可以直接衡量一个软件的用户满意度，所以高质量产品应该是对用户体验的一个提升，因此用户体验与产品质量应该不会冲突。经历了软工实践，我意识到自己的观点是错的，就比如一个没有bug的产品但是用户玩不明白和一个可能存在潜在bug的产品但是更多的考虑的用户体验，后者肯定是相对“好”的产品，我们设计产品的源于需求，需求来自用户，用户玩不明白，难道设计后是给开发者用的吗，虽然可能可以做相应的用户引导，但是如果产品的初衷就是为了方便，那就不太好说了。对于现阶段我的理解是一个好的软件既要追求用户体验，也要追求产品质量。低用户体验，再好的产品质量也无济于事；低产品质量会降低用户体验。
渠道：软工实践经历
- 问题4
应该根据什么来选择在哪方面追求“专和精”？
引用构建之法：没有人能在学校里掌握所有“将来会用得到的知识"才离开学校.随后马上把技术运用在实践中。工程师应该在实际工作中不断学习和不断成长，根据自己的情况选择在哪个方面追求“专和精".在哪几个方面达到"知道就好”的水平”。
尝试解答：是否可以说我们应该在那些常用知识技能结合自己的能力去做到专和精，要学会运用知识的思想，而不是单单某个具体的主流技术，因为主流可能随时代变化，但真正的原理、思想还是类似的，要学会举一反三才是真正的学明白了。
渠道：软工实践经历
- 问题5
团队中角色与职责有必要自然转化吗？
引用老师的评论：这里所说的角色、职责能够自然转换并不是指要求成员能够胜任任何一种技术，这不现实。更多值得是在团队中担任什么角色应承担相应的职责。
尝试解答：我认为团队中角色与职责有必要自然转化，就好像这次软工实践，原先后端选手居多，组长最后由后换前，在前端位置承担自己相应的责任，这就是角色与职责的自然转化，这可以说时很有必要，有利于保持进度的一致，不会因为哪一端进度慢，最后出现联调来不及的情况（一个例子就是，github实训时有一个组后端人员就两个好像，最后接口对不上）。
渠道：软工实践经历
新问题：如果这种转化确实发生，但是转过去的人对那部分知识一点都不熟悉，对于原来那一部分却了如指掌，那这个转化后的效率真的会比原来的高嘛？
做中学
5个阶段中，每个阶段收获最大的知识或能力是什么？
-
需求
需求分析我参与的并不是很多，但是也学会了站在用户的角度思考问题，换位思考，切身想像用户在使用产品时会希望产品怎样有效的帮助到用户。而不是开发者本身想要什么。以及考虑需求可行性，比如以开发者目前的能力能否很好的实现需求。好在我们处于学习阶段，开发的周期对于我们是充足的，我们可以尝试着学习未知领域的知识。 -
设计
这一块我主要负责的是数据库设计方面，然后在后面开发过程有遇到因为数据库设计缺陷而导致实现部分功能较困难或者说实现起来不是那么通俗易懂，没有必要那么麻烦，导致反过头来修改数据库表结构的情况出现。所以我意识到了这个部分的重要性。同时要注意接口文档同步更改并且及时通知队内所有人（我们组来说相对好点，某同学所在小组修改了接口文档内容没有通知之前实现的人，导致这个人最后做了无用功，使我印象十分深刻！），队内及时的沟通很有必要。 -
实现
这是我第一次较为正式的和团队完成一个完整的项目，实现过程我学会了独立思考，以及通过各种途径寻找好的解决方案，然后可能是负责的部分相对简单，所以有时候闲下来我会去看看队友写的代码，学习了SpringBoot文件上传以及Sa-token、Spring Security等知识，读别人代码其实也是一种学习的途径，走别人的路少踩点坑。同时学会使用阿里巴巴插件规范代码。 -
测试
锻炼了SpringBootTest单元测试的使用，应用了软件质量与测试课程里的部分知识，收获了黑盒测试以及使用JProfiler进行性能测试的能力。其实这几个阶段，队内及时交流都是很有必要的。在接口文档上，不但要明确各个接口的各个参数、返回值以及接口本身的意义，然后任意一方修改接口时，要及时的交流，否则后果可能会多做无用功。 -
发布
微信小程序发布最好提前ddl几天，然后发布后也要进行相关测试，有bug及时修复。
经历的理解与心得
结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得
个人项目
- 通过这次个人项目初步学习单元测试，之前的测试方法都是直接运行程序，十分不便，但是使用单元测试，可以更加方便地对特定代码进行测试（这个程序比较小，当时还没有意识到测试要与开发同步进行）；还学会了使用JProfiler进行性能分析。
- 复习了git和GitHub的使用，较为正式的使用了git工具进行项目管理，再一次感受到了用git工具管理代码的优越性。
- 使用PSP表格进行预估，事后可以更容易发现自己的问题所在。
- 最大的感想就是作业要早点做，不要拖到ddl，意外随时可能发生，早点做既能够降低风险，又能够让老师助教提前点评，发现不足的地方可以及时改进。
结对编程
- 结对作业一（原型设计）：相较于个人作业确实是花费了更多的时间，但换来的是较于个人实现来说整体效率以及质量上的提升，毕竟是1+1>2，一个人不容易发现的问题也许会被另一个人发现，一个人解决不了的问题也许另一个人刚好知道问题所在。这次原型设计是和老同学进行的，过程的分歧比较少，但是实际工作中可能会遇到和陌生的人进行设计，理解方面双方偶尔意见是会有出入，这是需要我们花时间去讨论来产生一个合理的中间方案。
- 结对作业二（网站实现）：这个作业里可以说是完整的学习了Spring MVC的开发流程，从入门到最后较好的运用。但是过程可以说是惨不忍睹，在实现完之后有些配置我依旧是不太明白，配置这些东西我记得把我搞得半死，但是后面JavaEE这门课我较为系统的学习了，现在回过头来想想也就是那么回事，所以理解原理是很重要的，一头雾水的学真的很累。遇到困难多百度，再无法解决求助别人，自己死磕效率真心不高。
团队项目
- 第一次正式以一个后端成员参与一个完整项目，是一个很不错的体验，也是将自学的SpringBoot知识运用的一个经历。
- 合理的分工安排以及时间规划，效率自然就上去了。
- 队内有效的沟通合作很重要，一个Team就要有Team的样子，不能说从头到尾自己做自己的，最后整合的时候问题百出。
- 代码规范要提前规定好，可以看起来比较舒服，也可以方便队友、老师、助教或者其他人阅读。
- 测试要与开发同步进行，否则可能联调会出现问题，会增加不必要的时间成本。
- 心得就是很幸运很开心能够遇到我的队友们，和优秀的人在一起就确实是会进步，学到了很多东西。
个人技术总结
博客地址
概述
一个功能强大且高度可定制的身份验证和访问控制框架
