挣脱束缚的一步——软件工程实践总结

222000305陈宇焜学生 2023-06-04 19:54:15

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

引用地址：
过往博客：寒假实践作业中对构建之法社区中的问题与思考

水平近似的两个人在进行结对编程时，是否会由于能力的限制导致代码质量无法提高？
当时似乎没有对水平近似的方向做出回答，而是站在出现差距时的效果进行分析。通过实践下来发现，水平相似的两个人想要获得提升，首先需要进入一个较复杂的环境中，比如陷入某个问题、遇到了思维瓶颈、难解的需求。在需求固定、水平一般的情况下，即使水平近似，也会因为代码风格、个人接受过的熏陶不同而产生分歧，但这个范围也很有限，面对都没有遇到过的领域时代码质量可能无法提高。在结对编程实践中，对于html或是web技术了解甚少，但又要求必须使用，怎么办？这就使得两人都陷入了困境，于是上网查找折中的方案，并测试了一下，才解决问题。
写了再改Code-and-Fix模式真的很差吗?
这里依旧保留寒假博客中的回答，但对于独立开发者，写了再改的模式可能隐含重大危险。在β冲刺实践过程中，有个玩家的控制系统与实际角色运动系统耦合在一起，并且控制是分散的，对于我们的小项目而言问题似乎不大，但当要准备开发大型项目时，问题将接踵而至，代码管理上，想要查找这些操作统一的接口？很难，还好强大的IDE给你提供搜索工具。自学期间一位老师认为：“当你要遇到问题要重构你的项目的时候，说明你的项目问题已经很大了。”。独立开发者遇到重构的问题，那可能是灾难吧。
关于团队中的角色转换和转会，究竟有没有这方面的需要呢？我们团队进行了角色的转换，但大家都需要花费很长的时间进行新知识的学习，是不是降低了效率呢？
过去的回答里，我认为这方面的需求不是那么必要，这是从开发者的角度出发。然而在Web开发或其他什么行业里，前后端的岗位调整似乎是经常出现的，这个时候除了辞职，还能考虑是否接受吗。只要能给予一定的缓冲期(β冲刺也提供了)，学习一点不太难的技术，结合自己的所学知识或架构进行理解，相信也能很快适应对应的岗位，这在我们的实践中是清晰展现的，同组组员也很少接触游戏开发，然而本着在实践中学的道理，在α冲刺时就能够边学边做了，极大推进了项目进度。
在MVP方法中，如何保证雏形产品的不完备性不影响用户反馈？
在过去的回答中，以玩家（用户）的视角回答了问题，认为用户反馈在某些方面很难达到预期标准。针对今年的游戏市场环境，查阅了一些曾经关注过的游戏demo，别说是雏形，只要是影响了用户体验，就很难逃离暴死。因此，雏形产品一定要展现项目利好的、有价值的一面，比如创新的风格设计、独特的文化内容或是实用的技术水准，起码能够让用户看到你的用心与投入以及产品的方向，这从开发者的角度来引导用户反馈，扬长避短，将不完备的地方直接告知用户以给予心理准备，又或者展现诚意吧。
虽然敏捷流程非常的迅速高效，但这是否是对团队人员的一种消耗？
敏捷流程最大的问题出在每日例会和每天的任务目标上，在实践过程中，每日例会可以不那么严肃，例如，问做了什么不如直接问出现了什么没有汇报的问题，在每日例会中直接提出解决方案。而任务目标则是每天的工作重心了，在顺利开发的条件下，要考虑每日冲刺的时间和整体项目的推进，产生消耗是必然的，因此要求团队人员保持热情。
软件开发过程中是否有必要保证代码具有100%的正确性，如果有必要又应该如何实现呢?
现在看来，100%正确性是很难追求的，但预防和避免又是两回事。预防工作难以做到，我们可以避免。代码审查是十分重要的环节，不论团队采用哪种组织结构，代码的正确性要高于推进项目，否则系统越来越多，消息越来越多，如何保证将来一个构件修改不影响其他构件？这在我们的β冲刺阶段也出现了，还是角色控制的问题，由于单例与Mono的机制，导致一个控制器出错，其他系统也一并出错。另外，在开发结构中，全员采用相同的编程风格和思路也是很重要的，能对预防bug产生起到作用。
新的问题
敏捷开发中出现的多任务应该如何处理？
对于我个人而言，处理多任务一直是难事，比如生活、学习等活动都会影响敏捷的正常流程。而此次β冲刺有其特殊的一面：并不是所有成员都是项目需求的技术方向，而遇到问题我就必须介入解决，这也影响了我的任务，但我处理的并不好，导致加班。

二、做中学——阶段性收获

选题阶段

需求分析中，要求采用NABCD模型对项目的需求进行描述，这意味着我们除了要考虑项目做什么，还要考虑怎么做、大致方向以及让客户信服的理由。在需求中，老师提出了一些游戏概念上的问题，抛开游戏经历不谈，这些问题也是用户会提出的问题，当然，我们给出了自己设计的理由，但这其实映射了潜在用户的需求。

不玩游戏的人如何对你的游戏信服？
如果你的用户群体也包括了这类用户，你该如何说明？
投资方也不一定能够懂你的游戏内容，难道你不要投资了？

虽然当时项目仅面对喜爱这类游戏的人，这定义了玩家拥有一定游戏阅历的前提。但如果想要挖掘潜在用户呢，比如将来可能突然因为硬件升级而火热的VR、AR等方向的开发，此时就需要针对需求模型进行口语化的阐述，要明白需求分析的意义并不只是给自己规划“做什么”的框架，还要让看到需求的人能够明白你的理念。

需求分析阶段

需求分析阶段需要对于团队项目有一个大概的框架和认知，要标定大致的分工内容以应对接下来的开发和设计工作，这个阶段就需要衡量一下整个系统的样子，我们团队在这个过程中做的不够好，所以使得接下来的开发出现了比较大的变化，这也让我更加确定了一个项目的开发中需求分析的重要性，它是后续设计的入口。
- 如果自己定义需求，定义得太多，时间不够就很难开发完成。太复杂又会让概要设计变得困难，因此需求分析还需要解决实际意义上对于选题的解决办法。
- 对于客户定义的需求，要能够将需求转化为工作，每个需求能否实现，不能马虎大意，也不能夸下海口。
游戏很难通过原型体现，一般是demo雏形实机演示。
对于类图设计，老师提出了一个很重要的概念：“使用聚合而避免继承”，一开始我对这句话嗤之以鼻，认为，“继承不是更好吗？能体现设计还能呈现树状结构，而且和聚合也没差别阿”，但现在明白了，在之前实习中，我也曾将一些懒得写的东西作为父类，而主程告诉我，这没有意义，不如不要，现在想起来，这也是老师的话的体现，另外，在概要设计时也充分地改善了类图。

概要设计阶段

这个阶段主要针对于设计与开发人员，让项目成员能够知道开发的标准和规范以及设计。设计中需要考虑这样设
计的意义，而不是“因为别人这样设计而我也这样。”。
- 在需求分析阶段应用了很多继承，认为此时设计成继承应该是天经地义地，然而当老师问：“他们有什么共同之处吗？”，我们却难以回答，因为我们不知道为什么这样做，只知道似乎这样做很合理。概要设计影响了后续实际开发的方方面面，一旦出现真正不合理的地方，到时候再挽救就悔不当初了。所以我们取消了无用的继承，取消了对项目实际开发无意义的结构，并为架构设计开了个好头。
  
  贸然敲定的类图
  结合实际的类图

实现阶段

实现阶段要求对需求和设计进行实际开发，这个阶段的收获是实打实的，这也是呼应博客标题的一环。在过去的学习中，我很少在实际项目中进行独立开发，更多的是依赖教程和自己对自己的思维麻痹，也就是问自己，如果想要实现XX功能，脑子里能否复现？能复现就算成功。但实际情况呢？
在实际开发中，我做到了不依赖教程或他人的思路来完成一个系统的开发，比如UI管理、道具管理、存档、背包等。在过去它们还只是停留在脑海中的思路，而在实践过程中我把它们实现出来了，并解决了大量的脑子里看不见的bug，还帮助我理清各个系统间的差异和联系。另外还印证了一件很可靠的事情，即：
我是的确热爱游戏开发本身，而不仅仅是游戏，β冲刺时，由于开发工作热火朝天，让我停不下在电脑前双手，整整18小时连续工作，十分的舒爽，主打一个亢奋战士，到了床上腿都麻了。

测试阶段

测试阶段没有太多收获，主要是对测试这个岗位的工作有了大概的了解，明白了想要设计出高覆盖率的用例确实是一件难事，不仅要考虑测试单元的设计，还要理解测试驱动开发的用意。之前不明白，为什么会有测试驱动开发？没有写出代码如何能够让测试驱动开发？
- 而实际上，这里的测试用例需要来源于设计，每个被测单元究竟该如何设计才能达到功能要求？会出现怎样的状况？这些当然是在开发工作中能够同步思考的，但如果在开发前，根据这些问题来设计测试用例，就能减少开发工作中出现的难以察觉的错误，也能避免写了再改的问题。

发布阶段

以前做项目是没有考虑过发布的事情的，虽然也曾打过包，遇到过困难，但是对于部署这方面一直没有直观的了解。曾经倒是将个人网站部署到了服务器，但发布时要做的工作似乎也不简单，很多在项目中能运行的，在真机和exe中就无法运行。特别是此次项目，由于数据读取的路径不是打包后可加载的路径（这点和jar包很像），导致打开黑屏且没有bug日志。

三、循序渐进的三次项目

个人编程

个人编程的任务有点微妙，由于只涉及控制台，且数据很多比对很花时间，输出的结果也不知道是否完全正确。但是在项目中直接应用了当时设计模式刚学的生成器模式，这使得本次任务的代码可以直接被复用。

结对编程

结对编程可以说也是比较艰难了，由于web技术不熟悉，采用了其他方法完成任务，但是也遇到了花费时间很长而难以处理的问题，另一位同学在处理图形显示的代码时，我在旁边看，然而从两个视角都无法解决问题，可以说是一次十分煎熬的开发工作，但是从领航员的视角总是能看到很多东西，比如所编写的代码之外的bug，扫一眼就知道了，根据《代码整洁之道》的结论，驾驶员很容易陷入头脑风暴中，这时领航员就能代替驾驶员完成“下楼跑一圈再回来开发”之后的重新审查工作。

团队项目

团队的工作总是需要大量的配合，这更让我确定了开发中沟通的意义。本次模型采用敏捷开发Scrum，它需要有每日站会报告项目来推进项目，凸显了“敏捷”概念，但在此模型之外，我们也会有很多需要及时沟通的地方，及时的反馈才不会让工作堆积，也能及时地应对突发情况。

四、课程目标的掌握程度

目标1：理解软件工程师的职业道德规范和实践要求，了解国情社情民情，理解软件产品对社会、健康文化等影响，树立积极向上的软件开发理念。
- 掌握程度：100%
- 软件工程师首先要在法律框架下进行开发，有些事情看似只是不道德，实际上还触犯法律。
- 软件工程之所以是一个学科，因为它研究如何进行软件项目的构建，我们目前所学的方法，不论是开发模型还是设计工具，都是软件工程的体现，相比于日常项目工作，它更加专业有效而且准确。
- 软件需要顺应政策，不仅影响曝光和用户量，还影响软件的开发方向，另外社会反响会反作用于软件本身。
目标2：掌握需求分析的全过程，能辨别客户表述的多样化要求，熟练使用需求表达工具，能够规范、准确地表达客户的需求，构建需求分析模型。
- 掌握程度：80%
- 目前需求分析掌握了如何能够将用户需求细化成功能需求，常用的可以使用原型进行分析。
- 但是目前所接受的需求并不多，所以这方面并没有把握能够完全分析出来，特别是自己不擅长的或者离谱要求，为自己保留20%的空白。
目标3： 掌握软件开发的全过程，遵循体系结构设计方法和基本设计原则，通过正式的技术评审，完成从体系结构设计模型、数据设计模型和构件级设计模型，形成面向高效可靠的服务组件设计方案或软件系统设计方案。
- 掌握程度：95%
- 本人的曾经的项目经历也涉及了这部分的工作，所以还是比较有把握的，这部分的每个工作我都亲身参与设计，并且能够在实际开发工作中实现。
- 体系结构主要掌握了分层和调用返回，数据流等并没有实际开发过，故作为缺少的部分。
目标4： 能够执行从组件到软件系统的技术评测，具备设计模型的评判能力，具有创新设计意识，能够优选设计方案。
- 掌握程度：80%
- 能够对软件按提供的功能和组件一个个测试，并猜测其中的设计意图，能够对bug进行评审并进行反向推敲来源和工作。
- 不是很理解这个目标，但是进行了软件评测，但由于评测的目标提供的信息有限且不涉及底层设计，很难给出开发者角度的评测思路。
- 创新设计意识只能说和阅历与天赋有关，软件评测作业似乎有点指导选题设计的意思，但个人提升不大，也很难证明自己的掌握水准。
目标5： 遵循软件开发各阶段文档标准，采用规范的表达，掌握需求规格说明书、系统设计说明书、系统测试报告等文档撰写方法，具备与业界同行交流能力。
- 掌握程度：95%
- 能够根据软件开发各阶段的标准文档来编写文档，此次实践也参与了每次文档的编写。编写时能避免白话文。
- 实际编写时还有很多部分无法下手，特别是对于游戏开发，有些条目脑中完全没有思路。也许并不是都要写，但有些确实不会也不了解。
目标6： 具有良好的团队意识和合作技能，能够与其他成员开展有效的沟通和协作；能够组织、协调或指挥团队开展工作。
- 掌握程度：80%
- 团队意识有很大提升，能够将工作交给参与的成员。
- 能够及时处理和反馈问题，能够安排和细化任务，加强其他成员的项目理解。
- 对于协调多种工作还是很吃力，特别是很难处理对工作完全不了解的人的任务。
- 没能具有产生凝聚力和调动作用的技能。
目标7： 能够辨别具体软件项目管理中涉及的构成要素，掌握软件规模和工作量的估算方法，能够选择合适的工具规划软件进度并对项目管理过程进行配置，具备初步的管理复杂软件工程项目的能力。
- 掌握程度：100%
- 能够分不同的度量标准进行规模和工作流的估算，能够分明任务，使用燃尽图等。
- 能够使用规划软件安排任务、设计任务、查看流程等，能够分阶段进行不同的任务。

五、技术总结

在寒假实践中为自己准备了学习技术的路线，现在看来还是太年轻了，有点想要一蹴而就的心态，内容分支偏杂，因此实际上调整了方向，自学上专攻系统开发、架构设计理解与网络，在团队中再应用部分能用得上的技术，例如本次用到了Dotween、Gameframework、excel2json、Newtonsoft等，并继续加强了系统开发和Gameplay实现，复习了Unity2D的部分技术。

个人学习：简单状态同步的Unity应用学习小结
概述：多人在线游戏需要同步玩家数据，许多公司都拥有至少一款此类游戏。对于状态同步，首先需要掌握两层的设计架构思想以及计算机网络的原理，其难点在于：1. 网络延迟。2. 数据量.3. 安全性。

团队项目：对象池在Unity中使用的“坑”
概述：对象池常使用于大量游戏对象的维护上。作为游戏优化的大头，其实现可以很简单也可以很复杂，这里举例说明多类型对象池的学习记录。此处对象池异于引用池。在Unity中使用常用的对象池时，需要理解对象池的的原理和Unity的生命周期，而此处的“坑”也和一种对象池的实现有关

...全文