在公司做了一个功能开发流程的总结,顺便也分享一下自己的想法。
前言
这个文档目的是 明确业务功能开发流程,进而提高团队协作效率。
(从此,做出好游戏,席卷人民币,迎娶白富美,走上人生的巅峰,想想还有点小激动呢…)
在产品研发中,客户端是很核心的一个部分,我们是策划、服务器、美术、测试、用户之间的纽带。作为有担当的核心部分,当然要对自己的产出进行把关。这并不是一个舍己为人的行为,而是一个互惠互利的举措。
马云爸爸的3Win理论:客户Win(团队效率Win),合作伙伴Win(策划、服务器Win),自己Win。
这些我们都做到了,怎么能不成功!
怎么做
1. 开发阶段
原则:
与策划定表结构或与服务器定接口,是一个 讨价还价 的过程,一定要进行协商,切忌某一方一言堂。
开发过程中,对于文档细节的疑问,哪怕是一丁点,也要与策划再三确认,不要嫌麻烦,因为现在不改,以后也是你改,而且花的时间更长。
如果在此过程由需求改动,一定要 确保策划落实到文档 上,避免之后不必要的麻烦。
我们可以提供自己的建议,但是最终解释权归策划所有。这句话不仅针对客户端,同样也对服务器有效,也就是说,如果与服务器有争论,可以让策划知晓双方观点及利弊情况,然后由他仲裁。
- 总之,策划就是一个双刃剑,我们要学会如何减少自己的伤害,更要充分加以利用。
流程:
与 策划及服务器 商定表结构
表中字段的加减要慎重,不要随意。
一个表的字段数量一定要控制,必要时可以作表的扩展,不要所有东西都放一个表里。把表当成函数,不要所有逻辑全写在一个函数中,也不要有过多的小函数
表中数据的存储,也需要考虑到后期的维护。
- 比如之前做过一个装备强化表,策划要求每个强化等级对应一条数据,前期装备少,强化等级低,表很小,可越维护越大,造成后续加载效率极低的问题
设计表的过程中,尽可能多的让策划采用公式来设计数据,可以大大减少数据量
- 之前那个强化表,最多的时候有几万条数据,后来改成公式不到100条
如果涉及到其他表中的字段修改,一定要跟该表的功能负责客户端一起讨论
与服务器商定协议接口,必要时可让策划参与
由于客户端和服务器表是共用的。
尽量 让表中的某个字段只由一方读取,比如客户端读了A字段,服务器就不需要读了;如果服务器读了A字段,客户端就不读了,让服务器发过来。
避免混合数据造成查错困扰。
如果某字段服务器不用来维护,只是进行 验证判断 或 发放奖励 ,则可以客户端自己读取。
规划方案制定XMind,先设计后开发
客户端开发
如果此时需要测试数据,可以按照约定的格式,自己写一些简单数据。切忌等待表或服务器做完再去开发 。
建议
客户端在开发阶段需要的做一些自测数据,建议利用好Cache,做一些model,model是ui和数据(服务器和策划表)之间的中间键,它是我们客户端自己整理的数据集合。有利于之后功能的迭代。具体怎么弄,欢迎大家去找司伟伟讲解
2. 自测阶段
原则:
我们做的是一个产品,需要保证自己产品的 基本质量。此处我们多迈了一小步,但是会给团队效率提升一大步。
流程:
要求策划出 正式数据(或近似于正式数据的测试数据)
用 策划数据 与服务器对接
根据策划文档与策划数据,进行正常功能所需的流程
- 保证功能全程不崩溃
- 所有与服务器交互,正常执行且显示正确
- 界面显示无异常情况(即使是由于策划数据导致,也要 告知策划 ,让其改正)
将问题整理(应该分为三部分 策划、服务器、客户端),并提交相应人修改
若有客户端、服务器、策划的修改,待修改完,到 步骤3;
若无修改,或者 只剩下策划的修改,且策划要求可以直接进入反馈阶段 ,可以进入反馈阶段
3. 反馈阶段
原则:
理论上讲,由于自测阶段存在,改动会比较少。一般是策划发现玩法与想象不符造成的额外修改,这些修改,需要根据改动规模进行协商。
如果在此过程由需求改动,一定要 确保策划落实到文档 上,避免之后不必要的麻烦。
流程:
提交策划进行测试
策划反馈(一般是以彩虹表形式)
若有反馈,则修改反馈,到 步骤1;
若无反馈,则继续
4. 收尾阶段
原则:
整理XMind是一个好习惯,好记性不如烂笔头。趁热打铁,把整体设计、思路都记录,方便以后理解修改,绝对是不损人很利己的行为。
至于XMind的规范…再说吧
流程:
- 整理XMind
- 关于重构
- 尽量避免重构,重构对于客户端、策划、测试的成本都比较高。一旦重构,必须 告知策划,进行测试