团队、创新及优化

本文系 Coding CTO 孙宇聪接受 InfoQ 采访内容整理稿。

Q ：首先请您先自我介绍一下。

A ：我叫孙宇聪, 07 年毕业之后加入了 Google 中国，在 Google 中国做了一年半，又调动到 Google 美国做了 7 年 SRE ，然后今年年初回来创业。 目前在 Coding 担任 CTO 。我在 Google 的主要工作是 SRE ，但是同时非常关注如何提高程序员的生产力。 Coding 的一大重点就是极为关注开发者这个群体，关注如何提升他们的生产力，做更好的工具，更好的社区，来帮助开发者成长。我们最近还推出了 Coding 码市，让开发者用自己的知识和技能赚取真金白银。

Q ： SRE 在前面的采访里也聊了不少，今天的采访想更多的聚焦在 Coding 开发团队内部变革上。目前『码市』这个团队的主要情况是什么样的？

A ：目前，码市和 Coding 主站最开始在公司内部是两条不同的产品线，分别有各自的团队。

国内一般的创业公司、也包括大公司，新产品上线都是靠组建一支『敢死队』。做一个新事情需要一个新团队，『码市』这支敢死队与众不同的是，我们完全没有招新的员工，全部是从 Coding 工具团队里选出来的老员工组建而成。事实证明这样的选择是非常好的，把之前团队里的成熟经验和工具都带到新的业务上去了，加速了起步，也避免了许多问题。

但是对许多公司来说，新项目的团队一般会采用很多不同的技术，产生很多新的想法，逐渐和老团队越走越远，越来越难以融合，这在未来就可能会存在很大的问题。举个例子来说吧，在编译系统的选用上， java 的话，可能是 Maven 或者 Gradle ，以及一些第三方的系统，虽然在功能上不会有太大区别，但是在不同编译系统里得到的经验和最佳实践并不能有很好的相互迁移。老的系统不肯改变，新的系统又无法融合回旧的体系，陷入了一个死循环。

我在 Google 最大的体会是： Google 整个公司只有一套开发环境和研发体系。每个工程师虽然做的是不同的业务，但是强制所有人都使用同一套研发体系。这套研发体系长远看来极大的促进了公司整体业务的研发效率提升，利远大与弊。

码市团队初期也遇到了类似的问题，团队采用了新的 Java 编译系统可能就不一样，新的 JavaScript 的编译体系，虽然每一个改动都很小， 合并起来就是天壤之别。

如果一个创业公司做不到统一开发环境和研发体系，那么势必会造成我们研发力量的分散。这就是为什么有些公司事儿特别少但人特别多，因为每个人所作的事情都不通用。虽然你可能说我们公司用的都是 Java ，但是这里面的细节和问题太多了。

作为 CTO ，我的一大目标就是把要把这些问题扼杀于萌芽之中（笑）。

Q ：的确是创业团队里的开发者更喜欢尝试新的东西。

A ：完全禁止创新也是不可能的。因为作为一个公司、团队必须要尝试新鲜的东西，不然难以进步。如果一个团队老用旧的东西那他就领会不到外界的好处。比如我们在码市项目试行过之后，逐渐将全部 Coding 项目从 maven 切换到了 Gradle ，因为真的很好用。

我这里要说的关键是，作为一个创业团队，我们必须需要定时把各个业务组聚在一起，共同评论一下 Gradle 什么样， Maven 什么样， 我们整体应该往什么方向发展。 举一个例子，这就和像园丁打理花园一样，你可以让花随便长，但到了一定时间一定要把长得不好的砍掉，选出其中一种，或者是有限的几种一定要留住的。最终的决定其实并不重要，重要的是要有这样一个决策的过程，以及强有力的执行。

初创团队人员的调动是非常频繁的，一个人的兴趣点会转变，公司计划也会改变。你做的项目几个星期之后就可能由别人来维护。 我们在公司强调所有人写的代码都是公司的共同财产， 每个人都有义务共同维护这些代码。

作为 CTO 来说，我的工作就是抵住 CEO 的压力。每周我们要安排一些产品上的事情，我们也要留出一段时间来做架构上的整理，改进，统一。我需要给程序员们留出时间，创造条件来做这些长远的事情。 只要把程序员聚到一起，他们自然而然就会产生出很好的想法来，然后再把这些好的想法推广出去。

我们需要做到的有一下几点。

第一， 我们一定要统一，不能『浅尝辄止』，半途而废。

现在的很多技术、工具，基本上是『万能的』，只有好不好用的区别，没有能不能的区别。 所以当我们发现了一个好用的工具，就必须要把他用好。而且是在全部项目上用好。

第二，创业公司要有计划的投入力量，推动技术革新。

新工具、新架构改进雏形有了之后，我们必须要留出一段时间来让老项目和新项目一起去推进，把改革真正贯彻到底。一个团队只有真正能做到不断学习新东西，然后能将他们完全应用到自己的老系统上去，这才是一个健康的体系和研发环境。

如果做不到这一点，随着产品线越来越多，你的工具越来越多，研发体系的复杂性越来越高，资源就难以流动，公司会遇到很大问题。 Coding 内部在推行同一套编译系统，同一套代码的组织方式，还有一些最佳实践，比如说好用的静态分析工具。 让大家随时都处于同一个环境里面，使用同一套语系交流。同时， Coding 经常组织团队之间的成员流动与相互分享，进一步鼓励沟通。

只有一个研发体系能够做到这种程度，建立良好的沟通体系，才能够让大家劲往一处使。研发部门是一个技术公司的发动机。发动机必须要所有零件合力去推动整个发动机的运转，而不是单独的小零件自己运转。

Q ：之前您也提到说， Google 在工具流程统一方面做的很好，但是这也是经历了一个过程，在最初的时候早期的工作还是很有挑战性的。

A ：一个技术公司哪怕是 Google 、 Twitter 、 Facebook ，也无法确定的知道哪个工具是最好的、最合适的。 首先公司不能限制住大家的创新，要让工程师随便去试，去做微创新。但是同时公司内需要有一股核心力量，不关心具体业务，只关心怎么吸收大家的微创新，使之成为可以实现的目标，推广到所有的项目里去。程序员不能全是写业务的，应该留出一些力量做架构的，有一些是做基础开发的。哪怕只有一个人也比零要强很多。

Q ：你觉得现在以 Coding 现在的规模，专门设置一个人专门给内部开发工具服务的，是不是太早了点?

A ：小公司内的确很难， 现在 Coding 内部也做了一个百分之二十计划，就是一周里留出一天的时间是给程序员用来思考『如何把现在的东西做好』。创新是一个急不得的过程，平时公司里也会有很多新想法、新吐槽， 缺少的是能把想法和吐槽转化成真正目标和力量的人。那我们至少可以做到定期把大家聚起来，每个人出一点时间，一起讨论出一个方案。

作为 CTO 和管理层，需要做的就是关键时刻推一把，找到一个合适的人在合适的时间去去推进架构的进步。

还回到花园的比喻上，公司是一个花园，园丁只能除草和施肥，在合适的地方施加压力，在合适的地方 say no ，这样才能把花园搞得很好，你对花的生长是无法控制的。管理技术团队也是一样的道理，把大家聚在一起，给他们创造条件，让他们往一个方向努力，这样才会成功。

Q ：那您现在考虑比较多的事情或者问题分享一下？

A ：给工程师创造更好的环境，真正提高工程师的生产力，这也是我们关注的一个目标。比如我们上海的工具团队做了很多提高程序员生产力的工具，哪些是我们真正能用到我们自己身上的。

比如我们现在搞了一个网页上看代码的 Code Insight 的产品。像 IDE 一样可以在网页上看到所有的变量之间的关系，操作的流程，代码的流程，还支持非常好用的搜索。

我们所有创新工具都首先在要在公司内部推推行。其他的还包括代码评审工具， 我们自己每天都在用。 Coding 所有的开发管理，所有代码全都放在 Coding 平台上，这样我们才能先于用户知道哪个地方有问题，那个地方要优化。这个我觉得还是比较好的点。