关于游戏服务器开发的一些个人见解

参与并理解策划需求

能把事情做好的人永远是少数。程序如此,策划也如此。遇到不靠谱的策划,一定好主动沟通,弄清楚它们都在想些什么?!

隔离是必须的

游戏逻辑相关开发要占用游戏服务器开发的绝大部分时间,也是出现 bug 最多的部分。游戏逻辑的各个子系统之间直接的源码级 API 交互,会随着团队成员和子系统的增加,呈现出急剧的复杂度。更好的方案是,子系统通过唯一的中间层 API 以约定的协议与其他子系统进行交互,子系统之间实现源码级的隔离。

这种分案有很多优点:

  • 便于模块分配,降低了源码冲突的可能性,限制了单个子系统 bug 的波及范围。
  • 降低了系统的整体复杂度,便于人类的大脑理解。
  • 子系统的实现变更(重构、重写)的代价(负担)会很小,代码质量会越来越好。
  • 容易定位造成 bug 的子系统。
  • 心情舒坦,利于长寿

代码质量

代码质量是一件严肃的事情。所有改 (zao) 善 (ta) 代码质量的行为,都会获得回 (bao) 报 (ying) 的。

潜在即是必然

一个发生概率为百万分之一的 bug ,在线上运行时是必然会发生的

bug 修复要趁早

大多数没有第一时间修复的 bug ,会被遗忘。

  • 对于只给出 workaround 或准备稍后 fix 的 bug ,一定要记录在案。
  • 对于反应出设计缺陷或业务理解偏差的 bug ,最好重写相关模块。

警惕 C++ 中的 “设计模式” 和 “面向对象”

就我个人来说,我是很讨厌 C++ 的 “面向对象” 部分的,对 “设计模式” 也没有好感。我在工作中遇到的一些人,谈起 “设计模式” 、“面向对象” 来头头是道,写起代码来就很难让人恭维了。

好代码才是硬道理

协议设计

请求、回应式的消息一定要有序列 id 的概念,这样客户端可以轻松的找到与回应消息相匹配的请求消息,进而恢复挂起的执行流。

团队协作

让每个伙伴都开心的工作!

团队成员

确保你的伙伴都是热爱代码的人。

代码开放

代码是团队的共同财产,如果不开放,也便没有了信任的基础。强势的法律声明和有代码安全意识的伙伴才是保障代码安全的正途。就我个人来说,在代码不开放的团队工作时,很难维持贡献代码的激情。

代码 review

要让代码 review 成为常态,要鼓励团队成员之间的相互 review ,鼓励团队成员对任意代码的 review 和修改。代码 review 可以很好的促进团队成员之间的了解、合作、信任。

版本控制,降低冲突

首选分布式的版本管理工具,推荐:git + github 。所有的冲突都意味着某种程度上的耦合,在减少冲突上付出的努力,会节省团队成员大量的时间成本。

做一个实践者

纸(嘴)上谈兵永远写不出好代码。