'
▲ 回到顶部

从 Code 看豆瓣的工程师文化

2013-05-13cover
上周六去了 Beijing Open Party,和其他很多人一样,主要是冲着豆瓣的 Code 分享去的。(今天微信发出的文章是空白,是因为文章被微信吃掉了,非常抱歉)

豆瓣 Code 是一个豆瓣内部自己用的工具,他们实际上是做出了一个自己的 GitHub 克隆并针对自己的情况有所加强——这样你大概就能想象是个什么样子了。界面上,目前几乎是像素级地抄袭 GitHub,不过正在做他们自己的界面。

对于不了解 GitHub 的朋友,简单说明一下,其实就是一个程序员的社交网络。通常的社交网络就分享图片视频和励志小文章吧,GitHub 分享的是开源项目或代码片段,你可以在那上面看到别的程序员写的他愿意公开的代码,如果看到有人单枪匹马完成看似不可能的任务,或者写一个短小的小代码做到比大公司大投入做出的东西更好解决方案,这其实也是挺励志的吧。

令我有感触的主要是这个系统在豆瓣内部带来的影响。一个软件公司或互联网公司,如果不做 code review,我们可以猜测这家公司代码质量肯定不怎么样;但是一个公司如果不是使用高效的在线工具来做 code review,而是用原始的方法到一个会议室里面来做的话,这是一个很低效的过程,最终 code review 会沦为走过场,也会被大家所避之不及。

举个传统 code review 浪费大家时间的例子,一个项目要上线前,召集一堆人进会议室,会有数据库的、前端的、服务器运维的相关同事到场,如果一个数据库专家在会议室干坐两个小时就只为看你的十几行涉及数据库的代码,你想想这效率会有多低啊。

而有 Code 这样的工具。就能把原本需要集中的 code review 时间碎片化和异步化,这样就把时间更多地返还给相关的员工,让他们自己把握时间和节奏来做这件事,只需要看涉及自己工作的相关代码就可以。

豆瓣也鼓励在 Code 上尽量把 pull request 碎片化,对于非程序员读者,你可以理解为尽量用最小的改动来让大家做 code review,而不是一个项目完成后的超多代码一次做 code review——而这也是传统的 code review 方式难以避免的问题。

Code 平台带来的影响不只是工具带来的效率提升,更重要的是把编程社交化之后心理层面的影响。编程工作虽然是个和机器交互的过程,但更重要的其实是在用代码和人交流,编程语言写的代码主要是为方便人去读写,否则我们干嘛不用机器语言(数字1和0)去编写程序呢?不是有句名言说的“最好的代码是让人易懂的代码,并且碰巧机器也能运行”吗。在 Code 上,就像在 GitHub 上一样,你可以去关注你感兴趣的项目,可以去吐槽烂代码——但是这也给你压力,因为你的代码如果写的烂同样会被他人吐槽,所以自然地激励你去写好代码。

另外,他们也 copy 了 GitHub 里面的 Contributions 方块图,类似题图这样,这是我刚到我的 GitHub 页面截的自己的图,Code 界面现在对 GitHub 是点对点抄袭,不会有什么不同。这个图里每个方块代表一天,绿色就代表有代码贡献,实际上我没写那么多代码啦,因为 sucklessInfo 的网站是托管在 GitHub,不是每天有更新文章嘛。这个功能上线后,我是没怎么在意,不过是看到有网友说现在是会刻意地想要每一天都刷绿。在豆瓣,的确存在工程师也有这样的强迫症。

分享之后的问答环节,有人问我们公司还在用 SVN,怎么说服这帮人用起来类似工具啊。还有人问你们有没有用什么行政手段强制要提交多少 pull request,是不是每天都要刷绿等等。我想这些其实都是公司文化的问题,不在豆瓣这样开放的工程师文化的环境工作的人可能比较难理解。我虽然也没在豆瓣类似的公司工作过,但是有过刷 GitHub 的经历——很怀念大学时有一阵每天刷 GitHub 看别人代码的经历,那段时间进步很大——所以我多少能理解些吧。关于技术公司的文化。明天再写吧。

- The End -

关于 sucklessInfo

sucklessInfo 是 @undoZen 个人运营的微信公共账号(微信 id: sucklessinfo)

账号会坚持每天推送一条消息,内容主要针对个人面对信息爆炸时代的反思。

这里仅作为过往文章的存档。不接受评论。您可以关注微信账号后给我发送消息,也可以直接给我写邮件:undozen [at] gmail.com(别忘了把 [at] 换成相应符号)

也可以通过 RSS 关注本站,地址: http://suckless.info/rss.xml

除特别声明外,本站的文章使用《知识共享协议:署名-非商业使用-禁止演绎》开放部分版权