[2017BUAA软工]提问回顾

原博客链接

原问题1:有没有系统的方法来提高一开始的文档的设计后的质量呢

在之前的OO课程上,我已经深刻领会到了设计的重要性,而且在这次的团队开发中,我也是负责从需求分析到代码设计的转换,所以对设计这个过程有一定的理解。

如果要我现在回答上面的问题,我觉得我会说,唯一的方法就是:多看书提高自己的水平,多实践改正问题,多反思并不断更新设计,才能提高设计的质量。而且这一切的前提我觉得是需求分析做的很充分。关于这一点,在下面的新问题中我会详细阐述。

原问题2:在评判软件的好坏时,是不是需要考虑软件背后的成本来对软件好坏进行评判呢?

这个问题老师已经给我做了解答,一定是需要综合考虑各个因素评判好坏的

原问题3:对于没有集体主义精神的人该如何管理呢?

管理是门很大的学问,不过还好在我们的团队项目中,大家都是有责任心的。

新的理解和收获

新收获1:需求分析十分重要

我们的团队开发是瀑布模式,即一部分人先制定游戏的内容,然后我来把他们的游戏内容转化为代码的设计,在设计好后,我们开始编写代码,一切看起来很和谐,但是如果考虑我们现有的时间成本就会发现这样的模式并不可取。

假如游戏内容设计人员花了一周时间制定了游戏内容,然后设计人员花一周时间把他们的游戏内容转化为代码设计,最后开发人员进行代码的编写再花一周。可以看到在内容设计人员设计游戏内容的过程中,代码设计人员和开发人员其实无事可做,而在代码设计人员和开发人员开发时,游戏设计人员又会没有事情可做,这就好比一个单周期的CPU,同一时间只有一个部件在工作,所以我一直在想能不能把这个模式转化为类似流水线的模式?因为我们的开发时间其实挺短的,也就最多一个月时间,况且还有其他课程需要学习,开发时间短,任务重,瀑布模式虽然好,但是可能没有那么多时间顺次的走完一个流程。

我尝试在游戏内容设计人员给我一部分内容后我就开始设计,设计好后就可以开始开发了,但是当他们把另外一部分内容设计给我的时候,我内心是拒绝的,因为如果要把他们的另外一部分内容加进来的话,需要改动之前的一些架构。虽然软件开发讲求可扩展性,但是还是会有一些扩展的方向是一开始没有考虑到的,所以我们在β阶段对α阶段的改动是很大的,就是因为需求的改动太大了。

所以我个人认为,在瀑布模型中,需求分析是绝对不可以与其他阶段并行的,需求分析是接下来所有阶段的基础。

新收获2:框架选择时,尽量选择成熟的开发工具

这次我们做游戏选择的开发工具是一个新的编辑器,随着开发过程的深入,这个新编辑器逐渐的显露了出它的一些缺点:

  • 本身有一些bug
  • 相关的技术文档还不完善
  • 技术社区的很多问题没人解答
  • 没找到做单元测试的方法
  • 游戏场景文件不能很好的支持github的冲突处理(场景文件应该是自己生成的json格式的文件,如果多人开发时有了冲突,会发现有几百甚至上千处冲突需要合并,而且场景文件的内容还不好理解),这就导致多人合作开发成了问题

所以在选择开发工具时,选择成熟的,已经多个版本迭代的工具,才能减少开发的成本。

新收获3:代码规范真的很重要,而且代码规范的严格遵守更重要

多人开发,每个人都有每个人的编码习惯,如果没有一个统一的规范遵守,会发现最后写出来的代码可读性较差,也不利于接口之间的对接。

学习到的知识点

需求阶段: NABCD模型,认真分析需求,而且要尽早做,做充分

设计阶段:设计阶段很重要,设计的好才能更好的分工合作

实现阶段: 即使自己不负责测试,也不能说自己写的代码连测都不测,代码的质量是自己保证的不是测试人员给你保证的

测试阶段: 单元测试很重要,但是首先你在选择框架时要选择一个能做单元测试的

发布阶段: 不要以为发布阶段很简单,把文件打包一下上传就好了。发布要尽早做,因为可能有许多未知的事情,比如还要考虑审核时间。

维护阶段: 用户反馈很重要。

posted @ 2018-01-14 15:22  xxrxxr  阅读(205)  评论(5编辑  收藏  举报