對創業公司技術選擇的一些思考

在過去四年多的時間裏我有四分之三的時間都是呆在創業公司，其中有一年的時間在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也罷，先把有沒有的問題解決。要知道這會兒少一次查文檔的時間就少幾分鐘加班的時間。

起步階段，這個階段是公司業務的快速發展階段。這個階段開發的任務一般要比第一個階段還要重，不過公司在這個時候已經拿到一筆錢了，能夠快速的擴建開發團隊。這個階段的技術選擇：對於核心業務的選擇也傾向於使用主流的技術。一方面是這些技術足夠成熟穩定，另外一方面招人相對容易。對於一些非核心的業務能夠嘗試一些新的技術，爲後續作一些經驗儲備。

再後來的階段我尚未經歷，等有機會再做補充吧。