我的ODC项目经验分享

 

在三年的合作过程中，我们不断丰富其主系统的功能，提高用户体验，降低页面响应时间，并对过去的代码进行重构和完善。项目后来变得越来越庞大，我们将其中三个次要功能抽出作为服务，于是我们又多了三个新的子项目。 今天，我们打算分享一下我们维持项目稳定的一些因素。

对于客户来说，这个项目应用于美国，同时涉及到病人的隐私信息存储，因此，客户一开始最重视的并不是我们对项目的理解程度和开发进度，而是信息和代码的安全和保密问题。这个项目基于HIPPA（Health Insurance Portability and Accountability，中译：健康保险携带和责任法案），对于客户来说，只要发生一次病人隐私泄漏，他们就无法继续运营了，因为美国对此要求及其严格--“病人的隐私高于一切”。

 

在项目初期，客户对安全保密这方面极其敏感，我们也不得不小心应对，一再承诺我们的邮件只会使用公司专用邮箱，信息不会发送到私人信箱，定期分析服务器日志，同时也不会在外网开放访问权限。我们认为，此时取得客户信任，比进入迭代开发更加重要，因为这意味项目是否能真正开始。为了向客户展示我们的诚意，我们申请在苏州分公司单独隔出一个小办公室，安装有单独的门禁系统。此外，为了进一步确保安全，也申请了专线网络。这一切，都是为了告诉客户，我们和你们一样，甚至比你们更重视信息隐私工作。

 

尽管如此，还是会有些意外的小插曲。在我们接手项目不久，有家公司开始申请注册PharmMD作为他们的商标，客户发现了这件事，于是来询问我们。虽然说不上“危机公关”，但在那个敏感时期，这件事也确实也让大家紧张了一回。于是，我们开始调查这件事，发现这只是一个巧合，正好只是一个药妆公司在申请商标，并不涉及到我们的员工泄密或者恶意抢注。药店使用Pharm开头的单词作为品牌十分正常，比如连锁的PharmPlus药房。这件事细说起来其实和我们没有关系，但是为了安抚客户，后来还是做了一系列说明工作。

如何保证代码质量，准确的说，和客户合作的这三年，我们和客户其实在共同探索这个问题的答案。

 

一开始我们每周会有code review meeting，确实有些效果，但是就我们实践下来觉得效率并不高。当review某个人的代码时，reviewer如果不了解前因后果，可能会觉得相当乏味，而且那时团队里有五名开发人员，每周花一个下午review所有人的代码要消耗相当多的时间，往往在会议进行半小时以后，大家打酱油的成分就变多了，因此这种会议大概只持续了半年。那之后我们之后是如何保证代码质量的呢。

 

首先，针对RoR项目，我们有许多约定和代码风格规范，成员们尽量尊守这些约定和规范，另外我们还有一些工具可以对代码风格进行检查。具体的代码风格规范，可以参照RubyChina上wiki里的相关内容，在github上也有ruby和rails的风格标准化文档。而工具方面，我们可以用rails_best_practice来检查项目中的代码风格问题，同时也会利用brakeman来扫描项目中是否存在安全漏洞；不过这些工具毕竟是机械化的扫描，所以经常会遇到他们过于敏感的问题，所以有选择性地修改一些就好。

 

其次，我们会保证自动化测试代码能有高的覆盖率。我们在提交代码时有两个约定，一是每个新的方法，都必须和对应的单元测试代码一同提交，即no spec no commit，二是修改完现有代码后，至少应该保证spec测试能全部通过再提交。 最后，虽然我们取消了code review meeting，但我们仍然有代码review的工作。由于我们使用Github做版本管理，所以我们使用了其PR（pull request）功能。对应每一个user story，程序员开发时会建立自己的开发分支，分支的名字一般用story ID加功能描述命名，当整个story的工作完成后，开发者建立一个PR，请求将当前分支的代码合并到主开发分支上。在PR中，程序员会先@一位对相应代码或者需求比较了解的组员进行初步review，如果reviewer对有代码疑义，则会在对应的代码块进行备注，接下来就需要进行讨论或修改；如果没有疑义，初步review通过，则会进入final review的阶段。在我们的项目中，final review是由客户方的一位技术人员进行把关。Final review也通过后，开发者就会将代码合并到主开发分支上并关闭PR，接下来测试人员就可以对该功能进行测试。 此外，尽管如此层层把关，终端用户在使用时，还是会因为一些没有设想到的操作，或者系统原因而遇到一些错误。这时候我们使用Airbrake记录每一次程序报错和error stack，便于我们进行修改；也会利用NewRelic，捕获项目中存在效率问题的部分，以便我们在重构时有优化的方向。

我个人认为团队的人情味和项目的稳定性是相互影响的。只有项目稳定了，团队里的组员才能有足够的时间磨合和培养默契；而大家足够团结时，才有机会让项目稳健地进行下去。

 

我们比较期待team building活动，虽然只是吃喝玩乐，我们还是能争取则尽量争取。于是乎大家似乎或多或少都学会了三国杀，我也能在台球桌边装作姿势还不错的样子（不过基本打不进球）。也就是在这些玩闹的过程中，大家增进了解，也会明白各自处事的方式。我们的团队虽然不大，算上汉族，我们居然有四个不同民族的成员。多样性带来了很多不一样的观点，也带来了一些创造性，我觉得这可以算做是一个团队的asset。

 

同时我们对待客户也是比较有人情味，大家遇到节日会发送问候，遇到有人结婚生子也会发一些祝福。有次客户那边有人结婚的时候，我们从亚马逊给其买了一些小礼品；又或者我们会把团队的照片做成明信片再寄给客户。我觉得看得见摸得着的实物，比网络上的文字更能打动人。

 

如果说编程能力、代码质量是硬件，那么人情味就可以算是一种软件，二者都十分重要。