不忘初心，牢记使命——软件工程实践总结
| 这个作业属于哪个课程 | 2021春软件工程实践|W班 (福州大学) |
|---|---|
| 这个作业要求在哪里 | 软件工程实践总结&个人技术博客 |
| 这个作业的目标 | 不忘初心，牢记使命 |
| 其他参考文献 | 无 |
第一部分：课程回顾与总结
1.1 回顾自己列出的5到10个问题：尝试解答、继续分析、提出新问题
以前提问题的博客链接：寒假作业2/2
Page33 1.2 提到了软件工程是什么?
软件工程是把系统的、有序的、可量化的方法应用到软件的开发、运营和维护上的过程。
先前思考：本学期也开始学习到《设计模式与软件体系结构》这门专业课，特别对北京大学杨芙清老师的《中国软件工程历程与发展》进行学习，进一步理解了软件工程的定义以及软件工程教育为中国软件传业发展提供了有力的人才支撑。也回想到寒假作业1/2中我自己写的为什么当初选择软件工程专业的问题。在我看来，软件工程是应用计算机科学理论与技术以及工程管理原则与方法实现满足用户要求的软件产品的学科。
新的理解：通过这次课程，可以说是亲身体会了软件工程的全流程，包括需求、设计、实现、测试、发布五大部分，更深刻体会了软件工程作为一门工程的实践性、必要性。
Page69 3.1 个人能力和衡量与发展，提到了软件工程师如何衡量、证明自己的能力？引用了一段别有风趣的回答：
问：职业篮球队员都有很详细的记录说明，作为一个职业软件工程师，你有类似的数据说明你所有的职业活动和成绩么？
答：嗯……没有。唯一的数据是，我的“上场时间”还是挺长的，而且经常打加时赛——加班。什么样的数据能说明一个软件工程师的技术和能力呢？衡量能力有哪些参数？没有量化的指标，就谈不上衡量和比较。我们还是看看搬砖的伙计们，关于工作量，他们：有多少块砖？要搬多远？他们也有简单的指标衡量工作质量。多快搬完？搬的过程中损坏了多少块砖？
先前思考：感觉职业篮球运动员和搬砖的伙计都不能很好的衡量或证明一个软件工程师的能力。 项目/任务有多大？花了多少时间？质量如何？是文章后续PSP认为的几大因素。这让我联想到了之前在知乎看过的如何在面试中证明自己是优秀的软件测试工程师的问题，就包括了基础的软件技能、测试流程熟悉、问题分析敏锐、善于总结分享等。个人认为，一个软件工程师的能力必来源于不断的学习，项目、博客、github等正是对你所掌握能力的一个证明。只要功夫在，不怕没饭吃。
新的理解：软件工程师如何衡量、证明自己的能力，经过这次亲身实践，在一个团队中不管从事什么方向，只要你有心或你有才华，总能展现出属于你的闪光点。只有你足够努力，你总能见证你优秀的那一天。
Page181 8.3 获取用户需求——用户调查提到了软件需求阶段的获取信息手法
开发软件时，我们总想知道用户到底想的是什么，对各种功能的偏好是什么，掌握这些信息，我们就可以按部就班地去满足用户的需求。大家可以靠直觉，靠老板的命令，靠互联网上传来的各种信息，靠拷贝其他软件，靠其他不靠谱的手段……当然我们也可以靠一些经过实践证明行之有效的办法，其中许多具体做法既可以用在软件需求的收集阶段，也可以用在测试阶段。
先前思考：这反映了从用户需求到软件设计的这么一个过程，大学阶段对于面向对象分析与设计、设计模式与软件体系结构、软件工程的学习也加强了我对用户需求分析的了解。最近我听到很多人都在讨论产品经理及其定位，当产品经理将公司的战略转化为产品的目标后，就需要从中挖掘需求。这些需求不光是来自用户的，还可能是市场需求，公司内部的需求。当然这只是产品经理众多职责的一个部分，我想这也是产品经理在当今软件开发中如此重要的一个原因吧。
新的理解：正如文章提到的无论是收集或测试阶段，事实上在互联网时代，软件需求阶段获取信息的手法可以说是五花八门，这个部分我也不知道如何用言语来表达，只能说通过软件工程实践，我对这样的思考有了更透彻的认识吧~
Page362 16.1.3 提到经典迷因
好的想法会赢学理工科的同学都比较理性，大多会认为，好的想法当然会赢啦。就像解数学题一样，好的解法当然会得高分啦。好主意一定会把不太好的主意都比下去。但是在现实中，好的主意不一定赢。例如，看看我们日常使用的电脑键盘，作者打赌99.9%的键盘都是这样的布局（QWERTY），但是很多研究者认为下面的键盘布局（Dvorak）更有效率。
先前思考：这便是先入为主对人的影响，经过网络资料的搜索，得出是因为更换成本太高，在“约定俗成”面前，效率完全不构成优势。最近我弟弟一年级做二位数与一位数加减法的时候就有我以前没有学过的“平十法”、“破十法”等，这在我看来就有点打破常规的感觉。在我看来，在软件开发的过程中必定也会遇到各种各样的约定俗成的难以打破的僵局，但这不代表创新越困难，一个能打破僵局的软件产品必定是史诗性的。
新的理解：社会是以人与人之间的纽带构成的，一旦一个东西约定俗成之后，所谓的效率、创新在这个“经典迷因”面前都无法撼动它的定位，软件工程实践也是如此，例如有的“古老”的系统就是由底层代码编写而来，导致其后续的维护等工作变得十分困难。正如江主席所说的“一个人的奋斗固然重要，但也要看历史的进程”，一个史诗性的创新必然伴随着技术的大突破。
Page389 16.1.6 提到经典迷因
这个想法对理工科的同学们来说更是自然不过，很多同学孜孜不倦地跟踪某技术各个版本的细节，津津乐道其中奥秘。一些同学的想法大约是——学习各种科学技术，从本科到硕士、博士、博士后，然后创新、齐家治国平天下。例如，我们看看手机的发展历史，哪一次进步不是技术的进步带来的呢？
先前思考：这引起了我对最近一个新闻热点事件的思考，关于Clubhouse这个软件，“马斯克也在用的 App”，是很多人对这款 App 的最大认知。这已经成为继 Facebook 和 TikTok 之后一个新的现象级社交软件。甚至一时之间，几十款“中国版Clubhouse”都即将面世。这款产品并没有使用多么尖端的技术，在我看来Clubhouse的火爆告诉我们只要精心设计，即使用并不是那么先进的技术也可以打造出爆款的产品。技术的创新固然是关键，但并不是全部原因。
新的理解：和上面迷因提到的一样，像先前思考提出的Clubhouse过去三个月如今已没有多少关注度，如果一个产品或者企业想要获得长久的发展，必然要靠核心技术来维持，这也是国内独角兽企业会持续存在的原因。
1.2 5个阶段中，每个阶段收获最大的知识或能力是什么？
需求阶段：体会到了设计问卷进行需求分析的重要性，了解了NABCD分析。
设计阶段：进一步强化了对Axure等原型设计软件的使用。
实现阶段：首次完整地参与了一个比较大型的web应用程序设计（一开始感觉到最后会做不完），并按照寒假计划比较熟练地掌握了vue.js+element ui的开发，从队友中不管是技术还是团队合作都学到很多。
测试阶段：结合《软件质量与测试》的课程将所学的测试知识应用其中，例如黑盒测试。
发布阶段：通过问卷对用户反馈进行了比较及时的收集，制作了项目的微信公众号相关推文。
1.3 结合自己在个人项目/结对编程/团队项目的经历，谈谈自己的理解或心得
个人项目
完成了WordCount程序的编写，以往只是简单的觉得自己只会老师教的知识，很少自己去学习课外的本领。在个人项目中学会了Git、GitHub desktop、单元测试、性能优化.....等新技术的学习，虽然学习效率低，但最后还是勉勉强强完成了整个项目。体会到了时间规划的重要性，为我在接下来的项目中敲响了警钟。
结对编程
一开始看到这个作业的时候十分的害怕，虽然已经完成了原型的设计（尽管十分的粗糙），但一开始对编码实现中一些功能的实现理解的不是很到位。我的Web基础不是特别的扎实，并因此遇到不少困难，但是有了队友的帮助，我们的大部分问题都迎刃而解。整个结对过程让我受益颇多。通过这次作业也让我们对团队作业更是充满了期待。
团队项目
在alpha冲刺阶段中承担了后台管理页面讨论管理部分和视频管理部分的编写，在beta冲刺阶段中，进一步完善了讨论管理部分的页面，主要是UI和处理页面逻辑部分。在alpha阶段时只进行了简单的页面编写和少部分逻辑，算是比较粗糙地完成了任务。beta冲刺阶段中有对之前的经验教训进行了一个比较好的总结与反思，对前后端交互进行了学习，在编写接口的过程中和队员学习了很多，深感自己技术上存在许多缺陷，需要进一步提高知识水平。同样在此感谢队友们的精诚合作，没有团队的耕耘就没法收获成功的果实！
第二部分：个人技术总结
概述：created是一个生命周期的钩子函数。在实例创建完成后被立即调用。在这一步，实例已完成以下的配置：数据观测 (data observer)，property 和方法的运算，watch/event 事件回调。然而，挂载阶段还没开始，$el property 目前尚不可用。本文将探讨created在使用过程中遇到的一些问题。
不忘初心，牢记使命。
