关于功能开发的感想

在公司做了一个功能开发流程的总结,顺便也分享一下自己的想法。


前言

这个文档目的是 明确业务功能开发流程,进而提高团队协作效率

(从此,做出好游戏,席卷人民币,迎娶白富美,走上人生的巅峰,想想还有点小激动呢…)

在产品研发中,客户端是很核心的一个部分,我们是策划、服务器、美术、测试、用户之间的纽带。作为有担当的核心部分,当然要对自己的产出进行把关。这并不是一个舍己为人的行为,而是一个互惠互利的举措。

马云爸爸的3Win理论:客户Win(团队效率Win),合作伙伴Win(策划、服务器Win),自己Win。

这些我们都做到了,怎么能不成功!




怎么做

1. 开发阶段

  • 原则:

    • 与策划定表结构或与服务器定接口,是一个 讨价还价 的过程,一定要进行协商,切忌某一方一言堂

    • 开发过程中,对于文档细节的疑问,哪怕是一丁点,也要与策划再三确认,不要嫌麻烦,因为现在不改,以后也是你改,而且花的时间更长。

    • 如果在此过程由需求改动,一定要 确保策划落实到文档 上,避免之后不必要的麻烦。

    • 我们可以提供自己的建议,但是最终解释权归策划所有。这句话不仅针对客户端,同样也对服务器有效,也就是说,如果与服务器有争论,可以让策划知晓双方观点及利弊情况,然后由他仲裁。

    • 总之,策划就是一个双刃剑,我们要学会如何减少自己的伤害,更要充分加以利用。
  • 流程:

    1. 与 策划及服务器 商定表结构

      • 表中字段的加减要慎重,不要随意。

        一个表的字段数量一定要控制,必要时可以作表的扩展,不要所有东西都放一个表里。把表当成函数,不要所有逻辑全写在一个函数中,也不要有过多的小函数

      • 表中数据的存储,也需要考虑到后期的维护。

        • 比如之前做过一个装备强化表,策划要求每个强化等级对应一条数据,前期装备少,强化等级低,表很小,可越维护越大,造成后续加载效率极低的问题
      • 设计表的过程中,尽可能多的让策划采用公式来设计数据,可以大大减少数据量

        • 之前那个强化表,最多的时候有几万条数据,后来改成公式不到100条
      • 如果涉及到其他表中的字段修改,一定要跟该表的功能负责客户端一起讨论

    2. 与服务器商定协议接口,必要时可让策划参与

      • 由于客户端和服务器表是共用的。

        尽量 让表中的某个字段只由一方读取,比如客户端读了A字段,服务器就不需要读了;如果服务器读了A字段,客户端就不读了,让服务器发过来。

        避免混合数据造成查错困扰。

      • 如果某字段服务器不用来维护,只是进行 验证判断发放奖励 ,则可以客户端自己读取。

    3. 规划方案制定XMind,先设计后开发

    4. 客户端开发

      如果此时需要测试数据,可以按照约定的格式,自己写一些简单数据。切忌等待表或服务器做完再去开发

  • 建议

    客户端在开发阶段需要的做一些自测数据,建议利用好Cache,做一些model,model是ui和数据(服务器和策划表)之间的中间键,它是我们客户端自己整理的数据集合。有利于之后功能的迭代。具体怎么弄,欢迎大家去找司伟伟讲解


2. 自测阶段

  • 原则:

    我们做的是一个产品,需要保证自己产品的 基本质量。此处我们多迈了一小步,但是会给团队效率提升一大步。

  • 流程:

    1. 要求策划出 正式数据(或近似于正式数据的测试数据)

    2. 策划数据 与服务器对接

    3. 根据策划文档与策划数据,进行正常功能所需的流程

      • 保证功能全程不崩溃
      • 所有与服务器交互,正常执行且显示正确
      • 界面显示无异常情况(即使是由于策划数据导致,也要 告知策划 ,让其改正)
    4. 将问题整理(应该分为三部分 策划、服务器、客户端),并提交相应人修改

    5. 若有客户端、服务器、策划的修改,待修改完,到 步骤3;

      若无修改,或者 只剩下策划的修改,且策划要求可以直接进入反馈阶段 ,可以进入反馈阶段


3. 反馈阶段

  • 原则:

    • 理论上讲,由于自测阶段存在,改动会比较少。一般是策划发现玩法与想象不符造成的额外修改,这些修改,需要根据改动规模进行协商。

    • 如果在此过程由需求改动,一定要 确保策划落实到文档 上,避免之后不必要的麻烦。

  • 流程:

    1. 提交策划进行测试

    2. 策划反馈(一般是以彩虹表形式)

    3. 若有反馈,则修改反馈,到 步骤1;

      若无反馈,则继续


4. 收尾阶段

  • 原则:

    整理XMind是一个好习惯,好记性不如烂笔头。趁热打铁,把整体设计、思路都记录,方便以后理解修改,绝对是不损人很利己的行为。

    至于XMind的规范…再说吧

  • 流程:

    1. 整理XMind
    2. 关于重构
      • 尽量避免重构,重构对于客户端、策划、测试的成本都比较高。一旦重构,必须 告知策划,进行测试