我们的游戏在通关后有一个联网的排行榜，这个是我负责开发的，主要就是打通前台跟后台的网络通信。在团队刚开始决定要做这个排行榜的时候我还是很开心的，因为我就是那种喜欢对着黑框框敲代码的类型，我拿起了之前丢掉的后台代码，开始着手搭建服务器，大概花了两天的时间，实现了单语言前后台通信。 当我信心满满准备将我们现在的框架接入通信时，简单看完框架的网络组件后我傻眼了，我的后台完全是用几行简陋的代码拼凑出的一个骨架子，非常原始，还没有成熟的网络层，而框架的网络组件是已经内置好网络层的，如果我想要两者对接，那么我必须要在后台搭建起一个简易的网络层。

这显然是不可能的，因为实力有限，眼看着项目时间过半，这样下去最后这个排行榜功能可能就出不来了，而且因为我同时还在部分管理项目，在我沉浸在后台的这几天压力全部落到了策划头上。思前想后，最终我决定前台也抛弃网络层，用C#写一个原始的通信脚本，完全舍弃框架的网络组建，一来我不需要大量时间去学习框架，而C#我是有一点基础的。二来这样更节约时间，即使最终做不出来，也可以当场放弃专心管理项目，正所谓身轻好掉头。 说干就干，决定了方向后我立马打开百度“C#套接字编程”，再配合上我的《C#入门到入土》.pdf，我又花了两天时间，终于实现了后台与前台的异语言通信，成功发送并接收了一个Hello字符串，至此，我松了一口气，以为工作差不多就快完成了，但还没等我悬着的心放下来，困难却又接踵而至。 前后台通信需要解析消息，我发个简单的hello，后台只需要全部拿住然后从二进制编码转化成str输出就可以了。但如果是排行榜信息的话，至少也要知道玩家和排名吧？我就需要发送一个数据结构到后台。即{Player:XX, Point:XXX}这种类型的数据。到这里我就犯难了，之前在公司用过google的ProtoBuffer，只要接入它，就无需再担心任何消息编码解码问题，于是我简单去搜索了下，发现我正在使用的后台语言因为太小众，没有多少社区生态，所以连Pb都没有支持。与此同时，留给我的时间也寥寥无几，如果这个功能再出不来，就会被砍掉。

正当我焦头烂额，吃饭都没心情之时，突然又想起了极限开发思维和我惯用的第一性思维原则，我苦哈哈的埋头写代码，却从来没认真的审视过我遇到的困境和静下心来做一个决策分析，于是我开始思考，我需要的是什么，答案很简单，一个排行榜，只要能显示用户和他的分数，再排下名就ok了。我再思考，为了达成这个目的，我需要干什么？答案是我需要让前后台能正常通信，发送用户名和分数就够了。既然如此，我遇到了什么障碍？我马上又思索并回答自己，为了发送用户名和分数，我需要接入PB,而接入PB时间紧迫而且后台语言没有成熟的生态。想到这里，我又问自己，既然这条路行不通，那么有换一条路的可能吗或者往回走？我思索了一下，换一条路的话，就意味着采用其他的编码解码协议，这同样需要时间，而我对PB有使用经验，所以时间只多不少，且不说后台语言的生态连最常用的PB都没有，如何能奢望它能有其他协议的支持呢？那么后退呢，我完全放弃使用Pb可以吗？我又开始思索，我使用PB是为了方便编码解码协议，这样不管多复杂的数据都可以方便的进行通信。想到这里我就立马顿悟了，既然只有一个用户名和分数，如此简单的结构，杀鸡焉用牛刀，我直接发送字符串，将用户名与分数用逗号隔开，服务器接到后解析成字符串然后直接用字符串简单地将其劈分成两部分，分别取出来就可以了。说到底排行榜如此简单的功能，直接发送字符串有何不可呢。至此我从技术的泥潭中脱身，现在就是造轮子阶段，简单的造个轮子比上各种复杂工具来得更快。我回到家就开始键走偏锋，垮垮的敲代码，虽然还遇到了另外的一些问题，但终于还是在最后把这个功能抢了出来。停下键盘的那一刻，仿佛整个世界都清净了。 排行榜，待我得心应手之后，一定会让你实现的。程序终是要上天堂的，最后再说一遍，后台要开始加速了。话已至此，Made In ProtoBuf!