3

游戏前端工作流程总结

 1 year ago
source link: https://www.cnblogs.com/hggzhang/p/17413240.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

游戏前端工作流程总结

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

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

image

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

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

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

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

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

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

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

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

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

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

report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK