导语

如何赢得客户的信任，从而保持一个项目的持续稳定并达到最终的成功？本文作者分享了一些自己的观点：在编程能力，保证代码质量这些“硬件”前提下，也许一些“软件”比如尊重客户，和谐的团队氛围也是项目成功的重要因素。

项目介绍

客户旨在为病人提供更加优质低价的治疗方案。其主系统联合病人、医师和医保公司，根据病人的病症、体检数据、过敏情况、生活习惯和过往服药方案等信息，结合其内部一套引擎工具，检查用药过程中的问题（DrugTherapyProblem）并提出给药建议。

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

1.重视客户所重视的

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

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

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

2.从UI开始，从测试代码开始

在我们接手客户的项目以前，这个项目已经开发并且使用了五年多，在外包给我们之前，曾经也外包给另外一个公司--他们的设计和模块封装都是非常不错的。对我们而言，这既有便利，也带来不少困扰，便利在于免去了初期定义的麻烦，而要明白项目的逻辑和业务，对我们来说也是一个挑战。

我们拿到项目源代码时，发现这个项目同时使用了PostgresQL和Redis两个数据库，PG这边已经建立了五六十张表，项目中对应的模型达到了七八十个，源代码达到了1万9千行左右，测试代码更是达到1:3左右的比例，spec测试和feature测试代码加起来接近五万行，全部测试运行完大约需要三四个小时。而一般的ROR项目，都会尽量把源代码控制在行左右；这个项目能如此庞大（这还是在尽可能优化之后的结果），并且没有说明文档，也是让人始料未及的。

面对这样的庞然大物，如何开始着手是我们遇到的第一个问题。好在客户也了解这一点，一开始的几个迭代并没有特别多的逻辑功能需求。为了了解现有的代码，我们从两条路出发。一是从UI的修改开始进行开发，二是通过阅读测试代码。从UI开始实际是一个逆向了解代码的过程，同时也在进行着简单的开发，可以让客户看到我们在前进。比如某个story可能只是对CSS或者页面的文字进行修改，一开始我们很可能都不知道这个页面是哪个控制器渲染哪个页面返回的结果，这时候可以通过页面上的特征文字或者CSS的class和id进行搜索，由于项目中涉及I18n，我们可以现在locales文件中定位文字，找到相应的key，从而反向搜索出对应的view和controller。这未必是一个非常理想的方法，但是还比较适合这个有特别多lib封装和module而又需要尽早看到产出的项目。

另外一条路则是阅读测试代码，客户项目的测试代码十分繁杂，但也给我们带来了一些便利。功能测试的部分代码，由于其几乎接近自然语言，配合其详尽的测试用例，我们可以了解某一部分的逻辑需求。这个方法比较适合去了解一些“客户认为是常识，无需多言，而我们却不知其然”的需求。

3.保证代码质量

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

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

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

其次，我们会保证自动化测试代码能有高的覆盖率。我们在提交代码时有两个约定，一是每个新的方法，都必须和对应的单元测试代码一同提交，即nospecno
转载请注明原文网址：http://www.13801256026.com/pgst/pgst/3423.html