序言

不断总结完善方法论可以在类似的事物中提供指导和依据，下面是我作为前端游戏程序员对工作流程的经验总结。考虑比较复杂的情况，据实际情况酌情简化或者增加细节。本文多是经验所得，主观性较强，且个人水平有限，请大家讨论交流和批评！

流程

大概流程如图所示，部分细节在下面说明

需求宣讲

一般比较复杂的需求会要求策划对需求进行宣讲，需重点听下需求涉及哪些领域，主要功能、流程，并初步判断可行性、复杂度、成本等并提出相关建议

需求分析

先根据需求手册和视觉稿流程、功能、细节、实现方式捋一遍，有必要的话（据经验需求手册并不把每个细节都讲清楚）拽上策划同学把有疑问的地方对一遍。

预研

在遇到不熟悉的领域或者一些复杂的技术，要提前验证是否能够实现和实现成本甚至做一个demo。另外，有些问题可能有多个解决方案调研选择更合适的。

建模

可以在抽象的层面上大致的提供完成需求的理论模型，方便开发者伙伴之间沟通合作，并为开发编码提供蓝本。模型是编程语言之上对业务的抽象，理想情况下编码前要“胸有成竹”。建模方法有很多，由于公司没有要求特定方法，我一般采用类似DDD的方法，领域包含核心功能，支撑，和给外面用通用部分，必要时辅以流程和状态图。追求实用。

依赖确认

在开发前，先确认下配置表、协议、美术资源、依赖的接口的实现情况，理想情况是都准备好了，但是实际情况可能在开发中陆续交付，根据情况做好打算。另外，也有些别的模块，可能要依赖此模块，也要同其他开发者交代大概的时间。

反向宣讲

此时需求基本确认完毕，准备开始开发了。做最后的确认，以要求中途不会变更需求和其他依赖交付的延期。并给出大概的开发周期，以方便其他伙伴准备工作日程。

开发

我大多从总体框架开始，即尽量从最上层的抽象入手。然后是确认边界，包含各个抽象的职责范围，职责的极端情况等。随即就是对抽象具象化，我的习惯是从数据层开始，包含数据的增改删查，以及各州数据变更必要的通知。然后是逻辑层，最后是表现层，这是个人经验总结下来最高效的顺序，我想大概是因为绝大多是情况下是数据驱动表现。开发完成（某个阶段），需要进行阶段性的测试，对于前端来说，我一般会模拟下后台发的数据，以尽量确定联调出现的问题不是前端的问题。最后就是联调和需求完整的自测。

验收

开发和自测完成，要通知伙伴进行验收，通常会有PM，策划，美术（多是确认美术效果）及其他依赖此需求的小伙伴。处理验收反馈和bug，然后转测，通常还会处理一波反馈和bug。

归档

归档的目的一个是在于方便其他人了解需求和功能，这部分用的最多的就是通用部分的接口查询。另外一个是方便自己review，以减少日后review的成本。出于此目的，我的文档通常依顺序包含如下几部分：

• 需求文档&视觉稿，以方便了解需求
• 参与者，以方便日后找解决问题的人
• 公共接口，方便外面查询和使用
• 工程制图，大部分是建模的制图，方便日后自己和他人review
• 备注，常用的包含一些TODO，以及其他的说明