Mia 公司的母公司是 3G资本，
她前几天突然好奇公司的文化是怎么样的，
就去找了相关资料读了一遍。
然后 Mia 惊奇地跟我说：
“我发现 3G资本 对人才的要求特别神奇。
三个关键词是 smart, poor, desire to be rich…”
空气中顿时充满了快活的笑声。
后来我又想，
我司有什么企业文化呢？
假如要我来说的话，
大概就是 工程师文化 吧。
工程师文化
看美剧的时候，
我们会发现美国人一楼总有一个车库，
车库的工具箱里装着各种各样祖传的实用工具，
Mickey/Rick/Baymax 都是从车库里走出来的。
软件工程师的工程师文化跟这个场景也很像：
- 在实践中学习
- 用工具解决问题
- 自主决策
我很喜欢这样的工程师文化。
具体来说，
我们举一个B轮公司的研发部门为例子，
也就是我目前在的公司：
再惠（上海）网络科技有限公司。
在实践中学习
我司有一份文档，
叫 the Hitchhiker's Guide to ZaiHui Dev，
俗称“新手村任务”，
这个文档大概长这样子：
文档里的章节包括搭建开发环境、
熟悉基础业务、参与合作流程、认识基础架构、
还有名为 DLC 的包括权限、队友、小脚本等附录。
除了这一套完善的文档以外，
每个人还配有一名 buddy，
就像老刺客带新刺客一样，
新同学在万物皆虚万事皆允的路上不管有任何问题，
都是可以抓着 buddy 问个透彻的。
比如其中后端的新手村任务大概长这样子（节选）：
- 玩 API
- 本地跑一个 server，尝试用接口获取 id=1 的商户信息
- 尝试用测试环境的登录接口，拿到自己的 key
- 想办法给所有测试环境添加自己的权限账号
- 通过调用 api 的方式修改自己库里的用户名
- 玩 DB
- 在测试环境入个会
- 在代码里找到“阿瓦达索命”相关功能，注销掉自己的账号
- 研究发验证码的代码 (pin.py) 到测试环境给自己设一个永久验证码
- 写 Bug
- 尝试搞挂<惠吧烤鱼>这个公众号，让微信提示“该公众号无法提供服务”（记得修！不然测试爸爸要叫！）
- 尝试不用 random 库，写一个有几率会挂的 ut
- 写一个循环引用，让所有 ut 都挂
- 尝试去测试环境改一下代码，然后搞坏该环境的发版（期待结果是在 pull_new_code 的时候报错）
一般来说，
有 python 经验的同学可以在一周左右做完新手村任务，
了解我们的主要业务和后端的大致实现框架。
刚毕业的同学也可以在整套流程中认识到 RESTful/MySQL/Git/Jenkins 等开发流程。
对应的，我们还践行 DevOps 的原则，
就是 Eat your own dog food。
不仅包括开发+架构设计+环境搭建一体化，
还包括可以瞎比玩别人的测试环境，
一个环境我搞挂了就得我来修，
不修的话就会被拿刀抵在背上来修（并不）…
用工具解决问题
截止到目前（2018年7月）为止，
我司技术部门（各端研发+测试）一共不到60人，
对应我们年费制的数千家商户，
平均下来每个人支持了100家商户。
这么想想敏俊（96年的刚毕业小帅哥）也支持了100家商户，
想想也为他感到有点小激动…
这里就是我们用的大量工具起到了杠杆的作用，
放大了每个工程师的生产力。
当时我被面试的时候，
谢老板的一句话给我印象很深：
“能用工具解决的问题，
我们是不会让工程师上的。”
具体来说，
我们看一个典型开发流程所要经历的一些步骤。
迭代
我司一直跑的是敏捷开发，
早期用的是 Trello。
那时不仅产品不多，
产品经理也不多。
后来队友逐渐在增加，
就尝试用了 Jira。
Jira 的好处是它功能强大可配置，
配套的 Confluence 等设施完善。
但是因为配置起来比较繁琐，
也没有让我们自己反复调整的时间，
大部分队友也就不太适应 Jira。
后来一直到现在我们在用 Teambition。
目前每个产品线有自己的敏捷面板，
每两周一次迭代，周一计划会，下周五回顾会。
每天早上晨会，大家除了过一下昨天的进度和今天的计划，
还会主要把一些小的疑问/困难放在晨会里说出来，
10 个人的晨会大概 10 分钟就结束了，效率巨高。
前几天面试的时候，
一个唯品会的小姑娘好奇地问我：
“你们的迭代是两周定时的么？”
我意识到其实不同团队对迭代的执行细节不一样，
就跟她解释了一下我们对迭代的理解：
“其实迭代就像地铁班车，
我们是写死两周一班车，
这个迭代能做完什么就做完什么。
车又不等人，做不完的下个迭代再做就行啦。”
VCS
我们用的版本控制工具是私有部署的 GitLab EE。
除了 Repository，
还用上了里面的 Merge Request/CI/CD/Docker Registry/Wiki 等功能。
比如举我们的机器人 KevinBot 为例，
假如想要给 Kevin 加一个新功能大概流程是这样的：
- fork 项目到本地开发
- push 到自己的 repo，提一个 merge request
- 触发了 CI 检查
- flake8 检查一波有没有语法问题，比如用了双引号、忘了写逗号
- django 检查一下有没有 migration 上的问题
- 跑完全部 ut，看看单元测试能不能过
- 跪求 code owner 来 review 自己的代码
- 会有线上评论，不好解释的会线下解释一波
- 有问题就打回去改了，重新 push
- approve + merge
- 自动触发了 docker 的自动构建
- 构建完成以后自动触发了发版，kevin 机器人发版完成
整个过程中 contributor 需要 fork + coding + merge request，
code owner 需要 review + approve + merge，
剩下的单元测试、镜像构建、版本更新都是一条流水线做完的~
于是小机器人就更新了一个又一个并不实用的好玩功能
监控
我们的监控系统分为几块。
所有监控的告警我们用的是邮件 + 微信机器人。
机器状态的监控我们用了云平台的自带功能 AWS CloudWatch，
业务的状态、日志监控我们用了 ELK 整套系统，
还有最直接实用的错误监控我们用的是 Sentry。
比如说一年前每周都有好几个发版夜的时候，
大家都是一边看着 Jenkins console log，
一边看着 Sentry 看看会不会蹦出来一些 error log。
有的话当然就火线编程了！
（于是当时就有这样的九核围观的梗：
后来我们终于迎来了正规军测试小伙伴的加入，
Sentry 依然还是我们在测试环境用的一个非常有效的 debug 手段，
不论是 error 还是 warning，
Sentry 上的每一个错误都有几率被抓起来吊着锤。
有一次 Sentry 变慢了一些，
都被敏锐的旭总察觉到了事情并不简单，
从而牵扯出了一桩案件：《破案·Sentry迷云》
自主决策
上面讲的这些工程师文化的方方面面，
各个优秀的团队都绝对也一样有这样的工程师团队。
但唯有一点，
我是觉得只有我司是特别的。
套用一段之前在高德干活的拉总讲的话：
“我以前在高德，做的事情是领导分给我的。
我的领导呢，做的事情也是他的领导分给他的。
所有人要做的业务、要使用的技术都是相对固定的。
但是在再惠，根本就是怎么好怎么来。
而且实话说，我以前根本没有想象过，工作能这么开心！”
拉总总是这么睿智（棒读）。
政治老师说过，
我们答题要用总分总的形式容易得高分。
看来工程师文化令人喜欢的一个原因，
就是工程师们也十分令人喜欢呀。
（完）
也十欢呀。