软件工程实践总结&个人技术总结博客
| 这个作业属于哪个课程 | 2021春软件工程实践S班 (福州大学) |
| 这个作业要求在哪里 | 软件工程实践总结&个人技术博客 |
| 这个作业的目标 | <写上具体方面> |
| 其他参考文献 | .... |
一、软件工程实践总结
1.1 问题回顾
-
点此跳转到《软工实践寒假作业（2/2）》
-
回顾曾经提出的问题，发现有些尚存在疑问或没有新的看法，这些问题是问题一、二、三；对于已解决的问题四、五，前者是通过实践有了自己的理解，后者则源自助教的指点。
问题一：在《IT行业的创新-创新的迷思（5-6）》中，迷思之五部分有这样一句话：“70% 的创新者说, 他们最成功的创新, 是在他们的拿手领域之外发现的。”，虽然文章中举了些例子，但我对这个比例还是有疑问。
按我个人的经验，一个外行人如何能在其他领域创新呢，在某领域创新难道不需要精通这些行业的知识吗？就算真的出于某些偶然的因素，他做到了，但这个比例也不应该是70%啊，难道大部分创新都是偶然？鉴于个人观点的片面性，我就这句话百度到了几篇相关文章博文，其中有赞同的，也有反对的。但并没有直接证据说明这句话的对错。
我对这些看法作的总结如下:
支持:“当局者迷”，领域内的专家由于拘于熟悉的知识而欠缺新的思考，往往不知如何突破。而领域之外的执着的人却会因为一个想法而刨根问底，不懈追求，最终创造专家都想不出来的新东西。另一种支持的观点是这70%的创新中部分是商业模式的创新，不关乎核心技术，正如《创新 - 王屋村的魔方们》中二柱同学的做法。
反对: 创新应该基于对该领域的深刻理解与知识储备，就好比一个小学生他做不出高数题，但有的题目他可以蒙出答案。
问题二：创新的时机跟黄金点游戏有关联吗？
- 我看了《创新的时机 – 黄金点游戏》这篇博文，博文中邹老师谈到了黄金点游戏以及对这个游戏的几点领悟，但是我觉得跟创新的时机没什么关系。关于时机，“只先一步”部分有这样一段话：“那些成功的企业只是比大众的平均值先走了一小步（平均值 * 0.618）, 就是这一小步, 让大部分人看到了产品的“相对优势”从而接受产品。关于技术创新, 一些趋势（例如社会网络），大家早就看到了, 也有一些产品推出, 但是往往最后成功的产品成功在时机上。”，“Technology Hype Cycle”部分也提到：“说到时机, 任何新技术都有一个自身发展的规律，Gartner 的Jackie Fenn 写了一个很有意思的报告, 提到了Technology Hype Cycle。”我对这两部分的理解总结为：新产品在合适的时机推出才能获取成功，此前这个产品可能经历了几个发展换代阶段。但我觉得创新是创造新产品，创新的时机肯定是领先于产品推出的时机，正如文中说的：“做前沿研究的人, 可以早于其他人很多年提出新想法, 但是这些想法一般都是在“Innovator” 那个圈子里有影响, 这些想法要等若干年才能由成功的企业家看准时机推向大众市场。”，所以我认为黄金点游戏是跟推出新产品的时机有关联而不是创新的时机。
问题三：软件创新的出路真的是“走进作坊”？
- 邹老师在《软件工程讲义 9 创新的出路 走进作坊》中对于软件创新的出路提出了“走进作坊”的观点。原文中有这样一句话：“这些好的作坊, 都有这些核心特性: 从小事做起, 讲究质量, 信用, 对产品负责, 对工作自豪。”，我学识有限，对这篇文章笼统地理解为：创新的出路是作坊是因为好的作坊有匠人精神。感觉我的怀疑没什么依据，要说源头大概就是如原文中说的“哪里都有盗版, 哪里都有抄袭, 哪里都有竞争”，上网去搜索出路什么的大部分都是讲创新是出路，缺少实践的东西。只能说直觉告诉我走进作坊不错，但实际操作起来把它当做创新的出路真的可行吗，是不是大家一起“走进作坊”，我国软件业的创新就能搞起来了呢？
问题四：如何应对“主治医师模式”?
- 我读了《团队和流程》这篇博文，里面谈到了几种团队模式和软件开发模式。原文中有这样一段话：‘主治医师模式的退化: 在一些学校里, 软件工程的团队模式往往退化为“一个学生干活, 其余学生跟着打酱油。”’，即将面临软件工程实践课的组队，由于能力、性格的不同难免会形成各种团队模式。如果有幸遇到这种模式，那么最佳的办法便是各司其职，带头的“医生”应该根据成员能力的不同分配合理的任务，其他成员所要做的便是好好配合“医生”，除自己负责的任务外，在其他与技术无关的任务方面尽量提高效率（如：撰写心得体会、计划安排，积极参与讨论、会议）。在这种技术水平相差较大的情况下，带队的“医生”承担较多的任务是不可避免的，能力较弱的应该避免“强出头”给团队带来不必要的麻烦，实在不会的问题应及时请教，当然，也要杜绝划水的现象，有余力的话主动承当一些任务。
问题五：什么是单元测试的自动化?
- 读过《单元测试&回归测试》这篇博文，谈到了单元测试的自动化。原文是这样的:“另一个重要的措施是要把单元测试自动化，这样每个人都能很容易地运行它，并且可以使单元测试每天都运行。每个人都可以随时在自己的机器上运行。团队一般是在每日构建中运行单元测试的，这样每个单元测试的错误就能及时被发现并得到修改。”，单元测试的自动化顾名思义，就是单元测试能够自动运行，所以，像用Junit编写的需要主动运行的单元测试都不算自动化的单元测试，自动化可以针对你每次提交或者打包的时候，自动运行你写的单元测试，并生成结果。
1.2 五个阶段的收获
1.2.1 需求
-
需求分析阶段我个人承担的任务比较少，主要是参与讨论用户需求，试用设计出的原型，以及原型答辩PPT的设计。
-
由于是前几次的团队作业，需求分析阶段提升的能力大概就是团队协作及文档编写能力。
1.2.2 设计
-
设计阶段我的任务是功能模块设计，由于我们的系统比较特殊，功能划分起来比较容易，因此任务主要还是在于文档编写。
-
设计阶段提升的能力大概还是文档编写能力。
1.2.3 测试
-
测试阶段我主要负责测试web端的功能，编写功能测试用例，录制自动化测试脚本以及部分功能的压力测试。
-
看似测试阶段我负责的东西比较多，其实大部分任务还是比较简单的。收获的话分为两方面，一部分是频繁的测试、及文档编写工作磨练了我的耐性，使我更加细心；一部分是学会了用Jmeter进行简单的并发测试，这个我在个人技术博客中会详细说明。
1.2.4 发布
- 这部分要说收获的话谈不上，主要是检查项目完成情况，需求调研，感受了一波项目结束的喜悦。
1.3 理解与心得
1.3.1 个人项目
- 个人项目进行的时候还未返校，那时候很多概念知识才刚接触，觉得相当的麻烦。我自己不是一个足够自律自主的人，能够独立坚持并完成作业，我觉得真有种坚持就是胜利的感觉。
1.3.2 结对编程
- 我与结对队友只完成了结对作业一，由于两人都比较菜，秉着与其做个虚有其表的东西，不如不做的想法咕掉了结对作业二。两个人协作当时对我来说还是比较陌生的，我个人比较擅长自己解决问题，经历了结对的过程，我觉得比较重要的事情一个是沟通，双方都要对自己的工作及任务进展有清楚的认识，一个是自己能够承担工作固然重要，但更为重要的是信任队友，学会将一些工作交给队友完成。
1.3.3 团队项目
- 团队项目可以说是历时最长的一个项目了，团队项目中出现的问题也是最多的。我在团队中的角色算是半个“打酱油”的吧。
我觉得团队项目，组长的工作是尤为重要的，作为团队的领导人，除了因人而异分配任务，对任务的进展还需要有一定的把控，不然很容易出现大部分成员划水，最后赶工做任务导致的问题密集发生现象；组员的话则是要积极主动，自己要有一定的规划，不能等着组长来调配自己；还有一点是沟通交流，埋头苦干固然重要，但是也应预防沟通不当，导致先前的工作付诸东流的惨状，即使没有问题，工作相关的成员也应该互相了解一下情况，特别是前后端之间的沟通。
二、个人技术博客
-
点此跳转《使用Jmeter进行并发测试》
-
概述:
该技术是使用Jmeter模拟多用户并发请求的场景，并有具体的测试结果，主要用于系统的压力测试，学习该技术是为了给系统做压力测试，并且进行适当的调整，相关用例也可以作为自动化测试用例使用，该技术难点主要在于token的获取。
