回首过去，展望未来
回首过去，展望未来
| 这个作业属于哪个课程 | 2021春软件工程实践/S班 |
|---|---|
| 这个作业要求在哪里 | 软件工程实践总结&个人技术博客 |
| 这个作业的目标 | 总结和回顾 |
| 其他参考文献 | ... |
一、课程回顾与总结
1、有关《构建之法》的问题
-
问题一：作者有在书中提过这么一句话，“简单的说，软件的行为和用户的期望值不一样，就叫Bug，是否是Bug，取决于用户、开发者的不同角度。”这句话值得思考，在之前的理解，Bug指的是程序中没有被开发人员发现的问题，但这里给出了不一样的概念，开发人员有必要给用户最好的体验，而用户也对体验需求慢慢的有新要求，但如果用户得寸进尺，给开发人员难以接受的需求，这时这个Bug应该由谁负责。在下得出，应该是不同角度有不同的结果谁更合理谁获胜。
- 同意书中的观点，软件是给用户使用的，最终目的就是满足用户的需求，使用户可以高效愉快的使用。满足用户的需求就是开发者的职责。在团队合作时，用户对我们的demo产品试用后，提出了许多的建议与要求，这些我们作为开发者，都有一一的去考虑设计实现。当然与产品无关的需求在考虑后得剔除。若是一个软件满足大部分的用户需求，那么可以说它是几乎没有BUG的。
-
问题二：小强地狱讲：开发人员可以忽视一定量的bug，优先保证核心功能的实现。但是这种开发模式真的好吗，前期忽视一定量的BUG，能保证后期核心功能不会有Bug么，如果能，则挺好的，若不能，后期BUG连环，处理是一件很麻烦的事情，就像前期地基不牢，后期建筑有不足，甚至要倒，重新从地基开始重建，真的合理吗。在下觉得可能可以边写边改，保证后期，但是在下只写过轻量级项目，不懂重量级是否适合小强。
- 在这次团队作业中，我负责的地图设计在交互上一开始有一个小BUG，当时没有太在意，只是为了能把测试版做出来，结果测试版demo中出现了交互卡死闪退的情况，这让我不得不重新去审视修改之前的交互小BUG。这是BUG的连锁反应，原本只是一个小小的交互延迟的BUG，却导致了卡死闪退的大问题。所以我现在认为，一开始出现的小BUG就得解决，不能拖到后期，因为不知道后期他会造成什么样的问题，而且修改时，可能涉及到底层代码的重构，非常麻烦。
-
问题三：团队合作，这是一个在任何时候都不过时的话题，在软件工程中，是尤其重要，每个人能力不同，角度不同，风格不同。导致了团队不能友好有效的运行，在之前，在下就有几次不好的团队合作，工作分配不均，有的人不做事，拖到最后大家帮他擦屁股，书中也用猪，鸡举了一个生动形象的例子，若是一群猪组队，就不能是一个好团队了嘛。团队的成功到底如何定义。
- 经过这次的团队合作实践，我认识到，团队的成功与每一个人都脱不了关系，只要是前期每个人分工合理实际，大家都竭尽全力、努力去完善代码编写，市场调查等等。即使做出来的产品与期望有所偏差，但是只有每个人都用心尽力去做，大家愉快合作，积极沟通。这就是一个好团队，即使最终产品没有成功，但是在团队层面上，已经成功了。
2、阶段性收获
-
需求阶段：需求作为产品开发的最初步骤，必须做到尽量全面细致的分析与调查，因为他决定了之后产品的主要功能与设计。使得后续的开发有指导，不会失去目标。一旦确定就不能随意做出大的改动。
-
设计阶段：这就需要需求阶段的结果作为指导，再根据开发难度周期等，尽可能的去满足用户需求。游戏方面就得有新意，有创新性，有可玩性。界面与操作不需要过于复杂，只要满足以上即可。
-
实现阶段：我这次实现的主要是地图方面的设计，我之前没有使用过Unity，后面自己通过网上的教程，一步步的学习Unity的Tilemap设计地图，学到了一种新的引擎使用方法。虽然一开始使用不熟练造成了许多的问题 ，但最后还都是克服了。
-
测试阶段：学到了一开始的小BUG不能留，否则后面可能会造成比较大的问题。测试得全面，不能遗漏。
-
发布阶段：最后从demo到最终版，最后生成apk安装包给朋友同学，成就感还是有的。
3、心得和理解
- 第一次做游戏类的开发，虽然有些地方做的不够完善，但是学到了很多。查阅书籍，上网搜索教程，再一步步的学习使用。一步步的成长的这种过程让人乐在其中。
- 第一次有8个人的团队一起合作，之前最多只有3个人。体验到了正真的团队开发，大家积极沟通交流，一起完成一个较大的项目。最后产品的成功，与每个人都有密不可分的关系。
2. 个人技术总结
- TileMap总所周知是一个十分便捷的unity插件，他能够很方便的创建2d场景的地图，以及一些场景中的东西。
