CODE－豆瓣代码托管系统

Douban CODE 是豆瓣开发的一个基于 git 版本控制系统的协做平台。

代码访问：https://github.com/douban/code

CODE —— C: Community O: Original D: Developer E: Eldamar

目前 CODE 仅开放了一个框架，支持：

• clone & push project

• create project

• create user

准备环境

• MySQL

• Memcached

• Python >= 2.7

• pip >= 1.4.1

• virtualenv

• git

CODE 为每一个项目设置了三个角色，分为 owner（有所有权限）、committer（有 push 和 merge 权限）、member。review 机制根据项目的不一样设置了不一样的规则，如产品线级别的、须要对外发布的项目，基础库等项目都须要通过严格的 review，如东西团队对 review 设置了以下规则：

• 尊重他人，就事论事，对事不对人，毕竟每一个人都写过烂代码；

• PR 中的每个 commit log 都应该能够和代码对应，方便 review；

• 尽可能不要发太大的 PR，以避免引发 reviewer 的恐慌；

• 建议保证一个 PR 的粒度和专一，最好不要出现一个 PR 里又有重构又加新 feature 的状况，一样容易引发 reviewer 的恐慌；

• 提 PR 以前请确保在本地或测试环境一切正常；

• reviewee 若是接受 reviewer 提出的修改意见，须要在修改提交之后知晓 reviewer，常见的作法能够是在 review comment 处回复（并带 commit 连接）；

• 评论中至少出现一个 lgtm 且保证 ci 经过以后 PR 才能够被合并；（注：lgtm 即 looks good to me 的缩写）

• PR 合并者与提交者不能是同一我的；

• PR 需从一个特定分支（分支的名字尽可能能表达代码的功能）发往上游的 master 分支；

• Model 的部分，如不紧急须要unittest；

• Web 的部分，如不紧急须要webtest；

• PR 合并后如引发 bug 或功能异常，并经查确为此 PR 引发，提交者需请全组攻城湿喝饮料或吃冰棍（由被请者决定）；

• 将 fork 的仓库与上游同步时，应使用 git fetch upstream && git rebase upstream/master （或 code sync -r ），而不是 git merge 或 code sync （这里code是指面向 CODE 系统的一个命令行工具），以保持清晰的提交历史，并防止覆盖他人的修改；

• 注意安全问题，对于 SQL 拼字符串，模版中有 |n 的，以及处理用户输入等地方都须要仔细review，更多请参考 Web 安全开发指南

对于松散或娱乐性项目、小工具项目，并不会那么严格的 review，这也取决于 owner 本身，他能够借这个项目寻找到一位导师，来帮助他进行 review：

举一个具体的例子，例如东西团队的 Android 版本的开发，实际上最开始只是团队内部的一些成员想学习 Android 开发自发组织起来的，但一开始就找了移动组的同窗来随时帮助 review。

对于 CODE 项目自己，全部工程师均可以向 CODE 上的任意项目提 PR，也均可以是CODE 的 reviewer，同时全部工程师的代码都须要通过 review 才会被 merge 到 master 分支。

发展到如今，豆瓣的 review 基本上都是自发，不多遇到须要 review 的代码堆积的状况。代码讨论区里听说时不时会出现美女图，这多是刺激工程师们去 review 的因素之一；另外，CODE 系统自己也有奖励机制，鼓励你们去评论别人的代码。

CODE 系统的奖励机制主要有积分和勋章这两个部分。积分的规则主要就两个：

1. 提交的 PR 被 merge，增长 100 点积分

2. 提交的 PR 被评论，增长 5 点积分

目的就是鼓励多发 PR。通常来讲，小 PR 要好过大 PR，不过有时候开发任务比较紧的时候，发出比较大的 PR 也是在所不免。

勋章系统在 CODE 早期阶段就作了进去，早期的奖励规则主要跟代码提交相关，例如给开源项目发过 Patch 并被 merge 会有相应的徽章。如今 CODE 团队对勋章系统有一些新的规划：

目前但愿徽章系统能够独立出来，只是一套独立的API，任何人任何产品线均可以去设置本身的奖励规则，让这种奖励变成不是一种公司行为，而是更小的行为。 例如 antispam 组，可能就会有百人斩徽章，这个对于其余组可能就不是那么必要，固然若是你跨界帮助过 antispam 组，那么也有可能会得到这个徽章。

CODE 上没有设置惩罚机制。

测试

相比 Github，CODE 有一些很是实用的地方，好比在提交代码入库以前能够先在 CI 里面完成自动测试，reviewer 能够直接看到代码测试是经过（绿色）仍是失败（红色）；代码完成 merge 以后还能够经过 DAE 直接往线上部署。持续集成、自动测试、监控、部署这些都是独立系统，与 CODE 都是靠 API 来进行交互。