原博客链接
原问题1：有没有系统的方法来提高一开始的文档的设计后的质量呢
在之前的OO课程上，我已经深刻领会到了设计的重要性，而且在这次的团队开发中，我也是负责从需求分析到代码设计的转换，所以对设计这个过程有一定的理解。
如果要我现在回答上面的问题，我觉得我会说，唯一的方法就是：多看书提高自己的水平，多实践改正问题，多反思并不断更新设计，才能提高设计的质量。而且这一切的前提我觉得是需求分析做的很充分。关于这一点，在下面的新问题中我会详细阐述。
原问题2：在评判软件的好坏时，是不是需要考虑软件背后的成本来对软件好坏进行评判呢？
这个问题老师已经给我做了解答，一定是需要综合考虑各个因素评判好坏的
原问题3：对于没有集体主义精神的人该如何管理呢？
管理是门很大的学问，不过还好在我们的团队项目中，大家都是有责任心的。
新的理解和收获
新收获1：需求分析十分重要
我们的团队开发是瀑布模式，即一部分人先制定游戏的内容，然后我来把他们的游戏内容转化为代码的设计，在设计好后，我们开始编写代码，一切看起来很和谐，但是如果考虑我们现有的时间成本就会发现这样的模式并不可取。
假如游戏内容设计人员花了一周时间制定了游戏内容，然后设计人员花一周时间把他们的游戏内容转化为代码设计，最后开发人员进行代码的编写再花一周。可以看到在内容设计人员设计游戏内容的过程中，代码设计人员和开发人员其实无事可做，而在代码设计人员和开发人员开发时，游戏设计人员又会没有事情可做，这就好比一个单周期的CPU，同一时间只有一个部件在工作，所以我一直在想能不能把这个模式转化为类似流水线的模式？因为我们的开发时间其实挺短的，也就最多一个月时间，况且还有其他课程需要学习，开发时间短，任务重，瀑布模式虽然好，但是可能没有那么多时间顺次的走完一个流程。
我尝试在游戏内容设计人员给我一部分内容后我就开始设计，设计好后就可以开始开发了，但是当他们把另外一部分内容设计给我的时候，我内心是拒绝的，因为如果要把他们的另外一部分内容加进来的话，需要改动之前的一些架构。虽然软件开发讲求可扩展性，但是还是会有一些扩展的方向是一开始没有考虑到的，所以我们在β阶段对α阶段的改动是很大的，就是因为需求的改动太大了。
所以我个人认为，在瀑布模型中，需求分析是绝对不可以与其他阶段并行的，需求分析是接下来所有阶段的基础。
新收获2：框架选择时，尽量选择成熟的开发工具
这次我们做游戏选择的开发工具是一个新的编辑器，随着开发过程的深入，这个新编辑器逐渐的显露了出它的一些缺点：
- 本身有一些bug
- 相关的技术文档还不完善
- 技术社区的很多问题没人解答
- 没找到做单元测试的方法
- 游戏场景文件不能很好的支持github的冲突处理（场景文件应该是自己生成的json格式的文件，如果多人开发时有了冲突，会发现有几百甚至上千处冲突需要合并，而且场景文件的内容还不好理解），这就导致多人合作开发成了问题
所以在选择开发工具时，选择成熟的，已经多个版本迭代的工具，才能减少开发的成本。
新收获3：代码规范真的很重要，而且代码规范的严格遵守更重要
多人开发，每个人都有每个人的编码习惯，如果没有一个统一的规范遵守，会发现最后写出来的代码可读性较差，也不利于接口之间的对接。
学习到的知识点
需求阶段： NABCD模型，认真分析需求，而且要尽早做，做充分
设计阶段：设计阶段很重要，设计的好才能更好的分工合作
实现阶段： 即使自己不负责测试，也不能说自己写的代码连测都不测，代码的质量是自己保证的不是测试人员给你保证的
测试阶段： 单元测试很重要，但是首先你在选择框架时要选择一个能做单元测试的
发布阶段： 不要以为发布阶段很简单，把文件打包一下上传就好了。发布要尽早做，因为可能有许多未知的事情，比如还要考虑审核时间。
维护阶段： 用户反馈很重要。