序言

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

流程

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

需求宣讲

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

需求分析

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

预研

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

建模

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

依赖确认

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

反向宣讲

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

开发

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

验收

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

归档

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

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