問題描述
如何選擇新的技術棧
幾乎所有團隊都經歷過技術選型問題，不管是大層面的基礎設施選型，還是小到第三方服務的使用，開源項目百花齊放的今天，相同問題往往不止一種解決方案。如何才能正確選擇，少挖坑，是件有趣的事情。
需要考量的因素
業務，團隊成員，技術
技術選型其實並非一個單純的技術問題，相反技術平台本身的考量往往是放在最后面的。首先需要考量的是業務本身的特殊性，再結合團隊成員的訴求與能力，最終才在技術方案間做個選擇題。
業務考量
所有脫離業務需求的技術方案，都是耍流氓
技術選型是一個小馬過河的故事，廠家宣傳的再怎么天花亂墜都好，只有真正契合業務上下文的方案才是好的方案，而每個項目都有自己的特殊性，選型者作為掌舵人，需要把項目上下文盡可能了解清楚，找出項目成敗最核心的1到2個標准，以此作為基礎來做選擇題。譬如說，創業項目，靈活是明顯的述求，產品推出后必然會面對朝令夕改的需求，如何快速反應是選型的重點。再譬如說，陳年項目性能遇到瓶頸需要重構，再往下挖可能原有系統吞吐量不成問題，但瞬時響應太差，選型時就需要特別注意這個點。以此類推
團隊成員
最終的執行人是成敗的關鍵
選擇的方案需要充分考慮團隊成員的技術構成。手頭有幾把槍，什么槍，未來多長一段時間可以有幾把槍，什么槍，需要心中有數。另外，方案的選擇需要在核心人員間充分溝通，互通有無，對后期的落地也會更順利些。
技術考量
多對比，多試驗
對以上兩個考慮因素有了充分理解后，技術考量反倒是相對容易的事情。多看，多試驗，“按部就班”，即可
盡可能多的羅列出現有解決方案
多數場景下我們所面對的問題，業界都有人面對過，在閉門造車之前，先尋訪下現有的解決方案。
技術前景如何？
技術前景是一個需要優先考量的因素，有些技術看起來性感無比，讓你恨不得立刻使用起來。但可能非常小眾，此時就要非常謹慎，沒准項目還沒有結束，選用的解決方案就太監了。
社區是否足夠活躍？
社區活躍度是技術前景的一部分，需要重點考量。可以通過查看Github的star數，issue數量，問題修復時長，新版本更新進度；Google Trends；stackoverflow問題數量；文檔是否健全；配套的生態是否完整；國內社區論壇版塊等查看
是否有大廠使用，是否有成熟的案例
站在巨人的肩膀上，自然能看的更遠。（當然，也可能摔的更痛，這就是另一個話題了）。成熟案例也是社區周邊成熟的一個風向標，如今多數團隊都會分享自己的部分解決方案，google之，能從中得到許多信息。
技術特性
本身的易用性、可維護性、可擴展性、學習成本等。初步選定后，多寫點DEMO，多試驗
黑歷史
技術領域不存在可以解決一切問題的銀彈，選型前需要先了解下技術棧的黑歷史。正反用例都需要接收
開源協議約束
開源項目都會有自己的協議規則，決議前需要了解清楚，避免往后的麻煩。
profile
這是個需要特別注意的點，沒有人能保證一個方案萬無一失，一旦出問題，是否有兜底方案，是否能快速strace到問題，profile到熱點顯得尤為重要。
性能
信息爆炸的今天，軟文無數，壓測還是要自己跑跑。
最后，還有個魔鬼需要面對
新技術之於技術人員，就好比新包包之於妹子，似乎每一個技術人員都對新技術有天然的沖動。
瞧！多么優雅，多么性感，馬上用起來！
千萬別！
有時候開發人員自己玩的很high，但項目卻玩死了。這是件很悲哀的事情，我們需要抑制內心深處的魔鬼，技術只有跟業務有機的結合起來，產出所追求的價值，才是有意義的。
拾零散記公眾號
