知識星球點選上方“芋道原始碼”，選擇“置頂公眾號”
技術文章第一時間送達！
原始碼精品專欄
來源：https://kiwenlau.com/2018/07/19/technology-selection-is-not-critical
很多開發者非常熱衷於比較不同技術，比如：Angular是否比Vue.js更好？Node.js能否取代Java？究竟應該選擇MySQL還是MongoDB呢?
認真對比不同技術之間的優劣是非常有價值的事，可以加深我們對技術的理解，根據業務場景選擇更合適的技術。
但是，對技術選擇過於較真，爭得面紅耳赤，對於產品或者個人來講，都是沒有必要的。因為，技術選擇真的沒有那麼重要。
技術只是產品的實現手段
對於一個產品，技術僅僅只是實現手段。或者說，條條大路通羅馬，這個產品可以用Angular + Java + MySQL實現，那它用Vue.js + Node.js + MongoDB來實現也完全沒問題。不同技術在細節上確實有不少區別，但是它們在本質上它們是一樣的，Angular和Vue.js是前端框架，Java和Node.js是程式語言，MySQL和MongoDB是資料庫。
產品面向的是使用者，而不是開發者自己，在開發者開來，選擇某個技術棧也許很重要，但是對於使用者來說，很抱歉，他們完全不關心！使用者關心的是：是否有我想要的功能？UI設計是否合理？BUG有沒有及時修複？生活中，我們都是使用者，我們每天聊微信、刷抖音、逛京東、打王者榮耀，你會關心它們的後臺是用Java還是用Node.js嗎？
如果產品的技術棧還沒有確定，選擇一個目前使用者足夠多並且保持更新的技術就好了，用的人多的技術不會太差，還在更新則不用擔心BUG沒人修複。如果產品的技術棧已經確定了，那就更簡單了，直接擼程式碼啊；即使技術選擇有一些問題，抱怨是沒有用的，也沒人願意為了你的個人偏好去換技術棧，除非是產品需要。
作為開發者，應該利用自己已經掌握和需要學習的技術去實現一個好用的產品，滿足使用者的需求。如果產品沒有成功，有可能是產品的需求有問題，沒有市場；有可能市場很大，但是推廣得不夠成功；有可能推廣得不錯，但是商業樣式有問題，賺不到錢…當然，也有可能是技術問題，是技術不夠好，而不太可能是技術選擇錯了。
Fundebug的技術棧
當我們決定做Fundebug的時候，現在所使用的技術並不熟悉，而對於它們的同型別技術，我們更是一無所知。所以，這裡也不存在所謂的選擇的問題，我們使用了自己會用的技術：Angular + Node.js + MongoDB。它們使用者足夠多並且保持更新，符合我所說的標準。對於這樣的似乎有些輕率技術選擇，基本上沒有對我們產品開發造成什麼困惱，使用者需要的功能我們能夠儘量滿足。或者說，正真困惱我們的從來都不是技術選擇所造成的問題，而是產品設計、市場推廣、使用者溝通等問題。
我會負責一些後端開發，對於我們的技術棧，我熱愛Node.js，因為它語法簡潔，檔案清晰、有著簡單的非同步程式設計樣式和豐富的NPM生態系統；我也很喜歡MongoDB, 因為它的資料模型足夠靈活，然後檔案非常詳細，運維起來輕鬆很多。這裡沒有絲毫冒犯Java和MySQL的意思，因為我幾乎完全沒有接觸過它們，所以無法進行比較。我也相信，Java和MySQL也非常優秀，如果我們當初選擇它們應該也沒有什麼問題。
對於Fundebug的技術棧，我經常喜歡和人炫(chui)耀(niu)的一點是我們的所有應用包括MongoDB都是執行在Docker容器裡面，這極大的簡化了我們的運維工作。把應用打包到Docker映象裡面之後，我們只需要在叢集上安裝Docker，而不需要安裝任何應用，就可以在任意節點執行任意應用。我們可以根據需要(重新分配CPU和記憶體資源或者進行多副本擴容)隨時在任意節點之間移動應用。在叢集需要增加新的節點時，也只需要安裝Docker，這個新節點可以用來執行任何應用。我一直在思考Docker的價值，發現它確實很有用。所謂“如果你手裡有一把鎚子，所有東西看上去都像釘子”，我用了將近4年Docker，非常熟悉也非常喜歡，那我當然覺得Docker是個好東西。如果我們不使用Docker會怎樣？運維當然會比較痛苦，但是我們應該也沒有什麼大問題。大量公司還沒有Docker化，它們都活著好好的。
我對技術的迷思
和很多開發者，我也曾經迷信過一些技術，誰沒年輕過呢？
大三暑假學了一門叫做《大規模資料處理/雲端計算》的課，聽著很炫酷，其實主要是學習Hadoop，用Hadoop去實現PageRank等演演算法。PageRank是Google創始人提出的網頁排序演演算法，是Google搜尋引擎的基礎。Hadoop如此厲害，居然可以造Google，當時年少無知，覺得學會了Hadoop就夠了。事實上，知乎上也有類似的問題：Hadoop 就業前景如何？但是，現在呢？Hadoop的光環早已褪去，它只不過是對大規模資料進行批處理的常規工具，並沒有太大門檻。而Hadoop生態系統還有很多其他工具比如Spark, HBase等，僅僅使用Hadoop完全不足以應對各種複雜業務場景。
讀研的時候第一次接觸Docker，被深深吸引，因為Docker可以完美解決軟體安裝和配置的問題。大學畢業設計我曾花了至少1個星期時間配置一個4個物體機器組成的Hadoop叢集(當時不熟悉Linux)，而使用Docker的話，無需安裝，可以直接執行。我的開源專案hadoop-cluster-docker就是將Hadoop叢集執行到多個Docker容器中，這個專案已經累積了近千個Star，可見大家對於使用Docker簡化Hadoop安裝還是非常認可的。我接觸Docker的時間算是很早了，Docker最熱門的時候還收到過大公司的相關工作邀請，因此覺得熟悉Docker非常好，這次算是站在風口了。而現在呢？Docker已經逐漸普及化！因為Docker並沒有什麼高深之處，上手非常快。國內很多大公司，例如騰訊, 京東等早已Docker化。
無論是Hadoop和Docker，多少都算是改變世界的技術，也曾經大紅大紫，現在依然在發光發熱，但是早已不再自帶光環效應。這也是技術發展的客觀規律，新的技術不斷出現，它們解決了某些問題，受到熱捧，然後逐漸普及，被更新的技術所超越甚至取代。
事實上，我從來也沒有依靠Hadoop或者Docker去工作，它們也是靠不住的。技術發展如此之快，怎麼可能一招鮮吃遍天，現在熱門的技術遲早會冷卻，甚至會被淘汰。再說，技術是為工作服務的，而不是圍繞技術棧去圈定自己的工作內容；工作的時候，需要什麼技術就學習什麼技術，永遠獃在舒適區是一件很危險的事情。
參考
-
技術路線的選擇重要但不具有決定性
如果你對 Dubbo 感興趣，歡迎加入我的知識星球一起交流。
目前在知識星球（https://t.zsxq.com/2VbiaEu）更新瞭如下 Dubbo 原始碼解析如下：
01. 除錯環境搭建
02. 專案結構一覽
03. 配置 Configuration
04. 核心流程一覽
05. 拓展機制 SPI
06. 執行緒池
07. 服務暴露 Export
08. 服務取用 Refer
09. 註冊中心 Registry
10. 動態編譯 Compile
11. 動態代理 Proxy
12. 服務呼叫 Invoke
13. 呼叫特性
14. 過濾器 Filter
15. NIO 伺服器
16. P2P 伺服器
17. HTTP 伺服器
18. 序列化 Serialization
19. 叢集容錯 Cluster
20. 優雅停機
21. 日誌適配
22. 狀態檢查
23. 監控中心 Monitor
24. 管理中心 Admin
25. 運維命令 QOS
26. 鏈路追蹤 Tracing
…
一共 60 篇++
原始碼不易↓↓↓↓↓
點贊支援老艿艿↓↓
