软件工程实践总结——我的寻宝之路

221900108-侯沛延学生 2022-06-26 21:49:21

这个作业属于哪个课程	软件工程2022年春-F班
这个作业要求在哪里	软件工程实践总结&个人技术博客
这个作业的目标	课程回顾、个人技术总结
其他参考文献	《构建之法》

第一部分课程回顾和总结
1.1 问题回顾——对于旧问题的新看法
1.1.1 问题提出的博客地址
1.1.2 旧问题，新思考
1.2 做中学——每阶段的最大收获
1.2.1 需求阶段
1.2.2 设计阶段
1.2.3 实现阶段
1.2.4 测试阶段
1.2.5 发布阶段
1.3 项目心得——个人、结对、团队项目经历的体会
1.3.1 个人项目
1.3.2 结对项目
1.3.3 团队项目
1.4 自我评价——对七大课程目标掌握程度的自评
第二部分个人技术总结
2.1 你立下了一个目标——准备篇定下的目标完成度
2.2 你击败了几只怪物——在团队开发中做了什么事
2.3 你获得了大量宝藏——获取了哪些技术进展
2.4 你留下了一些武器——个人技术总结博客

第一部分课程回顾和总结

1.1 问题回顾——对于旧问题的新看法

1.1.1 问题提出的博客地址

软工实践寒假第一次作业

1.1.2 旧问题，新思考

old Q1: 工作时是否应该带着个人、感情驱动的因素?
old A1:
在工作中个人情感确实是不必要的东西，就如同流水线上的机器一般，只要做好自己的本职工作即可。然而情感在某些程度上是可以驱动人们更加高效、更加勤奋工作的因素。就比如我是为了买某样物品、为了早日完成工作以得到一段时间的放松，甚至也可以是一个长远的目标，比如为了更好地成家立业等等，诸如此类的目标能激发人们的斗志，以此能在工作时取得更高的效率。情感也是激发人们灵感的有效工具，而灵感对于工作来说也是十分重要的，不论是在何种情感状况下，突如其来的灵感往往能成为解决工作瓶颈的关键。虽然情感也是有其负面效果，不论其是带着积极情感还是消极情感，但总而言之个人认为情感在工作中并不是多余的，相反地，情感在工作之中仍有其存在甚至是成为某个环节关键的必要。
new A1:
个人对于该问题的思考仍然与之前相差无几，不过经过软工实践的几次作业之后也算是验证了我之前的想法：在团队作业中，我们不带任何感情工作当然能取得很高的开发效率，前提是我们有一个很明确的目的和开发思路，然而由于我们的团队项目涉及到网络部分，项目给予人的体验很大程度依赖于网络的同步，在大部分情况下我们都是忙于去解决各种技术问题，在这段时间之内我们难免带着各种负面情感——感觉很疲惫、厌烦，团队之间对于问题的解决方式也有过多次争吵，庆幸的是，我们更多时候都是怀着一股热情去披荆斩棘，一个接着一个问题被解决，给予我们的也是更多的动力来开发完这个项目，即使到凌晨2、3点，我们依旧靠着我们的情感，坚定地完成目标。所以对于这个问题，我的回答依旧是肯定的：情感因素有时是负面效果，但是更多的时间它是某个环节关键的必要，带着情感工作也不算是一件坏事。

old Q2: 花费时间越多，代表工作量越高吗？
old A2:
对于这个问题我的思考可能还很稚嫩，毕竟现在我接触过的“工作”也仅仅是课设作业和假期的闲时打工，但我也会基于此列出我的思考。
首先这个问题对于每个人可能都不一样，在一个人的不同时期也可能得到不同的结果。每个人对于工作的态度不同取决了他们的效率不同，就比如上述问题中怀揣着目标的人和内心“空游无所依”的人，令他们工作相同的时间，计算出来的工作量不言而喻。效率是影响工作量的一大因素，时间并不是决定一切的。现在我们假设每个人的工作效率是相同的，那么可想而知，对于机械性工作而言，这个问题的答案确实是时间和工作量正相关。但当我们考虑脑力工作时，当我们考虑团队工作时，又是得到不一样的答案。脑力工作需要思考，团队工作需要队员之间的协作配合——如何规划团队项目路线？如何分配工作？如何撰写文档？这些都是十分消耗时间的工作。总体来看，花费时间越多并不代表工作量越高，特别是在软件工程专业中，工作量并不能以如此简单的标准来衡量。
new A2:
不是如此，经过这一学期的学习以及实践，我能够得出一个比较确切的答案，工作量应与最终结果相关，花费的时间应该与个人的实力相关，特别是在一些脑力工作方面。在团队作业中，成员贡献度的衡量一直都是一个很头疼的问题，不同成员负责不同的模块，不同模块又不能简单地以花费的时间作为标准来计算贡献度，例如撰写文档和开发项目显然不是一个难度的工作。于是在项目开始前，我们事先以一个统一的公式计算每个模块所得结果的工作量，再根据不同的工作难度给予不同的权重，这样，工作量只与该成员所完成的工作有关，不与其花费的时间挂钩，而且团队中难免有摸鱼的人，应该在完成的工作上关注成员的工作量。对于这个问题的回答，我的观点依旧是：工作量并不能以如此简单的标准来衡量。

old Q3: 技术力不足的企业进行产品的创新是否过于盲目？
old A3:
这个问题同样地，我似乎没有经验来对此进行评价，但这同样也能引起我的一些思考。就我个人而言，我认为创新的基础是要有对现有的体系结构全面的、深入的认知。虽然确实也是有其他的情况，在自己不擅长的领域有了新的发现，但这也是建立在对这个领域有全面认知的基础上建立的。提升自我才能成就非凡，对个人也好企业也罢，我认为都是如此，技术力不足的企业进行产品创新的确过于盲目，首要目的应该是发展自身技术，在原本的基础上全面对技术进行一步一步的升级，巩固好自身对于市场的需求，之后再高谈阔论创新之路也不迟，~~除非他真的有钱~~ 。
new A3：
（补充）我仍然没有足够的经验来判断，但如《构建之法》中所说——技术才是创新的关键，个人认为打好基础依然是企业的核心要求，基础不牢，地动山摇！

old Q4: 软件的缺陷是否应该在规格书中说明？
old A4:
我们的某位老师曾经说过，没有不存在BUG的软件，事实也的确如此。BUG作为程序和软件中频繁出现的问题，是让人很头痛的一件事，但是绝大多数软件的BUG并不会严重影响软件的使用，即便如此，我认为软件的缺陷是应该在规格书中说明的。一些虽然看起来不严重的BUG可能会对某些用户产生严重影响，因此还是需要对软件做全面测试并标记出暂时无法解决的BUG。实际上我本人在项目报告中也会标注出项目中存在的BUG，我认为这是一个不错的习惯，也方便日后解决漏洞的存在（当然正规的软件在其他文档应该会存有记录）。
new Q4:
（补充）软件的缺陷其实也不仅仅只包含BUG，个人认识到缺陷应当还有软件无法做到完善的功能，例如反人类的设计、功能缺失、界面杂乱等，这些都需要在规格书中说明，不仅有利于后期确定改善的方向，也是对用户的负责。

old Q5: 结对编程的价值体现在哪里？
old A5:
本人对于结对编程的认知也仅限于书面，但经过了解发现在之前的项目中我也有类似的经历——在一个三人项目中，一人“驾驶”两人“观察”。经过类似的经历，我对结对编程的价值有了比较深刻的体会：首先结对编程能增加程序员编码时的“耐受度”，两人轮换工作能使程序员脱离重复工作的枯燥，观察员也能有充分思考代码的时间，提高工作的效率；接着结对编程能大幅度减少BUG的发生，毕竟“不识庐山真面目，只缘身在此山中”，对于自己的代码人们往往不能做到全面的审查，而结对编程能够清晰地将失误放大并使之能够被即使改正，从而提升编程的效率和质量；而且在结对编程中，两个人的知识面结合能够覆盖绝大部分的知识盲区，并提供一个可靠的解决方案；个人觉得最为重要的一点就是能使两人都全面认识代码结构，熟悉每一个模块。虽然结对编程也有之不足的地方，例如耗费人力、时间（当初的三人项目有时候完成一个功能就需要一整天的时间），但其价值是不可泯灭的。
new A5:
这学期经历了一次完整的结对编程的开发经历，我对于结对编程的价值又有了更深入的了解。结对编程的价值充分地体现在其对于代码质量的提升：在开发时，代码错误是难免的，特别是在结对作业中，网页的开发涉及到大量的css编写以及网页结构的一层层嵌套，前者可能对于运行结果的影响较小，后者一旦出现一点偏差就会导致整个网页的布局与预想的不一致。然而结对编程过程中有充分的审查代码的时间，这使我们的开发过程较为顺利，即使出现问题也会被“观察员”立刻纠正，遇到难题也是有两个人的知识量储备，~~完全不虚~~ ！

new Q6: 对于一名工程师而言，究竟应该是更”专“一点好，还是更”广“一点好呢?
new A6:
我对这个问题的看法是：对于一名工程师来说，“专”还是比“广”更为重要（如果只能选择一个方面的话，当然也有那种啥都会啥都很强的人）。就编程语言来说，专精一门语言带来的收益远远比学很多语言要高的多，专精意味着你有解决难题的能力，而“广”带给你的止于“入门”，对于实际的开发其实没有很大的作用。而且在编程语言应用的很多领域，要求开发者需要更深入地了解编程语言的底层，才能更好地做出项目，并对项目进行优化改进，提升产品性能，这些都是止于“广”做不到的。当然，“广”也有其好处，当我们在我们“专”的领域遇到难题时，可以试试用我们“广”的知识来搜索解决方式，虽然可能要涉及到另一个领域的技术，但是至少找到了一种解决方法。总而言之，我认为“专”是软件工程师该注重的地方，“广”可以作为“专”的一些补充。

1.2 做中学——每阶段的最大收获

1.2.1 需求阶段

关于需求阶段，最大的收获——也是最大的教训：在软件开发的前期一定要把可能的需求和功能全部挖掘出来并记录，否则到正式开发环节往往会引起一些不必要的麻烦，特别是团队项目，一旦在开发中期发现了某项功能被遗漏，轻则项目延期，重则可能需要改变整个项目的结构，浪费大量人力物力。
此外在需求阶段还有一些其他的收获：例如学会了利用NABCD模型来合理、系统地进行需求分析，以及一些相关文档的撰写。

1.2.2 设计阶段

设计阶段主要的收获是学会了使用Axure类似的原型设计工具。在以往项目开发时，对于项目的设计阶段我往往不是很在意，写到哪想到哪，这对项目的构建其实是不利的。通过这学期的学习之后，我明白了设计阶段的重要性，而且做好设计阶段的工作，在项目开发时的思路就会变得非常清晰。

1.2.3 实现阶段

实现阶段主要是各种技术的应用收获，例如unity的使用以及对于网络编程相关知识的运用。其实实现阶段在个人项目和团队项目又有不同的体验，个人项目实现阶段收获较少一点，也就是项目的开发过程中需要仔细一些，一行代码的失误可能会引起几个小时的纠错过程，团队项目关于实现阶段的体会较多，不论是关于项目的架构过程还是功能实现过程，总之在团队项目实现阶段，一定要协商好项目文件的结构，对于代码风格也要有约定，并且尽量减少功能实现与代码主体的交互，多多应用中介者模式或者适配器模式，增加类的可复用性，以在后期增加功能或者修改功能时减少对原有代码的修改，使得代码维护更加方便。

1.2.4 测试阶段

测试阶段我主要是学会了系统的测试方法，包括单元测试、集成测试以及系统测试。测试阶段是十分重要的一个阶段，是对已完成功能的验收，不限于寻找软件的缺陷。经历了几次作业后，我更加深刻地理解测试阶段的重要性，其中最大的收获便是测试一定要充分，站在用户的角度对所有功能进行验证，而且这个验证还需要包括一些非常规的操作，你永远不知道用户会进行什么样的操作！所以程序员能够做到的，就是尽量让所有操作都在预料之内，并进行处理。

1.2.5 发布阶段

在发布阶段中，主要学习到了服务器的租借以及项目的部署，并且第一次利用服务器进行了远程数据库的操作以及游戏服务器的搭建。

1.3 项目心得——个人、结对、团队项目经历的体会

1.3.1 个人项目

个人项目主要是对gitcode的使用有了初步的了解，并且在第一次热身作业中，我学会了用第三方库去解析json数据，将重要信息读取下来，而且认识到了I/O操作对程序效率的影响。在个人项目中，我在细节方面的处理也更加完善，包括输出格式以及代码的优化等。个人项目作为软件工程实践中前期的任务，对于同学与同学、同学与老师之间的交流有促进作用，不论是在作业细节方面还是代码优化方面，交流不仅仅能够解决我们对于项目细节的疑问，也能够互相学习彼此的优秀方案。

1.3.2 结对项目

结对项目中我初次使用gitcode与他人进行合作开发，体会到了gitcode的好处，它使得我们在项目开发中能把更多的精力放在开发本身上，在代码整合上能花费更少的时间。我还学会了很多工具的使用，例如世界地图的制作利用了echarts；网页外观的设计借助Axure搭建了原型并在开发时利用一些设计网站拼凑素材；字体库的导入利用了字体包转换工具等等。最重要的是学会了如何将项目部署在服务器上，这也是我第一次实现的服务器部署操作。并且复习了一遍web开发的流程，使得我对于web开发又有了更深入的了解。
在结对过程中，双方之间的交流也是很重要的，需要事先做好需求分析并且对项目结构、代码风格等进行约定，在开发过程中才能畅通无阻。虽然在结对项目中我们是采用纯前端实现，但过程大体上是相同的，有初步的认识才会有深入的学习。结对做出的项目依然存在缺陷，需要改进的地方还有很多，还是得提高自己的技术能力才能做出令大家都满意的作品。

1.3.3 团队项目

团队项目开发过程中，我们小组选择了游戏开发，由于之前没有接触过相关的知识，我们都是从零开始摸索，因此，在这个阶段我的收获也是最多的。不仅对于unity的开发流程有了详细的了解，并且在组员交互的过程之中，我体会到了一个团队相互之间配合的重要性，我们小组分工明确、各司其职，开发效率也因此得到了提高。由于我们在初期准备工作做得不充分，期间出了一点项目结构上的问题，还有一些关于实现算法上的争论，但最后我们还是把项目准时完成了，虽然还有一点遗憾：我们没能把在alpha阶段设想的所有功能完成，不过经历了二十多个夜晚的开发，我们也算尽力而为了。
我在团队项目主要负责的是游戏地图以及相关算法的实现，到现在这个算法依旧有很大的缺陷，我也是遇到了一点技术瓶颈。我们在团队开发遇到了类似的一个又一个的难题：房间功能实现、网络同步、游戏结束之后的一系列操作...我们往往先进行讨论，但有部分时间我们仍需要借助他人知识，这也让我深信，不断地学习才是解决问题的唯一途径，在今后，我还需要汲取更多的知识，以便在团队开发过程中，我能更好地发挥自己的作用。

1.4 自我评价——对七大课程目标掌握程度的自评

目标	评分	解释
目标1：理解软件工程师的职业道德规范和实践要求，了解国情社情民情，理解软件产品对社会、健康文化等影响，树立积极向上的软件开发理念。	95	在软工实践所做的几个项目中，个人对于软件产品对社会、健康文化等影响有充分理解，并且一直树立着积极向上的软件开发理念，绝不趁自己的专业之便做出一些违背道德、法律的行为
目标2：掌握需求分析的全过程，能辨别客户表述的多样化要求，熟练使用需求表达工具，能够规范、准确地表达客户的需求，构建需求分析模型。	88	掌握了需求分析的全过程，熟练使用需求表达工具，但对于客户表述的多样化要求有时无法全面辨别，会遗漏一些潜在需求
目标3：掌握软件开发的全过程，遵循体系结构设计方法和基本设计原则，通过正式的技术评审，完成从体系结构设计模型、数据设计模型和构件级设计模型，形成面向高效可靠的服务组件设计方案或软件系统设计方案。	90	开发过程中我在软件设计阶段和设计文档撰写阶段参与较多，并且一些基本的设计原则和体系结构设计方法我也比较了解，因此该目标的掌握程度个人自我评价较高
目标4：能够执行从组件到软件系统的技术评测，具备设计模型的评判能力，具有创新设计意识，能够优选设计方案。	85	个人在设计方案的选择上上自我感觉还不错，也具备一定的创新设计意识，但不够具体、不够充分，在遇到一些难题时没有足够的能力发挥创新设计意识
目标5：遵循软件开发各阶段文档标准，采用规范的表达，掌握需求规格说明书、系统设计说明书、系统测试报告等文档撰写方法，具备与业界同行交流能力。	90	开发过程中我参与了大部分的文档撰写，对于开发各阶段的文档标准也比较熟悉，并且有充分审查文档的经历
目标6：具有良好的团队意识和合作技能，能够与其他成员开展有效的沟通和协作；能够组织、协调或指挥团队开展工作。	83	在团队开发中作为一个组员我能够与其他成员进行流畅的沟通协作，但缺乏组织、协调或指挥团队开展工作的经历
目标7：能够辨别具体软件项目管理中涉及的构成要素，掌握软件规模和工作量的估算方法，能够选择合适的工具规划软件进度并对项目管理过程进行配置，具备初步的管理复杂软件工程项目的能力。	80	对于例如git类似的项目管理工具还不够熟悉，并且在软件工程实践中开发软件工程项目出了几次问题，自我认为这方面做的不是很好

第二部分个人技术总结

2.1 你立下了一个目标——准备篇定下的目标完成度

关于第一次作业准备篇中，我为自己制定了vue的学习路线。但是由于在学期初明确了自己未来的职业方向——游戏开发，vue与我的发展方向不符合，于是我将vue的学习替换成了unity的学习，学习安排与之前准备篇所描述的差不多，有区别的是学习的内容。在团队开发之前，我复习了一遍C#的使用，了解了unity的基本功能并写了一个小demo。经历了一次完整的游戏开发流程，我现在对于unity的使用比较熟悉了，对于unity一些组件的功能运用也比较熟练。
学习路线参考Unity学习之路，目前进行到第三阶段后期。

2.2 你击败了几只怪物——在团队开发中做了什么事

我在团队开发中担任的是游戏客户端的开发，遇到的比较多的问题还是在于对unity还不熟悉，处理问题没有思路。不过经过一段的学习后，勉强还算作可以。主要的技术问题是地图生成算法与同步的问题，虽然现在的算法能够基本实现所设想的功能，但该算法仍然有很大的优化空间，包括划定不同元素的生成区域、限制生成范围、大体积元素的判定问题，以及地图全随机。

2.3 你获得了大量宝藏——获取了哪些技术进展

利用unity进行地图制作；
利用unity进行动画制作；
利用shader渲染一些效果；
利用unity粒子系统制作一些特效；
利用springboot进行简单的接口开发；
对于web开发有了更深入的了解；
学会了项目在服务器的部署；
对于优化程序有了新的认知；

2.4 你留下了一些武器——个人技术总结博客

博客地址：个人技术总结——利用Unity简单地制作一张2D地图并生成随机资源
帖子地址：个人技术总结——利用Unity简单地制作一张2D地图并生成随机资源
注：该博客主要介绍了如何在unity中绘制你想要的地图以及在地图上生成一些随机的资源，例如树木、石头等。你可以用此来做一个资源抢夺的游戏或者为你的地图增添生气！

...全文