服务端编程手记

1使用版本控制系统--不需要解释

2好的搭档--默契会有好的效率，撞出创意的火花

3保持逻辑计算部分和网络松耦合--容器外的可测试性会极大的提升开发效率

4TDD，胸有成竹，尽早单元测试--尽早发现问题

5认真思考测试用例和边界调节--我知道我想要的是什么

6迭代开发--每次只开发开发一个功能，集腋成裘

7重构要保持接口的兼容性--防止屠宰式的重构

8学习unix的文件概念--一样的操作不一样的实现

9避免分支嵌套--除了不合格的就是合格的

10全局资源适度地可见--特权阶层的权利民众也要有，但不是人人可有的

11不依赖系统默认--包括操作系统的字符集时区，TCP的断开动作

12在应用协议的基础上实现应用逻辑的开始和退出

13三段式拓扑结构｛通信Proxy｝｛游戏Server1，游戏Server2。。。｝｛数据Cache｝

客户端连接到proxy上（负载平衡的），开始登录，游戏。。。。proxy和多个游戏Server通信，将客户分派其中一个上（平衡的），并将客户端的请求和服务器的相应进行转发。对于广播消息服务器只需一次性告诉proxy受众和内容即可。较少的网络IO可以支持较多的cpu计算。不同的Server统一的将数据定时同步到数据Cache，这样数据缓存可以支持更高的共享。在发生切换服务器动作时响应更快。

14大胆细致的使用并发技术--cpu计算能力是不容浪费的

15耗时计算且执行结果不影响下一步计算时--将耗时的计算交给异步线程去执行

16适度的同步控制--粒度过细会造成频繁的锁对象检查和操作影响性能，也是死锁的渊薮。粒度过大等于同步计算。

合理的将共享资源分组，在资源组加锁。练习哲学家吃饭题目。

16.1需要使用互斥锁的数据结构，减少锁占有的时间。扮演消费者的线程避免在锁占有时间内对数据元素做逻辑计算，将数据元素从数据结构中读出来，放入一个非共享的数据中在锁外做逻辑计算。

17在无限循环中依次检查有状态的游戏角色，根据状态和当前环境做计算。这种基于轮询和状态机的模型可以驱动NPC，编写AI。

18服务器将数据同步到数据Cache，数据Cache定时将有更新的记录持久--似乎现在的NOsql更适合游戏开发。

19没有0Bug的产品和项目，理性评估市场和定位产品，争取早日上线，占领市场，培养用户才是王道。