升级之路
首发于升级之路
为什么我喜欢工程师文化

为什么我喜欢工程师文化

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迷云》


自主决策

上面讲的这些工程师文化的方方面面, 各个优秀的团队都绝对也一样有这样的工程师团队。 但唯有一点, 我是觉得只有我司是特别的。

套用一段之前在高德干活的拉总讲的话: “我以前在高德,做的事情是领导分给我的。 我的领导呢,做的事情也是他的领导分给他的。 所有人要做的业务、要使用的技术都是相对固定的。 但是在再惠,根本就是怎么好怎么来。 而且实话说,我以前根本没有想象过,工作能这么开心!”

拉总总是这么睿智(棒读)。

政治老师说过, 我们答题要用总分总的形式容易得高分。

看来工程师文化令人喜欢的一个原因, 就是工程师们也十分令人喜欢呀。

(完)

编辑于 2018-07-27

文章被以下专栏收录

    没错,我们就是想招人。公司主页上没啥东西,有兴趣的同学可以去拉钩看我们的招聘职位:https://www.lagou.com/gongsi/j86312.html