对创业公司技术选择的一些思考

在过去四年多的时间里我有四分之三的时间都是呆在创业公司，其中有一年的时间在ThoughtWorks度过。中途有一次机会进入大公司，但是考虑再三还是放弃了。转而加入了一个创业公司。就这几年在创业公司做技术的经历，来谈一下创业公司的技术选择。

我第一个加入的创业公司是一个非常小的团队，人数最多的时候也就二十多个人（公司总人数）。后端团队从两个人发展到后来的六个人，已经是初具规模的团队了。公司主要做过三个大的项目：1. 新浪微博爬虫，2. 基于Web的社交网站，3. 即时通讯工具。

新浪微博爬虫是用Java实现的，关于这个项目有一段历史。一开始这个项目是用PHP+MySQL写的，参与项目的一共是三个人。但是写着写着，就发现越来越搞不动了。不仅性能上不行，而且代码量大了开发效率也不行了。三个人也都比较头疼。项目也进入了一种比较尴尬的局面。好在这时招进来一个大牛。关于这个大牛后边详细介绍。这个大牛进来之后，把原有的技术替换为Java+MongoDB。最后项目不仅效率上有很大的提升，而且原来三个人做的事情，现在剩下这位大牛自己搞，最终凭借一己之力完成了这个项目。

我们来分析一下这次技术栈的变更。从结果上看肯定是成功的（我们排除人的技术水品的因素，单纯分析技术）。原来三个人做的事情，现在一个人接管；项目顺利交付，并且性能也有大幅提升。

Java和PHP哪个更好？就这个使用场景来说肯定是Java更合适。因为需要大量调用微博API，我们可以利用Java的线程技术实现并发和异步编程。
MongoDB从始至今都是整体比较多的技术。一方面大家痴迷于它的性能，以及易用性，另一方面大家又被它的不稳定性所困扰。好多公司都在MongoDB上载过跟头。而且Mobgodb也对内存也是非常贪婪的。但是在我们的项目中用mobgodb给我们带来的好处也远大于它的弊端。项目整体性能的提升一部分原因要得益于MongoDB。所以说这次项目选型是很成功的。

Web项目我们用的技术是：Java + Nutz + MongoDB。
几年之前那可是SSH的天下，而且Nutz框架我在进入这家公司之前根本没有听说过。但是使用了之后，立马被它的易用性和简洁性吸引。首先学习成本很小，SSH这套框架不说别的，光是配置也够你学几天了，而Nutz几乎是零成本的，而且注解设计的也非常容易理解。还有相信大家也被SSH各种依赖搞疯过吧，而Nutz引入一个jar就可以了。一个jar包就包含了MVC，IOC，AOP等这些功能，不必强制依赖第三方jar，绝对是一个小而美的框架。

仍然是MongoDB。对于创业公司来说选择MongoDB绝对是一个非常明智的选择。首先你真的不用可以的关系性能问题；其次入门非常简，学习曲线较低；再者如果你的业务真的井喷了，那么MongoDB也能够通过分布式的架构来handle。还有最重要的一点是弱Schema，你不用操心Model改变数据库升级的事儿了，并且版本升级并不是一件简单的事情。

我们用这套架构做了很多Web项目，效率高，体验好。这一套技术无疑也是一次成功的选择。

再接下来我们开始做一个IM聊天工具。在这个项目上我们引入了Scala和Akka。在项目只有一个人（就是前边提到的大牛）了解这套技术这套技术的前提下，引入这套全新的技术其实风险还是比较大的。但是这套技术其实是非常适合我们的业务的。最终项目还是如期的完成了，但是过程中也有被技术折腾的欲哭无泪的时候，不过有这个大牛作坚实的后盾，好多技术难题都伴随这他一个个通宵搞定了。

个人感觉，这次技术选型对一个创业公司来说有些激进了。

那我们现在回顾一下，这个公司在技术选择一直是比较合理，没有犯过错误的。虽然最后选择的技术过于新潮，但是无疑这套技术是非常适合当时业务的。终于该说一下我们公司技术负责人，他从小开始编程，在未成年时就混进了外包公司（因为只有外包公司敢要未成年人），到后来成了华为最年轻的架构师。他非常聪明也非常努力经常是连着熬几个夜项目就出来了。而且他的技术品味也非常高。像SSH这个又笨又傻东西是他怎么会选呢。相比之下Nutz这种小而美的框架对他来说才是非常性感的。Akka，Scala虽然我认为是一个激进的选择，但是对于他来说肯定是在可控范围内，因为好多难题经过他一夜补眠就搞定了。

对于这个公司的技术选择：1. 小而美，不随大流。2. 激进但可控。选择一些非主流的技术（比如Akka，Scala，在2012年国内市面上很少有这两项经验的人），毕竟会导致项目后续招人上的困难，但是有一个最基本的保障是，技术负责人技术足够扎实，在这关键时刻以一敌三，同时引进新的技术后也在不遗余力的培养团队成员。

第二家创业公司使用的也是Scala技术栈：Play Framework + Reactive Mongo + MongoDB，也算是一套比较新潮的技术。当然也是这些技术吸引我进入这家公司。进入一家公司之前你总是会抱着一些美好的期望，这种期望往往会在你第一时间看到项目代码时随之破灭。Scala是一门很powerful的语言，当然当你用的不体面是，它只能比Java更具有破坏力。入职的前两天当我看完了需求文档，尝试梳理代码逻辑的时候，那时我恐怕遇到了前半生最困难的一件事情。逻辑遍布在各个地方，而且每段逻辑都没有严格的边界划分。就像在一堆打散的积木中，试图找到一个汽车的模型。

在这家公司Scala这套技术栈不仅没有起到提升效率，快速开发的作用，反而成了团队的拖油瓶，绊脚石。因为此时技术已经像一匹脱缰了的野马，不仅不会再听从你的训令，反而会拖着你瞎跑。所以当我熟悉了业务和项目基本信息后，就着手开始了项目重构，当然这也是技术负责人最希望作的一件事情。

对于这家公司的技术选择：盲目激进，不自量力。这家公司的技术负责人是一位Android工程师，对后端开发经验不足。首先自己涉足的是一块没有接触过的领域，用大流技术才是最稳妥的做法。而且具备Android经验，选择Java技术栈至少没有新语言学习成本（当然选择了Java也不肯定比现状好，只是少了一项技术难题）。再者招人容易，像Java，PHP什么的程序员遍地抓（但是大流意味着水平参差不齐，创业公司还是先解决有和没有的问题吧）。如果有幸招到一位不错的程序员，也可以弥补自己后端经验缺乏的短板。但Scala就不是这样了，除非自己有熟人或者熟人能介绍，否则招到的几率很小很小。大多数使用Scala的公司其实都是有自己培养成员的打算的。但显然对于这家公司来说自己培养是不现实的。

第三家公司也就是我现在的公司，是做海外电商的。在这里技术用到的技术也是多种多样：Python，Ruby，Java。每个公司的技术背后都隐藏着很多故事。这里的故事避开不讲了，只说一下结果：后端服务一开始时是由一个技术非常不错的人用Python来写的，他是一个Pythoner。后来由几个Java背景的工程师接管。Java程序员深受着分层架构的毒害，以至于在项目里也搞起了Dao，Service这些东西。原本很清爽的代码被搞得非常臃肿。而且既然分层了，也没有把每层的逻辑隔离好，各层的职责相互渗透。同事们也是抱怨连天。

再有就是Ruby，我刚进来就被分到了这个Ruby项目上。刚看代码的第一天我就隐约感觉到这是一个Java程序员写的代码。最明显的标识就是：变量搭配逻辑控制和循环使用，超大方法。虽然项目实现的不好，但是由于业务逻辑简单，还没有到那种不可收拾的地步。

由于深深受到动态语言的打击，在做新的系统的时候，团队又用回Java。这个项目我是从头到尾一直负责的。现在在这个项目上用到的技术有：Spring Boot，JOOQ，Flyway，MySQL。之前数据访问用的是MyBatis，后来被替换为JOOQ。MyBatis算是一个相对轻量的框架，但是还是感觉还是模板代码，有点死板。用JOOQ可以很好的解决这个问题，你不用再专门的搞一个mapper，让数据库操作更直接。这个项目作了还不到半年的时间，到目前为止，至少从开发体验上来说还是很不错的。

对于这件公司的技术选择：探索中前进。刚刚开始团队尝试了一些动态语言Python，Ruby。随着项目的不断发展，代码的可维护性和性能等问题日渐严重。时是团队又选择了大多数人都比较熟悉的Java。这对团队来说是一次成长的过程，都说动态语言好，适合创业公司作快速迭代开发，但是自己的团队基因不合适，那选择一个大家都熟悉的语言才是性价比最高的。并且现在的Java也不像原来那样笨拙了，开发效率比Ruby，Python也差不了多少。

总结一下，一个创业公司应该怎样选择自己的技术呢？下边分几个阶段来说一下。
创业之初，这个阶段公司作技术的可能就一两个人，这时公司迫在眉睫的是开发出第一个产品原型。这个阶段一定要用自己选择最擅长的技术，快速的把产品原型开发出来。Ruby也好，Java也罢，先把有没有的问题解决。要知道这会儿少一次查文档的时间就少几分钟加班的时间。

起步阶段，这个阶段是公司业务的快速发展阶段。这个阶段开发的任务通常要比第一个阶段还要重，不过公司在这个时候已经拿到一笔钱了，可以快速的扩建开发团队。这个阶段的技术选择：对于核心业务的选择也倾向于使用主流的技术。一方面是这些技术足够成熟稳定，另一方面招人相对容易。对于一些非核心的业务可以尝试一些新的技术，为后续做一些经验储备。

再后来的阶段我还没有经历，等有机会再作补充吧。