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