Vimer的程序世界

马上就要到羊年了，给大家拜年啦！～

因为一些习俗原因，今年没有像以往一样，早早飞回老家，而是要在深圳这边过完年三十，初一的早上再飞回去。
其实就算是提前回老家，工作这么忙，估计也不会多提前几天的。

这两天留在深圳，看着深圳原本最拥堵的车道都变得畅通无阻，也确实证明深圳有多少像我一样，远离家乡，在外拼搏的人。
这也是我喜欢深圳的原因之一：来了，就是深圳人。

深圳是包容的，只要你有能力，那么就一定能找到那个能展示你能力的地方，如果找不到，那只能证明你能力还不够。

其实从我在武汉上大学开始，再到深圳工作，这一路向南，有很多人跟我说，还是回老家好，在外面干几年，就早点回来吧。
最早的时候，我也在纠结，我应该怎么做。
我的高中同学，基本都留在了老家，或者出来，又回去了。

开始的时候，我这样说服自己：如果就这么回去老家找个轻松的工作，那么当年又为什么要离家那么远读大学？
再后来，我看到了一篇文章，他是这么说的：在外漂泊，本身也是一种试炼。一部分人会留下来，一部分人会回去。而留下来的更小一部分人会爬的更好，更好，成为这个城市的中坚力量。

而我选择，通过这场试炼。

然而，我也知道 ...

有段时间没写创业相关的文章了，这篇算是对之前一些想法的总结吧，记录在这里。

一. 得失

前段时间和朋友一起吃饭，朋友问我，创业后是否有后悔过？

这个问题其实我自己在内心里早就问过自己很多遍了。这个问题还是要从创业的初心开始说起。

当时离开腾讯的最大原因在于到达了职业发展的天花板：

• 技术成长。业务已经基本处于稳定阶段，不再有之前从0到1、或者从1到100的机会。
• 管理职位。由于业务扩张缓慢，所以一堆人都基本处于等位子状态
• 业务方向。腾讯的业务向来慢别人一拍是业界常识了。当时手机端已经崛起而开放平台的老大们还抱着页游这颗摇钱树不放，注定业务在短期内无法再高歌猛进。应用宝13年上半年才合入开放平台准备发力，可见一斑。

所以如果我当时如果选择留下，当组长确实没有问题，但是技术能力也会基本停滞了。

但创业则是完全不一样的事情，无论技术上的深度还是广度，都是在大公司当螺丝钉是无法比的。

比如你要自己从头封装一套socket的网络通信库，包括服务器端和客户端。

比如你要设计好服务器的架构模型，并且要对其稳定性、性能、可扩展性承担最终责任。

再比如你要设计好自动化运维的各个部分，包括监控、告警、运维统计、运营统计、各种报表，大公司已经有的那一套，你都要重新实现一遍。

这个过程很痛苦，我切身的经历过，但现在，这些东西，全都是ready的，而这种成就感，是无以言表的。

但是，实事求是，除了技术的追求 ...

之前一直用友盟的自动更新功能，但是友盟一直没有内置实现强制更新的功能，如果要在其基础上模拟实现会很麻烦，所以干脆就自己做了。

其实实现上比较简单，这里跟大家介绍下。

1. web接口

需要提供一个接口供客户端查询更新状态，并且在需要更新时，告知客户端新APK地址。

接口参数如下：

• package   包名，因为有时候会出现同一个应用换包名打包的情况
• version 版本号，即android清单文件里面的versionCode
• channel 渠道号
• os 操作系统，android/ios。ios 这里仅作预留。

之所以传入这些字段，是要在与服务器端的包匹配时，务必满足：

package, channel, os 相等，并且服务器端的version 大于 客户端传入的version

代码如下:

os = request.GET.get('os')
pkg_name = request.GET.get('package')
channel = request.GET.get('channel')
version = request ...

工欲善其事，必先利其器。

其实这篇文章到现在才写，也是想将这些工具都经过时间的验证，确保没有问题才分享给大家。 接下来咱们就一个个来说。

1. 任务管理

推荐： http://tower.im

任务管理的重要性毋庸置疑，然而小团队一定要注意的是，避免陷入大公司繁杂的需求跟踪流程里面去：腾讯的tapd就是很好的例子，详尽，什么都考虑到了，但也同时导致用起来份外复杂。

其实还有一个做的比较好的任务管理网站：https://www.teambition.com，只是因为一开始就用的tower，没有太多问题，所以就懒得换了。

2. 代码管理

推荐: http://bitbucket.org/

既然用bitbucket，版本管理软件肯定就是用的git了。

可能有些朋友会推荐用 http://github.com，其实如果舍得花钱的话，确实github会更出名一些。

我这里推荐bitbucket，很大原因是因为他私有仓库是完全免费的。

当然，最近国内的开源中国也宣布其私有项目完全免费了，和tower同样的原因，因为之前已经在用bitbucket，所以就懒得换了，有兴趣的同学可以去看看：http://git ...

这几天的心情非常好，主要原因是我们把服务器端的架构升级到了 2.0，这样最大的一个好处就是：

Server重启完全不会影响外网服务

所以，也是想趁此机会，服务器端整个发展的历程，跟大家分享一下，干货比较多，框架代码也会全部开源：）

一. 农业时代

创业最重要的就是一个“快”字，所以最开始的时候，所有的架构都以快速出模型为前提。

而常看我博客的朋友应该知道我对python情有独钟，所以自然的，python成为了我开发服务端框架的语言。

python自带的多线程tcp服务器框架非常简单：ThreadingTCPServer，即每个链接一个线程的模式：

import SocketServer

class RequestHandler(SocketServer.BaseRequestHandler):
    def handle(self):
        f = self.request.makefile('r')

        while True:
            message = f.readline()
            if not message:
                print 'client closed'
                break
            print "message, len: %s, content ...

还是继续聊创业的话题，发现关于创业，的确可以聊的东西太多了。

今天主要聊聊招人和培养的事情。

一.一分钱一分货

之前一直在招聘上蛮控制成本的，招进来的人能力都比较差，甚至很多都是毕业生。导致团队内无论是开发进度、质量都十分的差，而由于员工的心理成熟度和职业化程度不够的原因，从而导致一系列管理成本的提升，如离职、负能量传递、情绪不稳、责任感不强等。

所以最后算下来，我发现，看起来在省钱的事情，其实最后都是在赔钱。

其实解决这个问题的方法很简单，简单到和个人处事的方式一样：不要妄想占便宜。

一分钱一分货，不要指望物美价廉，更多的时候，必要的付出是完全值得的。

所以后来，客户端这边我们招了一个能力蛮强的人进来，结果发现客户端这边的架构搭建、任务分配跟踪等，我都不用像以前那么操心了，而且开发进度和质量也比之前好了几个数量级。

二. 对应的人，对应的事，对应的钱

前面提到了牛人在团队里的作用，那是不是就该尽量多的招牛人呢？

未必，毕竟创业除了理想，还是得脚踏实地现实点，而这个现实就是你有多少钱？

遇到一个牛人，愿意接受创业公司那点薪水，又能和你志同道合一起为渺茫的理想拼搏，这本身已经是一件可遇不求的事情了。

所以如果一旦出现一个就该牢牢抓住，别让他跑了。

但是大多数情况下，我们只能在简历库里搜索一份份平淡无奇的简历，从中筛选出你想要的那些人。

所以，更多时候 ...

敲上了这个标题，还是理不清自己想写下什么。
其实我只是想真实记录下自己创业路上的感受，前面三篇可能更系统些，毕竟带有总结的性质。
而这篇可能就更随性一些。
公司从成立开始就不停的有人离职，自己也已经开掉两个人了。
无论是被员工炒还是炒掉员工，感受都不是那么好。
一开始收到辞职申请的时候，自己还是蛮难受的，尤其是那个人可能还是你想培养的人的时候。
但是慢慢的，也就习惯了。
本来就表现不好的，当天提了离职，当天就让他交接完事情，第二天就走。
表现好一些的，示程度一起聊聊天，挽留一下。
但是挽留基本也都是没啥用的，反正目前在我这还没有成功过一个。
其实我始终认为离职，就跟男女分手一样：分手的原因一点都不重要，重要的是结果。
所以基本上离职我都会问一下，对公司有什么看法，也许离职唯一的用处就是可以让我能够清晰的听到他们对公司真实的看法，来杜绝之后类似事情的发生。
这几天连续处理了几个离职的事情，乃至于今天又听到离职申请的时候，我都已经不想再谈理想，谈职业规划，谈收益。
但接下来我还是和他聊了两三个小时，因为这个就属于我认为重要的那部分员工。
员工和老板也许真的很难站在对方的角度上思考。
就像我不能理解： 为什么我允许你上班迟到15分钟，中午有两个小时午休，醒的却还是晚半个小时，但晚上让你加班到10点之后几分钟，就有人吵着说要回去？ 员工的角度上只能看到自己的利益，全盘的利益是看不到的。
员工看到那个被我辞掉的员工，会自动把那个人替换成自己，从而同情那名员工，而认为我做的很残忍；但是却看不到因为一块短板的存在，导致整体的进度收到影响，从而影响了他自己最终的收益 ...

发现自己经常会一篇文章写了（一）之后，很久都不写（二），搞得最后自己都快要忘记了，所以这次赶紧把统一支付的文章给补上。

上次的文章中将统一支付的v1版本已经讲解ok了，但是还剩下两个问题：

• 服务器端没有办法做分布式
• 客户端对支付sdk进行插件式管理十分困难

我们一个个来说

一. 解决服务器端分布式的问题

解决这个问题的核心思路比较简单：

之前我们是把event的通知放在进程内存中，现在我们做成网络通信

由于支付的请求量本身不属于高并发，所以就放弃了打算直接写通知server的想法，转而看一下有没有什么简单的解决方案。

而由于自己之前redis的使用经历，恰好知道redis有一个pubsub模式，很适合做这种监听和通知的工作。

python的实现示例代码如下：

import time
import config
from share.vals import rds
from share.utils import safe_str
from gevent.timeout import Timeout
from urllib import quote, unquote

class RedisPubSub(object):
    """
    用redis订阅/发布消息
    """
    # 订阅频道
    sub_key ...

其实想跟大家分享这套支付系统的架构已经很久了，今天总算有时间写出来了。

先说说这套系统的需求由来吧：

1. 笔者公司的游戏产品已经有几款了，每次上各种渠道都是要搭配不同的计费方式，并且每开发游戏都要重复一遍痛苦的接入sdk流程
2. 游戏的支付需要出各种报表以及统计，每个游戏单独去做对人力的消耗巨大

基于以上几点，我这边设计了统一支付系统。

这个系列一共会分两篇文章，分别对应系统的v1版和v2版，我们这一篇先从v1起介绍。

在仔细分析了国内的大多数支付sdk之后，我们梳理出游戏的支付流程大体可以实现为两类：

• 第三方sdk服务器进行支付结果通知
• 第三方sdk客户端直接返回支付结果通知，没有服务器支付结果通知。

对于调用方而言，这两种方式各有好处。

• 第一种方式更加安全，但是支付调用的时间相对较长
• 第二种方式速度更快，但是很容易被不怀好意的人破解。参见之前的文章：google支付接口被刷以及解决方案

接下来，我们来看一下我这边设计的统一支付流程。

客户端:

服务器端：

简单解释一下：

• 每次支付开始，都要让服务器生成一个订单作为此次支付的记录，订单的id即为 bill_id。订单有4中状态：订单生成，支付失败，支付成功，发货成功。
• pay_server即为统一支付系统的服务器端，考虑到调用量和方便调试，使用了简单的http协议+json+sign的方式

对于服务器内部，唯一麻烦的一点是，《等待pay_server支付结果通知》这个接口。因为这个http请求需要支持挂起，在第三方支付服务器通知了pay_server之后，pay_server 根据通知里面透传的bill_id 将订单状态修改后，再给客户端结果 ...

接着上一篇继续，前面两篇算是把从创业开始发展到今天的整个过程大体说了一遍，但是接下来的文字才是真正我想要和大家分享和探讨的。

这个话题就是：作为一个技术合伙人，职责到底应该是什么？

其实随着公司的发展，我就一直在思考这个问题：一方面是来自于担心公司技术进度失控的不安全感，一方面是来自于自己不再有太多时间编码，而带来的对自身技术能力落伍的担心。

还是按照创业的阶段来说吧。

一、创业第二阶段-队长

这个时候，公司可能就3、4个人，一个产品、一个前端、一个后端。什么技术合伙人、技术总监之类的，没必要在意这个名字，这个时候，唯一的要求就是做出产品。

而这个能力，又分两块：

1. 自己编码的能力

2. 设计架构，主导技术开发的能力

这个时候，更像一个队长。你要带领几个队员，但你自己也要冲锋。

你要能够将产品解构为代码实现，你要熟悉整个产品的研发，无论前端还是后端。

这个阶段，是非常关键的为团队打基础的时间。

在产品的实现过程中，要逐渐规划出自己的技术框架，将底层、公共逻辑拆分出来，为下一个阶段做准备。

而队长，就是要将这些东西，在这个阶段尽快沉淀、积累下来。

举个例子，服务器端语言用什么？python。web框架用什么？django ...