開幹
技術選型是企業項目研發中少不了的一個環節，大部分情況下企業都是優先採用開源免費的技術框架。
有實力的企業在選定技術框架後可能還會做一定的改造優化，以更匹配自己的應用場景，而大部分中小型企業則更多是對技術框架的應用。
所以對中小型企業來說，一個技術框架的選擇至關重要，因爲在不具備改造開源框架能力的情況下，如果選擇了不合適企業實際情況的技術框架，可能解決不了問題，還會帶來新的問題。
那麼如何選擇一款既適合自己的團隊又能解決當下面臨的問題，不急，我們且往下看。
到底怎麼選？
1、確定問題核心
這一點，也是我們進行技術選型的動機和出發點，所以很關鍵，很多情況下我們解決不了問題的原因是不知道問題的根在哪，技術選型也是一樣，必須搞清楚引入這一個技術或組件要解決的核心問題是什麼，確定自己的問題場景，越具體越好。不能爲了用而用。
大部分情況下，每引入一個新的技術組件，在解決現有問題的同時可能會帶來新的問題.。所以在確定現有代碼、技術組件經過轉換思路、變通實現也確實無法解決面臨的問題時，再考慮引入新的技術框架。
2、列出技術框架清單
基於第一點分析出的核心問題場景，列出可以解決問題的相關技術框架，一般來說每個問題場景的解決方案都不止一種，這個過程可以輸出到文檔也可以存在於自己的腦子裏。
這裏有一個問題就是列表中的技術框架都從哪來，我個人的來源主要是這麼幾個途徑：書籍視頻、技術博客，搜索引擎，技術社羣，github、gitee代碼倉庫。不管是平時積累還是現查，途徑大致就這麼多。
這裏多說一點，平時看到一些好的解決方案或技術，要注意積累，可能當下用不到，但至少在腦子裏留個印象，記住關鍵詞和核心應用場景，記不住就弄個筆記，當有一天碰到具體問題的時候，在進行具體研究。
3、評估學習成本
有了上面的技術框架清單，下面就需要結合各種情況進行篩選，選出最合適自己或企業的技術，首先就是學習成本的評估。我們需要考慮團隊內部的可接受能力和學習能力，不能盲目選擇。
1）儘量選擇與公司當前使用的主語言一致的技術框架，如公司使用的Java，而找的技術框架是golang語言實現，而公司如果沒有專門的golang開發工程師或團隊，那麼如果使用該解決方案，就需要額外學習golang。
2）文檔是否完善，非常重要，除非你願意直接啃着源碼學習，完善的文檔可大大提升學習效率
3）網上是否有較多的相關學習資料或技術博客，官方文檔更多是技術本身的使用說明，而缺乏實際場景的應用和問題解決方案，所以網上的學習資料和問答有助於我們在使用過程中快速解決和定位問題。
4、評估使用成本
1）與現有系統結合時，所需要的改造成本，一般來說，新項目情況會好一些，主要是歷史項目或已經有大量功能開發完成的項目，如果接入這樣的技術框架，是否改動足夠小。如果動靜太大，就需要再斟酌斟酌。
2）投入生產時需要的運行環境或者說物理機配置，比如預算僅僅是兩臺服務器，而框架官方建議五臺集羣起，這就是一種使用成本。
5、社區活躍度
社區活躍度決定了一個技術能走多遠，也決定了使用過程出現問題能不能得到及時響應，又或者出現BUG能不能及時得到修復。看一個技術的社區活躍度可從以下幾方面觀察。
1）看github、gitee上的star、fork數，一般來說，能過千的都還可以考慮
2）看issue是否能及時得到解決
3）看版本迭代速度和代碼提交歷史是否較爲頻繁，這個頻繁說的是至少近2、3個月內有提交記錄或版本發佈。而不是提交記錄或最後一個版本還停留在幾年前。
4）搜索框架，是否有一定量的博客或技術問答帖，能搜到說明使用的人多。
6、技術維護團隊
1）儘量選擇背後有團隊支撐的技術框架，當然不乏有個人維護的很優秀的項目，但是長遠來看，團隊的更加有保障，這個道理相信大家都懂。
但是不是說個人的開源項目就不能使用了，當然可以使用，前提是假如有一天作者不維護了，那麼你具有二次改造的能力，又或者你就沒有改造的需求，現有功能完全可以滿足使用。這種情況下，使用個人的開源項目也無妨。
2）上面說了在團隊與個人之間，優先選擇團隊，那麼在團隊與團隊之間同樣優先選擇有大企業或知名的開源組織的開源項目。
拿企業來說阿里開源的相對於其他中小企業的開源項目來說，阿里的開源項目肯定更有保障，Apache相比其他組織也更容易讓使用者信任。
7、行業內是否主流
主流意味着用的企業多，會的人多，生產環境下的問題解決方案也自熱就多，企業內部人員流動是常態，人多有利於企業降低招聘成本和內部人才梯隊的延續，也可以降低學習成本。解決方案多能減少因技術障礙帶來的開發成本。
如果選擇太偏門的技術，一方面出現問題沒有太多的解決方案可以參考，另一方面市面上對應的求職者也少，招進來內部培訓也可以，那是不是又增加了一定的學習成本。
8、避免盲目追求主流
納尼？這個不是跟上面是矛盾的嗎？不，一點都不矛盾，上面說的是儘量使用主流，來降低團隊人員流動帶來的成本，但主流不代表你就能駕馭的了，這裏我們對自己團隊的能力要有清晰的認識，駕馭不好只能帶來線上事故，因此對於技術實力一般的企業來說，在主流和熟悉之間，還是應當選擇熟悉，畢竟拿的住，保證項目能穩定運行是根本。
9、嚐鮮需謹慎
技術領域每天都會產生很多新的技術，新的解決方案，作爲技術人員的我們應時常保持一顆學習的心態，初現的新技術作爲知識拓展，增長見識是可以的，但要直接應用到項目中還需謹慎，因爲社區、文檔可能並不完善，存在一定的學習成本，另一方面還未經過大規模生產環境檢驗，可能存在未知的缺陷，後期出現莫名奇妙的問題，遭罪的就是你和你的團隊。
10、場景測試
最後最後，以上綜合評估完成後，一定要做的就是進行場景測試，拿具體的技術應用到自己的業務場景，寫幾個Case進行測試，各方面判斷是否能夠解決問題，最終選取符合公司情況的技術框架即可。
在沒做場景測試之前，切不可直接大規模直接應用到項目中，除非所選技術在別的項目已經使用驗證過，有真實的生產實踐經驗，不然單靠文檔或一些資料得到的僅僅是直觀感受而已，具體合不合適，還得真實的Coding一把才知道。
總結
以上綜合起來就能保證所選的技術萬無一失嗎？並不能，但是可以大大降低出錯的概率，至少眼下來看是合適的。
技術選型其實也是一種權衡與取捨，不可能面面俱到，所以進行技術選型時，我們應該清晰的認識到
1、技術本身並無好壞，適合自己的就是最好的。
2、沒有銀彈，只有匹配當下場景的最優解，沒有完美的解決方案。