善始善终，旅程永远不会结束

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

第一部分 课程回顾与总结

一、善始（以前提问题的博客链接）

  凡是过去，皆是序曲，心之所向，便是天堂

二、温故（以前提出的问题）、知新（现在的见解）、提新（提出新的问题）

温而知（旧问题，新理解）

1. 对于一名工程师而言，究竟应该是更”专“一点好，还是更”广“一点好呢？

故：在我看来，“专”与“广”是无法比较那个好的，“专”与“广”各有利弊，“专”可以让你集中精力、全力以赴的去解决出现的问题，但同时你也会被局限在一定的思维之中。而“广”虽然可以让你触类旁通，另辟蹊径来解决问题，但是同时会让你眼花缭乱，头晕目眩。对于工程师而言，“专”决定你的深度，而“广”决定你广度，“深“而不”广“和”广“而不”深“皆是不可取的，就像在相等的周长中，正方形的面积要大于等于长方形的道理是一样的。综上所述，我认为二者都重要，没有哪一点更好的说法，主要看个人的取舍，适合自己是最好的。

新：以前觉得“专”与“广”二者都重要，没有哪一点更好的说法，现在看来还是“专”一点好，“专”至少可以让你有一席之地，“广”感觉更像锦上添花；”专“是地基，”广“是高楼大厦，没有”专“，高楼大厦无法建成；没有”广“，地基建好至少可以有小屋。所有感觉还是”专“一点好。

2. 商业价值与开源精神是否矛盾？

故：对我来说，商业价值与开源精神不应该矛盾，商业价值存在的意义在于维护个人或者组织的劳动成果，开源精神则可以促进产品更加完善，功能更加丰富，性能更加高效，虽然目前可能二者不可兼得，但是我觉得以后可能会有解决方案的。

新：现在看商业价值与开源精神还是不矛盾，毕竟两者是不同维度的，商业价值是维护劳动成果的维度，开源精神是产品完善的维度。

3. 项目/任务的大小应当由什么指标来决定？

故：需求的数量和难度。我看了许多人的观点，他们认为由代码量来决定，而我认为代码量只能作为辅助参考，就比如同一个任务，我用C语言写可能只要几百行，如果用汇编的话可能要几千行，就凭代码量的话我们能说用汇编来写的任务更大吗？可是他们的任务是一样的。所以我认为任务或者项目的大小主要还是看需求的数量和难度。

新：以前认为是需求的数量和难度，现在觉得还要补充上现有的技术水平。毕竟对于技术水平不同的公司，需求一样，但是技术水平高的公司可能写几个模块解决了，而技术水平差的公司可能还完成不了。所以相同的需求，在不同公司的环境下，任务或项目的大小是不一样的。

4. 极致是否会导致“偏离正道”？

故：个人观点，我觉得有可能会；所谓极限编程，就是把一些认为重要和有效的做法发挥到极致。虽然他重要和有效，但是他并不是整体，就比如人的大脑比较重要，如果发挥到极致的话有可能会头重脚轻，不利于行走。但是也可能成为最强大脑，掩盖其他的缺点。所以我觉得有可能会。

新：现在也还是这么认为，极致是否会导致”偏离正道“要看不同的人，有些人可以把握住那个”度“，所以可以创造奇迹。有些人把握不了，注定”偏离正道“。

5. 软件的缺陷是否应该在规格书中说明？

故：我觉得应该要。虽然可能会降低软件的评价，但是可能可以让用户避免一些糟糕的情况发生，况且列出缺陷也可以让用户更加信任你，用户使用起来也比较放心，毕竟他了解软件的缺陷，可以做出相应的措施来预防。

新：观点与过去相同，软件的缺陷要在规格书中说明，这个是软件开发者的义务。

知而提（新问题）

1. 既然开源精神与商业价值不矛盾，那要如何做到”二者兼得“呢？

愚见：项目开源后创造的商业价值按贡献度分配给每个参与的成员，这样一方面更加激发开源精神的优势，又维护了商业价值。

三、黄金屋（项目每个阶段的收获）

需求阶段

  在项目的需求分析阶段一定要确定好项目的需求，而且需求要尽量详细，不能产生歧义。在这次团队项目中，我们的需求做的不够详细，而且以为对方已经理解了自己要表达的内容，结果产生了好几次冲突，不仅拖慢了项目进度，而且还不利于团队的友好关系。所以一份详细且没有歧义的需求真的很重要。

设计阶段

  在项目设计阶段一定要做好团队之间的沟通。在这次项目的设计阶段我与一位团队成员负责设计类图，因为没有与其他成员进行充分的沟通，类图设计出来他们说有些东西实现不了，只能拿回去重新修修改改，拖慢了项目的进度。

实现阶段

  在项目的实现阶段非常重要的是”统一“两个字，包括代码风格的统一和项目资源风格的统一。因为没有做好项目资源风格的统一，导致我们在α冲刺阶段做的角色，到β冲刺阶段进行了重新制作，使得角色风格统一。这样导致我们原本预期在β冲刺阶段要完成第二张地图的设计不了了之。

测试阶段

  在项目的测试阶段收获最大的就是，你可以看到一堆你未曾设想的bug，测试阶段可以说是我学习知识最多的阶段。（也是访问百度最多的阶段）比如角色动画切换有延迟要这么解决、角色动画切换线太多要这么优化、角色网络动画不同步要这么解决等等。

发布阶段

  在发布阶段收获就是如何将你的产品描绘的高大上，而又不偏离实际，比如如何制作优美精良且内容充实的PPT。

四、颜如玉（每个项目的心得）

个人项目

在个人项目中，我

1. 复习了C++语法、字符串处理函数，为考研的算法科目做一点准备！
2. 学习了如何进行接口封装和代码的单元测试，拓宽了知识界面与能力！
3. 掌握了用git来储存代码，为代码进行备份，这样可以查看项目的历史版本，大大提高了效率与安全！

  通过个人项目的热身，拓展了我对项目的认知，同时也激起了我探索未知知识的欲望和热情，提高了我自主学习新知识的能力。

结对编程

在结对编程中，我

  首先，这次结对编程作业让我对HTML+CSS+Javascript的方式开发网页项目有了更深层次的理解，这次做可以使项目结构分明，术业有专攻，使网页开发效率UP。
  其次，这次项目也告诉我一个教训，那就是项目结构要一开始就要确立好，因为一开始没有统一好项目结构，所以我们还发时间进行了项目结构的统一，不过幸亏当时发现的早。
  最后，看到我们共同完成的项目，一股成就感就涌上心头，所以项目完工后部署到云服务器后就立马把网站发给我的朋友门，与我一同分享这喜悦！

团队项目

在团队项目中，我

  学习了非常多，首先，这是我第一次接触Unity并且使用Unity进行开发游戏，刚刚开始接触时就感觉这软件界面多、参数多，感觉要花费很多时间进行学习，后来通过教程学习，发现上手也不是很慢，也发现使用Unity开发游戏确实比较方便。其次，这也是使用GDNet框架进行开发游戏，这省去我们一大堆的时间进行项目配置等等工作，但是也有弊端，一旦设计到底层的实现，我们就不得不去请问框架的开发者，比如角色的动画不能进行网络同步。最后，在这次的团队合作编程中，我们体会到什么是团队精神，一个人有bug，八个人来de。当然也吸取了许多教训，比如因为都是第一次使用Unity进行游戏开发，我们的程序结构很乱，后期就要一直进行代码优化，而且程序bug也不好定位，代码冗余也比较多，这样很浪费我们的开发时间。

五、省吾身（对七大课程目标的掌握程度的评分）

目标	评分	解释
目标1： 理解软件工程师的职业道德规范和实践要求，了解国情社情民情，理解软件产品对社会、健康文化等影响，树立积极向上的软件开发理念。	76	有了解过相关文献与文章。
目标2： 掌握需求分析的全过程，能辨别客户表述的多样化要求，熟练使用需求表达工具，能够规范、准确地表达客户的需求，构建需求分析模型。	87	在结对编程中原型设计采用了”Axure“、”墨刀“等工具，原型设计也比较合理。
目标3： 掌握软件开发的全过程，遵循体系结构设计方法和基本设计原则，通过正式的技术评审，完成从体系结构设计模型、数据设计模型和构件级设计模型，形成面向高效可靠的服务组件设计方案或软件系统设计方案。	88	我们项目的类图就是采用的MVC模式来设计，设计出来的类图也有给队友进行评审，然后进行二次修改。
目标4： 能够执行从组件到软件系统的技术评测，具备设计模型的评判能力，具有创新设计意识，能够优选设计方案。	83	角色动画切换方案由原来的132条切换线，后面优化为56条，再到后面优化为32条。
目标5： 遵循软件开发各阶段文档标准，采用规范的表达，掌握需求规格说明书、系统设计说明书、系统测试报告等文档撰写方法，具备与业界同行交流能力。	93	参与了规格说明书、系统设计说明书、系统测试报告的撰写。
目标6： 具有良好的团队意识和合作技能，能够与其他成员开展有效的沟通和协作；能够组织、协调或指挥团队开展工作。	83	每次团队活动都有参加，与队友沟通也比较积极。
目标7： 能够辨别具体软件项目管理中涉及的构成要素，掌握软件规模和工作量的估算方法，能够选择合适的工具规划软件进度并对项目管理过程进行配置，具备初步的管理复杂软件工程项目的能力。	83	会使用git进行项目的管理，而且每天都会进行项目完成度的汇报.

第二部分 个人技术总结

个人技术总结——Unity中角色动画制作及动画切换逻辑的实现
概述：该技术是用来为角色设计动画的，比如角色移动动画，角色移动方向切换动画等等，一般为角色设计简单的动画时可以使用该技术，一个角色动画不宜超过20个，超过的话使用该技术会明显出现延迟现象，而且工作量也巨大。