探索全栈工程师团队的开发协作模式

他是2013年QCon北京云计算专题的出品人,也是2014年QCon北京移动应用专题的出品人。他的团队往下做到云计算基础架构,往上做到客户端。他本人从80年代末起接触编程,在大数据处理、云计算、以及分布式系统等方面都玩过一圈。他是蒋炜航,网易技术总监,目前全面负责有道云笔记业务。

\u0026#xD;\n

在这样一个团队中,后端和前端团队在同一个产品上工作,有紧密的协作关系。但是,底层的软件研发和应用层的软件研发毕竟有很大的区别,他们在代码提交和管理模式、测试机制、代码的交付周期、反馈和监控体系方面都有怎样的异同?在本次采访中,蒋炜航博士会介绍有道云笔记团队的一些实践。

\u0026#xD;\n

InfoQ:您在去年QCon北京出品云计算专题,今年则出品移动App的专题。这也对应了有道云笔记在技术上的一个特点,就是从底层到客户端都是你们自己来研发、维护、运营的。能先简单介绍一下跟有道云笔记相关的技术团队都有哪些,各自负责哪些方面吗?

\u0026#xD;\n
\u0026#xD;\n

蒋炜航:我们底层有基础架构组,这个组在云笔记业务之前就建立了,服务的对象不单单是云笔记,还服务有道的很多业务。这个组也在我的团队,做的东西跟Hadoop(HDFS、HBase、MapReduce)这些差不多,是自己研发的一套系统。底层提供的东西比较基础,只是存储和计算服务,对所有业务通用,本身不包含业务逻辑。

\u0026#xD;\n

业务逻辑的开发都在服务器端的团队,这个团队专门是负责云笔记的服务器端的,负责处理同步、多版本、提供API等服务。

\u0026#xD;\n

客户端包括PC、Mac、iOS、Android、Windows Phone的客户端,以及web端和浏览器插件。基本上每一层的团队都是几个人来做,不是很多。

\u0026#xD;\n

此外我们还有个精干的研究团队,这个部门做的是一些三到六个月才有成绩的东西。方向主要是应用研究,研究的目标不是发论文,而是把成熟的技术做到产品中。比如编辑器,我们需要做跨平台的编辑器,过去大家比较熟悉的就是Office和Google Doc,而以前很多Web based的编辑器并不适合跨平台终端的需求。我们一开始也是用Web编辑器做起来的,但是并不是很适合。我们也不可能像Office那样用几百个人去做一个编辑器出来,所以研究部门做的事情就是,花一定的时间找到合适的方法来提升编辑器的体验。提高跨平台的体验是一个很模糊的目标,不确定性很大,具体用什么做法要很多研究和尝试。这个团队还研究一些NLP和手写输入方面的项目。

\u0026#xD;\n
\u0026#xD;\n

InfoQ:有些软件产品的发展思路是求快,尤其在产品推出初期,要以最快的速度推出新的特性以验证产品的可行性;有些软件产品的思路是求稳,尤其在产品积累了一定用户量的时候,会更加关注软件的稳定性、安全性,升级的时候不要对现有用户造成负面影响。有道云笔记现在处于怎样的阶段,是偏重求快还是求稳?

\u0026#xD;\n
\u0026#xD;\n

蒋炜航:做互联网产品永远是要快的。同时,云笔记是个人的信息、知识管理工具,稳定性非常重要。要快,同时也要坚守产品质量,我们必须要两者兼顾。

\u0026#xD;\n

可以这么说:我们的目标就是,最大化高质量产品的输出。我们无论做什么事,都要以优化它为目标来做。敏捷、测试、监控,都是很重要的手段,但相比之下,清晰的目标才是更加重要的。比如,什么叫做快?新版本发布多了就是快吗?引入新特性的频率高就是快吗?我觉得不是。新版本发布,可能会有很多bug;新特性引入,可能是用户根本不关心的,可能你80%的用户从来都不会用到。所以这样的快是没有意义的。

\u0026#xD;\n

我们对快的定义是,要让有效的产品尝试的速度尽量的快。你发一个新版本来测试,是否获得了更多对用户的理解?新功能是否让用户在某个场景下的需求得到更好的满足?用户是否更加活跃了?有效的快速是满足业务目标的速度,这是通过不断为用户提供更合适的功能来实现的。

\u0026#xD;\n

我们现在发布重要的版本,会先在内部做高保真原型,在内部试用,从内部非常快的得到有效的反馈。然后我们会做很多的小范围用户测试和AB测试,比如在不同的渠道分发不同的软件包,来验证新的交互、新的功能,改掉原有的问题。另外我们还有一个很简单的原则:我们客户端覆盖这么多的平台,但是一个新功能的引入可能先只在一个平台上做,这样我们可以很快通过用户分析,了解用户是否需要这个功能,确认有用了才在全平台铺开。否则,就不引入其他平台,这样其他平台可以有更多机会尝试其他的东西。

\u0026#xD;\n

在这样的思路下,我们测试阶段的服务器端也可以做的很简单,比如我测试覆盖就几百几千人,那就先用Node.js搭一个服务给他们用就好了,性能问题可以以后再考虑。很多时候,做面向三五个专家用户(资深产品经理)的内测也已经足够了。

\u0026#xD;\n

做软件开发不是做选择题,要么选A要么选B。只要目标明确,具体用什么手段都可以的。

\u0026#xD;\n
\u0026#xD;\n

InfoQ:你们后端研发团队和客户端研发团队在开发模式上的差异大么?

\u0026#xD;\n
\u0026#xD;\n

蒋炜航:本质上没有任何差别,大家都是为了业务的发展。实际上,我们有很多好的移动端研发工程师是从服务器端转过去的。很多应届毕业生是没做过前端和移动端,他们一开始就是对服务器端感兴趣。我们就会让他先做服务器,其中一些人就会转岗到客户端去。基本上,优秀的工程师在哪里都是优秀的,所以我们内部鼓励full stack工程师,可以从头到尾把高保真原型做出来,包括前端的JS、iOS、Android App、后台服务。我们所有的工程师都要有敏捷的思路,以及以用户为中心的认同感,这些方面是一致的。

\u0026#xD;\n

当然,因为前后端软件的特性不同,肯定会有一些差异。比如,服务器端对性能更加敏感,所以会关注很多提高性能的手段。当然这些思路,客户端也可以引入。另一方面,敏捷在客户端是比较常见的,因为客户端是功能驱动开发,对交付速度要求更高。当然,服务器端也要有一定的敏捷思路,不能说要我提供十个接口,我就要做俩月。我完全可以用一周时间,用一些现成的技术,比如MySQL,把这个接口先提供出来,让客户端的开发能够用起来,之后再考虑性能问题,是不是要移到并行文件系统上面去,等等。

\u0026#xD;\n

总之,在规定的Sprint之内,我们一定要做出一个完整的版本。无论是客户端工程师还是服务器端工程师,他们的工作质量都是很容易判断的。

\u0026#xD;\n
\u0026#xD;\n

InfoQ:两个团队的交付周期是一样的吗?

\u0026#xD;\n
\u0026#xD;\n

蒋炜航:交付周期都是一样的,我们的节奏是一个月,也就是每个月都会有新版本出来,只不过有些不对外发布。

\u0026#xD;\n

我负责这个业务,具体来说我并不关心客户端团队是不是在满负荷工作,或者服务器端团队是不是在满负荷工作,我关心的是我们在这个周期内,产品经理想要展现给用户的价值是否高质量的完成了,是否能给用户提供一个高质量的版本,这是最重要的。

\u0026#xD;\n
\u0026#xD;\n

InfoQ:两个团队的代码提交方式、代码review机制、测试机制是怎样的?

\u0026#xD;\n
\u0026#xD;\n

蒋炜航:我们内部用SVN提交代码,每个项目提交到各自的repo里面。代码审查是结对review的方式。

\u0026#xD;\n

测试方面,主要由工程师自己写单元测试,交到自动化测试系统里去跑。我们有强制的测试覆盖率的要求。当然,服务器端和客户端跑的测试是不一样的,服务器端需要做更多的压力测试,而客户端在自动测试外还要做很多功能测试。

\u0026#xD;\n
\u0026#xD;\n

InfoQ:在监控和反馈机制方面,两个团队又分别是如何去做的?

\u0026#xD;\n
\u0026#xD;\n

蒋炜航:服务器端主要是服务器健康状态的监控。客户端有我们自己写的crash report机制,还有一套自己的BI系统,用于收集业务方面的指标。

\u0026#xD;\n

整个产品的日志跟功能是一样重要的,一起开发、测试。有健康的日志系统,才能了解用户的使用情况。这套日志系统检测的指标有几百项,其中一些比较重要的指标包括日活跃用户量、各个功能的使用率、用户满意度等等。其中用户满意度是关键指标,也就是NPS(net promoter score),我们所有的产品中都有这个分数,这个分数体现了用户对产品的喜爱度。

\u0026#xD;\n
\u0026#xD;\n

InfoQ:客户端团队相当于是底层团队的客户,这两个团队之间是如何进行沟通的?

\u0026#xD;\n
\u0026#xD;\n

蒋炜航:一个一个sprint来走。我们每个sprint先开客户端的会议,事先跟server端沟通好,要做什么功能,可能有哪些接口,之后就是非常自主的形式了。比如客户端安排要做功能A,server端做接口A,那么这两边的人就会自己去沟通,讨论API该如何设计,协议如何做。

\u0026#xD;\n

敏捷小组的特性就是自发性,我们没有规定谁是谁的客户,或者谁lead谁。我们就是设定了目标,分配任务到每个组,之后任何人都能驱动。比如很常见的,客户端说某个接口做的不对,会跟server端一起去改接口,不会说客户端不管API的设计,给什么用什么,大家肯定是一起来设计的。因为我们的工程师是full stack,所以这点是比较自然的。

\u0026#xD;\n

另外,我们的产品、测试、运营也都跟研发团队是坐在一起的,这几个团队之间的沟通都很多。我自己现在是60%在产品上,20%盯研发进度,20%在运营和市场上。

\u0026#xD;\n

你可能感兴趣的:(探索全栈工程师团队的开发协作模式)