在重大產品決策或者大規模應用開發前一般需要進行技術選型，特別是需要開發乙個之前沒有了解過的系統或者應用時，其目的是為了降低產品研發的技術風險。所以首先需要明確為什麼需要技術選型、需要達到什麼目的，整個過程需要有一套的組織流程來保證。
一般可以將整個過程分為調研、候選對比、關鍵技術驗證、原型驗證幾個階段。
在調研階段主要調研物件是目前該範圍業內主要產品以及開源產品，需要了解其主要技術特點和各自的優勢和劣勢。從以下幾個方面入手：
1、實現當前的需求，主要用到哪種技術；
2、該技術的成熟度如何，是否被廣泛使用；
3、該技術目前由誰支援，是否持續更新或者權威性如何；
4、該技術的優勢和劣勢，以及存在的風險；
5、技術的複雜性如何，當前團隊對該技術的熟悉程度和可能需要的時間；
在候選對比階段，是在前一階段基礎上選出兩種傾向用於最終路線的技術進行進一步的研究和對比。在此同時，需要需求人員給出產品使用的場景以及模擬，這一點是很有必要的。因為明確了產品的應用場景，才能對技術需要解決的問題進行更好的把握，避免選錯，導致最後專案失敗。比如有需要用新的核心開發遊戲盒子的需求，主要解決遊戲的體驗和流暢性問題，以及ie核心遊戲盒子的弊端。如果需求只是這樣，並不能很好的指導技術選型，因為還不知道要支援遊戲還需要些什麼。因此還需要更明確的指出使用場景，如玩的是頁遊，最少要穩定支援到10個遊戲多開，頁遊對cpu和記憶體等資源占用比較大，需要相容到windows系統xp及xp以後的版本。這樣列出來後，技術人員就會知道使用的技術必須在遊戲多開時和系統資源占用大時，應用要穩定和流暢。
在關鍵技術驗證階段，需要列出所有的技術驗證點，對驗證點描述、驗證方法、驗證步驟、驗證前提、驗證環境以及最後的交付物和評估方法指標在驗證方案中體現；
在原型驗證階段，主要是針對重點關注的場景，通過乙個原型來整體驗證比較。在這個階段一般需要進行概念模型、程式設計模型以及結構設計例如設計時檢視、系統結構圖等，定義需要的api，必要時還需要劃分子場景，在場景中包括場景描述、特寫、預研點以及相關設計。
以上是在技術流程上怎麼選型，在選型時還要注意到以下幾點：
1、實事求是，不要一味的擁抱開源或者依賴收費支援，只選擇適合解決當前問題的技術。
2、不要炫技，熱衷於時髦技術，選擇最新的東西讓人有成就感，但沒經過市場大規模檢驗的技術，也會讓人陷入泥坑。
3、敏捷務實，借鑑其他團隊的成功經驗，並且不要過度設計和拓展。
如何進行架構技術方案選型
在架構設計時,通常面臨的乙個難題是,如何選擇架構的技術方案.這也是各種專案都會碰到的問題.我們到底是選擇c s，b s模式，如果選擇c s,那麼到底是三層c s還是兩層，到底要不要分布式，b s的展示層是自己寫mvc，還是應用已有的開源的如spring mvc，struts 2.0,jsf技術。總之...
如何進行架構技術方案選型
在架構設計時,通常面臨的乙個難題是,如何選擇架構的技術方案.這也是各種專案都會碰到的問題.我們到底是選擇c s，b s模式，如果選擇c s,那麼到底是三層c s還是兩層，到底要不要分布式，b s的展示層是自己寫mvc，還是應用已有的開源的如spring mvc，struts 2.0,jsf技術。總之...
如何進行合適的前端技術選型
適合自己 團隊 的技術棧才是好技術棧 在專案的架構中，我們需要選擇各種技術棧所對應的技術 在專案的開發中，我們需要選擇各種工具庫。技術選型是我們必然會碰到的，我們常常面臨的不是單個技術的選型，而是對於乙個專案所涉及的一整套技術 方案 規範或者產品的選型。我們需要仔細的去權衡各種技術 各種組合的利弊，...