他是2013年QCon北京云计算专题的出品人，也是2014年QCon北京移动应用专题的出品人。他的团队往下做到云计算基础架构，往上做到客户端。他本人从80年代末起接触编程，在大数据处理、云计算、以及分布式系统等方面都玩过一圈。他是蒋炜航，网易技术总监，目前全面负责有道云笔记业务。
在这样一个团队中，后端和前端团队在同一个产品上工作，有紧密的协作关系。但是，底层的软件研发和应用层的软件研发毕竟有很大的区别，他们在代码提 交和管理模式、测试机制、代码的交付周期、反馈和监控体系方面都有怎样的异同？在本次采访中，蒋炜航博士会介绍有道云笔记团队的一些实践。
InfoQ：您在去年QCon北京出品云计算专题，今年则出品移动App的专题。这也对应了有道云笔记在技术上的一个特点，就是从底层到客户端都是你们自己来研发、维护、运营的。能先简单介绍一下跟有道云笔记相关的技术团队都有哪些，各自负责哪些方面吗？
蒋炜航：我们底层有基础架构组，这个组在云笔记业务之前就建立了，服务的对象不单单是云笔记，还服务有道的很多 业务。这个组也在我的团队，做的东西跟Hadoop（HDFS、HBase、MapReduce）这些差不多，是自己研发的一套系统。底层提供的东西比较 基础，只是存储和计算服务，对所有业务通用，本身不包含业务逻辑。
业务逻辑的开发都在服务器端的团队，这个团队专门是负责云笔记的服务器端的，负责处理同步、多版本、提供API等服务。
客户端包括PC、Mac、iOS、Android、Windows Phone的客户端，以及web端和浏览器插件。基本上每一层的团队都是几个人来做，不是很多。
此外我们还有个精干的研究团队，这个部门做的是一些三到六个月才有成绩的东西。方向主要是应用研究，研究的目标不是发论文，而是把成熟的技术做到产 品中。比如编辑器，我们需要做跨平台的编辑器，过去大家比较熟悉的就是Office和Google Doc，而以前很多Web based的编辑器并不适合跨平台终端的需求。我们一开始也是用Web编辑器做起来的，但是并不是很适合。我们也不可能像Office那样用几百个人去做 一个编辑器出来，所以研究部门做的事情就是，花一定的时间找到合适的方法来提升编辑器的体验。提高跨平台的体验是一个很模糊的目标，不确定性很大，具体用 什么做法要很多研究和尝试。这个团队还研究一些NLP和手写输入方面的项目。
InfoQ：有些软件产品的发展思路是求快，尤其在产品推出初期，要以最快的速度推出新的特性以验证产品的可行性；有些软件产品的 思路是求稳，尤其在产品积累了一定用户量的时候，会更加关注软件的稳定性、安全性，升级的时候不要对现有用户造成负面影响。有道云笔记现在处于怎样的阶 段，是偏重求快还是求稳？
蒋炜航：做互联网产品永远是要快的。同时，云笔记是个人的信息、知识管理工具，稳定性非常重要。要快，同时也要坚守产品质量，我们必须要两者兼顾。
可以这么说：我们的目标就是，***化高质量产品的输出。我们无论做什么事，都要以优化它为目标来做。敏捷、测试、监控，都是很重要的手段，但相比之 下，清晰的目标才是更加重要的。比如，什么叫做快？新版本发布多了就是快吗？引入新特性的频率高就是快吗？我觉得不是。新版本发布，可能会有很多bug； 新特性引入，可能是用户根本不关心的，可能你80%的用户从来都不会用到。所以这样的快是没有意义的。
我们对快的定义是，要让有效的产品尝试的速度尽量的快。你发一个新版本来测试，是否获得了更多对用户的理解？新功能是否让用户在某个场景下的需求得到更好的满足？用户是否更加活跃了？有效的快速是满足业务目标的速度，这是通过不断为用户提供更合适的功能来实现的。
我们现在发布重要的版本，会先在内部做高保真原型，在内部试用，从内部非常快的得到有效的反馈。然后我们会做很多的小范围用户测试和AB测试，比如 在不同的渠道分发不同的软件包，来验证新的交互、新的功能，改掉原有的问题。另外我们还有一个很简单的原则：我们客户端覆盖这么多的平台，但是一个新功能 的引入可能先只在一个平台上做，这样我们可以很快通过用户分析，了解用户是否需要这个功能，确认有用了才在全平台铺开。否则，就不引入其他平台，这样其他 平台可以有更多机会尝试其他的东西。
在这样的思路下，我们测试阶段的服务器端也可以做的很简单，比如我测试覆盖就几百几千人，那就先用Node.js搭一个服务给他们用就好了，性能问题可以以后再考虑。很多时候，做面向三五个专家用户（资深产品经理）的内测也已经足够了。
做软件开发不是做选择题，要么选A要么选B。只要目标明确，具体用什么手段都可以的。
InfoQ：你们后端研发团队和客户端研发团队在开发模式上的差异大么？
蒋炜航：本质上没有任何差别，大家都是为了业务的发展。实际上，我们有很多好的移动端研发工程师是从服务器端转 过去的。很多应届毕业生是没做过前端和移动端，他们一开始就是对服务器端感兴趣。我们就会让他先做服务器，其中一些人就会转岗到客户端去。基本上，优秀的 工程师在哪里都是优秀的，所以我们内部鼓励full stack工程师，可以从头到尾把高保真原型做出来，包括前端的JS、iOS、Android App、后台服务。我们所有的工程师都要有敏捷的思路，以及以用户为中心的认同感，这些方面是一致的。
当然，因为前后端软件的特性不同，肯定会有一些差异。比如，服务器端对性能更加敏感，所以会关注很多提高性能的手段。当然这些思路，客户端也可以引 入。另一方面，敏捷在客户端是比较常见的，因为客户端是功能驱动开发，对交付速度要求更高。当然，服务器端也要有一定的敏捷思路，不能说要我提供十个接 口，我就要做俩月。我完全可以用一周时间，用一些现成的技术，比如MySQL，把这个接口先提供出来，让客户端的开发能够用起来，之后再考虑性能问题，是 不是要移到并行文件系统上面去，等等。
总之，在规定的Sprint之内，我们一定要做出一个完整的版本。无论是客户端工程师还是服务器端工程师，他们的工作质量都是很容易判断的。
InfoQ：两个团队的交付周期是一样的吗？
蒋炜航：交付周期都是一样的，我们的节奏是一个月，也就是每个月都会有新版本出来，只不过有些不对外发布。
我负责这个业务，具体来说我并不关心客户端团队是不是在满负荷工作，或者服务器端团队是不是在满负荷工作，我关心的是我们在这个周期内，产品经理想要展现给用户的价值是否高质量的完成了，是否能给用户提供一个高质量的版本，这是最重要的。
InfoQ：两个团队的代码提交方式、代码review机制、测试机制是怎样的？
蒋炜航：我们内部用SVN提交代码，每个项目提交到各自的repo里面。代码审查是结对review的方式。
测试方面，主要由工程师自己写单元测试，交到自动化测试系统里去跑。我们有强制的测试覆盖率的要求。当然，服务器端和客户端跑的测试是不一样的，服务器端需要做更多的压力测试，而客户端在自动测试外还要做很多功能测试。
InfoQ：在监控和反馈机制方面，两个团队又分别是如何去做的？
蒋炜航：服务器端主要是服务器健康状态的监控。客户端有我们自己写的crash report机制，还有一套自己的BI系统，用于收集业务方面的指标。
整个产品的日志跟功能是一样重要的，一起开发、测试。有健康的日志系统，才能了解用户的使用情况。这套日志系统检测的指标有几百项，其中一些比较重 要的指标包括日活跃用户量、各个功能的使用率、用户满意度等等。其中用户满意度是关键指标，也就是NPS（net promoter score），我们所有的产品中都有这个分数，这个分数体现了用户对产品的喜爱度。
InfoQ：客户端团队相当于是底层团队的客户，这两个团队之间是如何进行沟通的？
蒋炜航：一个一个sprint来走。我们每个sprint先开客户端的会议，事先跟server端沟通好，要做 什么功能，可能有哪些接口，之后就是非常自主的形式了。比如客户端安排要做功能A，server端做接口A，那么这两边的人就会自己去沟通，讨论API该 如何设计，协议如何做。
敏捷小组的特性就是自发性，我们没有规定谁是谁的客户，或者谁lead谁。我们就是设定了目标，分配任务到每个组，之后任何人都能驱动。比如很常见 的，客户端说某个接口做的不对，会跟server端一起去改接口，不会说客户端不管API的设计，给什么用什么，大家肯定是一起来设计的。因为我们的工程 师是full stack，所以这点是比较自然的。
另外，我们的产品、测试、运营也都跟研发团队是坐在一起的，这几个团队之间的沟通都很多。我自己现在是60%在产品上，20%盯研发进度，20%在运营和市场上。
