参与并理解策划需求
能把事情做好的人永远是少数。程序如此，策划也如此。遇到不靠谱的策划，一定好主动沟通，弄清楚它们都在想些什么？！
隔离是必须的
游戏逻辑相关开发要占用游戏服务器开发的绝大部分时间，也是出现 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 。所有的冲突都意味着某种程度上的耦合，在减少冲突上付出的努力，会节省团队成员大量的时间成本。
做一个实践者
纸（嘴）上谈兵永远写不出好代码。