技術選型：效率至上與實用至上

　　當我們面對一個架構方面的決策時，通常會處於某種兩難的境地，選A還是選B，”市面上”同時存在各種豐富多彩的說法，單獨看去，往往各自言之成理，如果仔細對比，又往往莫衷一是。

 

　　在我目前所就職的公司，前段時間我剛剛做了一個架構決策：原來的系統，開發人員採用PHP編寫後臺執行的程式指令碼，處理各種需要高效能的業務；另外，他們又用CoffeeScript編寫了一個Web控制檯，以配置、管理和監控這個系統。這令我感覺相當的怪異，因此我決定，後臺關鍵程式，重新用nodejs編寫，而Web控制檯，則重新用PHP編寫。

　　這個決策背後的邏輯是：一個複雜的系統，越來越多的是由多語言混合編寫而成的，而在實際的系統中，所謂的架構決策，就是在不同的部分，選擇不同卻適合的語言和技術。

　　這個結論，我一直相當心安理得。直到上週，我去參加了ThinkInLAMP組織的PHP2013開發者大會。在會上，我聽到了來自臺灣的樑楓先生的一場演講《在WEB之外——PHP》，在演講中，他反覆在問一個問題：PHP真的只能寫Web嗎？而他的開發實踐相當的有趣，他在用PHP編寫工業自動化控制方面的應用，編寫串列埠通訊的程式碼，同樣的功能，用PHP編寫的時間是2周，而用C語言編寫的時間是8個月，而且PHP的2周，是他一個人完成的。這樣的演講，令人印象非常深刻，也引發了我更多的思考。

　　會後，我找到了樑先生，提出了我的疑問，舉的就是我在公司裡，顛倒兩種語言的架構決策。蔡先生的回答是：對啊，當初我只用了2周，但是後來我們還是又花了8個月呀。PHP，主要可以快速的拿出原型，真正的產品，還要C語言去開發一遍的呀。

　　經過這番討論，我得到了一個新的富有啟發的結論：在快速原型的階段，就可以選擇快速開發的語言，而在實用的階段，就應該選擇更加實用的語言。

　　這麼膚淺的結論，真的值得大肆宣揚，再寫一篇Blog嗎？自然不是，因為我在後來的一週裡，一直在腦子裡反覆思考這個問題，然後，突然想明白了一些：

　　在一些極端的領域，效率至上與實用至上，可以毫不相干，各自有所追求，前期追求效率的開發產品，由於成本極低，大多是可以隨時拋棄的。而真正的困難在於想要兼得。常見的與架構相關的兩種痛苦：一種是，剛開始為了追求快速開發，在技術選型上怎麼快怎麼來，結果系統越來越大，越來越複雜，等到想要考慮架構優化，想要重構的時候，卻已經積重難返，改起架構來傷筋動骨。另一種是一開始想得太多，架構做得太複雜，殺雞用牛刀的技術用得太多，往往還沒有等到系統開發完成，就已經Game Over了。

　　還有一個現象，也很常見，我們常常能夠見到各種技術方面的爭論，各執一詞的原因，往往是由於各自的立場不同：你說某某語言效率極高，他說等到複雜了這個語言就撐不住了。一些常常被人引用的例子是：某某知名網站，放棄了PHP技術、放棄了.NET技術，放棄了Ruby技術等等，對立陣營的同學們，就感到歡欣鼓舞：看吧，就知道你們那個語言，只能拿來開發玩具應用…

　　長長的引言部分結束，開始系統性的闡述我的觀點：

　　1. 選擇技術，往往不是選擇某種單一的技術，而是選擇一個技術棧；

　　2. 有些技術一開始的出發點就是追求開發效率，然後在後續的發展中，逐步開始追求實用；

　　3. 有些技術一開始的出發點就是追求實用性，然後在後續的發展中，逐步開始追求開發效率；　

　　4. 想要兼得魚和熊掌，的確困難，但是並非沒有可能，我們可以找到一些優秀的、可選的技術集合(兜售私貨的伏筆)；

　　5. 對於技術選型的判斷，需要考慮理論情況與實際情況；

　　效率考慮

　　技術複雜度（複用性）：學習並掌握一組技術棧，需要了解多複雜的技術；相應的，當我們掌握了這門技術，他可以在多少地方複用？

　　技術友好度（優雅性）：在開發的過程中，會不會有各種莫名其妙的陷阱，會不會讓我糾纏於各種莫名其妙的細節？

　　實用考慮

　　業務複雜度（組織性）：隨著業務的複雜，我們的程式碼會不會最終無法駕馭？無法維護？無人能懂？

　　效能提升度（潛力）：隨著業務的增長，壓力的提升，我們會不會最終被迫放棄現有的技術架構，重頭開始？

　　也許，我們可以憑藉這四個維度，做一個雷達圖，以便更加準確的評價候選的技術，這裡就先靠文字描述粗略的表達一下吧。

　　LAMP，當然是最為知名也最為成熟的技術棧，隨著技術的發展，Nginix、Memcached、Redis、LVS等等技術，也非常自然的加入到這個體系之中，常常有人宣稱：LAMP是全能的，而我在大多數時候，也相當同意這一點。如果將LAMP拆開來看，除了PHP，其他的幾項技術，並非LAMP獨有，如果我們單獨來看PHP的話，他在開發效率方面相當優秀，但是略弱於Ruby&Rails；在實用方面，卻略勝於Ruby&Rails，因此：PHP始終是一個不算壞的選擇。

　　Ruby&Rails，是一個較新的技術棧（當然，我們可以說它僅僅替換了LAMP中的P），但是，Rails在快速開發領域的貢獻是劃時代的，具有開風氣之先的意義。現在的Rails，也開始越來越大，越來越複雜，逐步的開始追求實用，這也造成了另一個有趣的現象：Ruby whitout Rails的興起。甚至可以認為：Ruby社群一個非常顯著的特點，就是強烈的追求開發效率，不太強烈的追求實用性。

　　nodejs，是目前最新的一個技術棧，他最大的一個優勢，就是前後端只需要一種程式語言，使得原本就熟悉JavaScript的程式設計師，爆發了極大的向後端進軍的熱情。而另一方面，由於nodejs的非同步響應的高效特性，使得其在實用性方面，有相當寬廣的未來。但是，現在的nodejs，對於業務複雜度的支援，還遠遠不夠。

　　Java是一門老牌的語言，說實話，我已經早就背叛了這個陣營，原因很簡單，Java僅僅在組織複雜業務程式碼的能力上，有不小的優勢；但是：這是以一開始就引入的架構複雜度為代價的。Java社群的眾多框架，似乎也忘記了對開發效率的追求，一門心思為了展現更多的設計模式…(純吐槽，請無視)

　　HTML5，也是相當火爆的熱門領域，很大的一個原因，就在於：HTML5的知識，可以複用於Browser、Mobile、Tablet等原本差異極大的多個領域，因此在開發效率上，對程式設計師產生了極大的誘惑。只是在實用性方面，目前還有一些疑問。經常聽人提到的HTML5&Native混合程式設計，我的直覺是：這樣只會造成更多複雜的問題需要解決。

　　Golang、Erlang，本身就是根植於實用性（尤其是效能）追求的技術，在開發效率方面弱於其他技術，原本就是合理和正常的，對於某些預期肯定會非常複雜的系統，一開始就選擇這樣的技術，可以說是相當正確的選擇。

　　Redis是一個好的技術，無論是自己一個人做個玩具小應用，還是在關鍵領域，承擔核心效能元件。REST是一個好技術，無論是開發一個DEMO，還是用於整個SOA架構的核心，都非常合適。這樣的技術，的確不多。

　　最後需要表達的一個觀點是：以上這些點評，僅僅出於我對這些技術的瞭解（你看，我根本不懂Python/C#，所以也不敢點評什麼）。 對我而言，在目前的階段，nodejs是一個非常值得加大投入，深入學習的技術棧（私貨在此）。

　　希望這篇文章，不致令各位朋友失望…