不同于独立游戏的心流开发（贫道曾做过独立小游戏，策划+程序都是自个儿，左右互博，形成了自己的闭环就开搞！），一些大型的商业项目往往涉及到多个部门不同的研发人员参与，甚至是相同部门的研发同事也存在着大量的信息差和矛盾。在饱经摧残后，贫道提出以下关于游戏程序开发的总结，与各位道友共鉴。若有不同观点或者补充，还请道友不吝赐教！
一.自我修养
1.知识的学习积累巩固
学习知识目的在于理解技术背后的原理，明白了原理才能知道那些做法一定是错误的，再结合前人的实践和自身需求为业务解决方案提供理论的支撑。
2.行业规范
软件工程是一门工程学，它要求多人合作完成，并且能够保持稳定，不要发生事故。这就要求我们共同遵守相关的约定，养成良好行业规范（如结构命名规范，工作归档，单元测试）。
二.立项
1.确定研发方案和技术难点。
策划宣讲结束后，程序开发内部根据需求和经验提出整体的解决方案思路，梳理业务模块和技术难点，准备反向宣讲。
2.反向宣讲
和策划深入讨论，确定技术方案的可行性和一些边界问题。向管理层和技术总监汇报解决方案和技术成本。
3.Demo研发
确定业务模块开发人员归属，重点攻克技术难题，并建立项目基本结构。
三.与策划同学的合作
1.需求的变更
策划变需求是老传统艺能了，同时也是他们的工作需要，首先要在态度上做到互相理解（如果一直变，就是他在搞你了，上去邦邦就是两拳）。在需求确定时期，一定要谨慎，根据自身经验提醒策划一些业务领域常见模块。在开发时期，注意“隐藏或可能的需求”，注意程序设计的开闭原则（即对修改关闭，对拓展开放）和模块设计的原子性。当需求变更时，告诉策划变更成本（尤其是导致重构的时候），决定是否要变更需求，并重新进行排期。
2.版本排期后新需求的进入
原则上在版本排期之后进入量产阶段时，是不允许新的需求再进来的。但是在实际开发中，因为种种原因，还是会有一些新需求进来。这种情况下，要仔细分析需求，必要时要和策划及产品经理重新安排工作的优先级和排期。一定要保证自己的工期合理，毕竟压缩工期是导致工程事故的主要原因之一。
3.配置
需求交付时，必要时给出说明文档和自动化检查或者配置工具。在配置解析中，加入配置合理性检查，并生成配置错误日志。
四.与程序同学的合作
1.确定规范
确定行业规范（命名规范，代码书写规范），并尽量统一代码风格（例如：有人用willxxx表示在函数xxx之前执行，而又有人用prexxx表示）。尤其注意游戏开发常用LUA这种非常灵活脚本语言，由于反射机制和自身封装性差的原因，一定要代码书写规范。（举个栗子：x = a.b; 改成 x = A:getB(); )。确定开发的一些原则（如尽可能不要修改别人的代码，如果一定要修改要申请别人的授权，改完知会对方相关的信息）。
2.面向接口编程和代码隔离
分工合作完成某一模块，尽量不要产生代码文件的交叉，避免git冲突以及互相插代码的风险，减少一部分人代码结构混乱对整体项目的影响。理想状态下，我们只需知道对方提供的接口或者父类的生命周期，不需要知道对方的代码细节。
3.接盘
接盘是一项十分痛苦的工作。一定要搞清楚需求，然后拽着甩锅的人理清开发思路。正常情况下，接的锅很少是代码结构十分清晰的，要顺着甩锅的人的思路继续开发，如非必要不要重构！
五.项目总结
主要包含个人总结，程序研发部分内部总结，项目总体总结。除了技术经验的积累，也要留意项目流程的优化，和对项目成功因素直觉上的培养！
|