注：本文轉載自《程式設計師》
好的技術選型，能最大程度地提高企業和團隊的效率，從而開發出滿足使用者需求的產品。作為一線的技術管理者，他們都是怎樣做的呢？
大公司或者大一點的團隊的技術選型幾乎不需要太多討論，因為最後會不可避免地繞到技術官僚的話題上去。這裡我簡單說說技術型創業團隊的技術選型問題。
擁抱開源技術
如果只能選擇微軟的技術路線，比如團隊只會用微軟技術，也不想學別的，那麼似乎沒有別的辦法，將就一下吧。如果還有的選擇，儘量使用開源技術。這樣不但可以有效降低軟硬體成本，還有更多的部署方案可供選擇，伺服器上線甚至還能避免病毒的侵襲。開源技術的好處是出了問題，你總有辦法可以找到答案。而用微軟的產品，可能平時不出問題，但一出問題，你根本沒什麼辦法。微軟的產品使用門檻倒是低，但複雜度可一點都不小，而且隨著發展，成本越來越高。國內有幾個大中型網站，比如天涯、5173、大眾點評、京東等，怕是深有感觸吧，有的因為成本太高而繼續被捆綁，有的則破釜沉舟要擺脫這種束縛，但不管怎樣，總要付出一定的開銷。
開源技術路線有數種分支，該怎樣選擇呢？選擇大路貨，選擇可以掌控的開源技術產品、語言、程式、框架，乃至解決方案。比如 PHP，比不上 Ruby 陽春白雪，但使用者基數大，總能找到不錯的工程師。PHP 雖然粗糙，但是管用。以 PHP 作為開發語言的成功產品不計其數，很多東西根本不需要你再開發，稍加定製即可。技術本身沒有高下之分，差別在於使用技術的人。
避免過度炫技
技術人員創業最容易犯的一個錯誤就是“炫技”，即熱衷於使用最新、最時髦的技術。新東西的確可以給技術人員以滿足感，但也很快會將你的時間資源消耗進去，除非你準備做的是一款基礎產品，否則你要花時間去學新規範、熟悉新功能、對付新出現的軟體 Bug……但這時你最需要做的是開發產品，而不是搗鼓其他東西。一些新技術或者方案，可以花些時間分析一下但沒必要立刻就用，只需確保將來有一天能真的用上時，對一些重大的陷阱或是缺陷能夠了然即可。
很多人神往 37Signals 的成功，但你一定要知道類似 37Signals 的團隊，默默無聞地夭折掉的不知道有多少。每當看到創業團隊就那麼1~2個人還整天搗鼓 Go、Erlang 這些東西，並想硬生生地用到產品中去，我就知道，這樣的團隊要懸了。有這些精力和能力，應該想辦法儘快讓技術變現，研究一下怎樣改進產品、怎樣給使用者帶來更大的價值，而這些不一定用最好的技術才能做好。想辦法儘快讓產品釋出，儘快接受更多人給你第一輪反饋，只憑創業團隊幾個人閉門冥想是很難出來好產品的，有時產品推出的時機比完備的功能更重要：GroupOn 最早不過是搭建在 WordPress 上的幾個頁面，而阿里巴巴網站最初也不過是一個論壇，你又何必等到所有細節都打磨好呢？
擁抱開源技術，避免過度炫技，如果技術型團隊創業（做網際網路），這兩條都能堅持的話，我想你已經抓住了問題的80%的部分，基本上你不會做太多的無用功。
另外，剛啟動時不要直接招技術總監、技術經理、架構師這些看起來級別很高的人，因為他們未必認同你的想法和你現在的團隊。建議找能實現你產品想法的人。最後有一點必須要說一下：不要因為一個人的技術喜好而捨棄整個技術團隊，在任何時候這都是很愚蠢的事情。
作者馮大輝，丁香園網站 CTO
在重大產品決策或者大規模應用開發前一般需要進行技術選型，其目的是為了降低產品研發的技術風險。所以首先需要明確為什麼需要技術選型、需要達到什麼目的，整個過程需要有一套的組織流程來保證。
一般可以將整個過程分為調研、候選對比、關鍵技術驗證、原型驗證幾個階段。在調研階段主要調研物件是目前該範圍業內主要產品以及開源產品，需要了解其主要技術特點和各自的優勢和劣勢；在候選對比階段，是在前一階段基礎上選出兩種傾向用於最終路線的技術進行進一步的研究和對比。在關鍵技術驗證階段，需要列出所有的技術驗證點，對驗證點描述、驗證方法、驗證步驟、驗證前提、驗證環境以及最後的交付物和評估方法指標在驗證方案中體現；在原型驗證階段，主要是針對重點關注的場景，通過一個原型來整體驗證比較。在這個階段一般需要進行概念模型、程式設計模型以及結構設計例如設計時檢視、系統結構圖等，定義需要的 API，必要時還需要劃分子場景，在場景中包括場景描述、Feature、預研點以及相關設計。
當然也需要對人員角色進行分工，一般劃分程式經理、開發人員、測試人員幾種角色。程式經理需要確定原型目標範圍，編寫原型目標文件並組織評審；制訂和跟蹤原型開發計劃，對原型進行驗證，確保原型符合原型目標要求。開發人員需要從開發角度提出原型需求，評審原型目標文件，按照原型目標文件和原型開發計劃完成原型相關設計和開發。測試人員需要 Review 原型目標文件，根據原型目標文件採用一定的測試手段驗證原型是否符合原型目標要求。
在最近我們進行的 ESB 新產品中，就採用了類似上述的流程。我們確信技術選型的最主要目標是要自主掌控，所以從非常底層的技術開始，重點關注併發、資源隔離這樣的目標，解決在不確定環境中實現交易控制和可擴充套件的目標。所以我們設計了一個三段式的 SEDA 架構，基本原則是要實現架構的資源可分配性，提升吞吐率，當然最初實現的功能可以比較簡單。通過上述流程，有效保證了我們在新產品研發過程中的效率和產品架構質量。
最後，在技術選型產出物上，一般的結果可以有三類，有馬上轉化應用的新產品，也可以是結合現有產品的一個解決方案，或者是某個方面的一個提升點（如一個新的元件）。
作者馮興智，普元資訊資深架構師
關於公司/團隊技術選型的話題涉及到很多非技術層面的問題，特別是大公司在技術選型方面，不可避免要受到企業官僚的影響。
下面我結合自己公司的實際情況，談談初創企業或小型開發團隊的技術選型。技術選型涉及產品/專案開發流程中各個環節所用到的工具和技術。例如專案開發前期的需求收集、整理分析工具、開發階段的 IDE 和版本控制系統、測試階段的測試工具等。
我們作為初創企業在進行技術選型時會根據產品的需求、技術的複雜性、可擴充套件性、跨平臺可移植性以及成本來做出最終的決策。
成本因素
初創企業的資源特別是資金往往不是很充裕，如果採用商業化的技術解決方案，往往價格不菲，像 Visual Studio 專業版、Windows Server、SQL Server 的價格動輒上萬，這種情況下不妨考慮一些免費開源的技術框架。比如使用 SharpDevelop 代替 Visual Studio，MySQL 代替 SQL Server。此外，也可關注並加入一些針對初創企業的扶植計劃。例如我們創業前所工作的公司採用的都是微軟技術，大家對微軟技術掌握得很熟練，這樣自己成立公司開發自己的產品時同樣優先考慮微軟技術。我們通過加入微軟的 BizSpark 計劃，有效降低了成本。
複雜性，成熟度
我們在做技術選型時最忌諱的就是盲目追崇新技術和框架。有些技術剛剛面世不久，還沒有成熟的社群支援和成功案例。如果這時為了趕時髦或者在產品的推廣宣傳上加點花頭而採用新技術的話，往往會導致專案陷入泥潭。採用不成熟技術而導致失敗的案例比比皆是，如網景在 Java 剛面世不久就使用 Java 重寫 Netscape Navigator 瀏覽器，導致使用者體驗大幅下降及使用者群的流失。還有當時被稱為下一代 Windows 客戶端技術的 WPF，到現在發展得仍然不瘟不火，如果僅僅是為了更炫的展現效果而使用 WPF，結果肯定會得不償失。
產品自身因素
技術選型不可避免地要以產品為中心。如果產品是 Windows 智慧客戶端軟體，那麼微軟的技術框架必然成為優先考慮。如果開發 Android 軟體，Eclipse 和 Android SDK 同樣必不可少。
作者石鈺，奈特軟體聯合創始人、首席架構師
我在微軟和騰訊從事了三年的軟體測試和團隊管理工作，期間涉及兩大類的研發工作：第一，用於質量控制的各種平臺系統，例如缺陷管理系統、用例管理系統、產品健康指數視覺化系統、自動測試管理系統等；第二，用於具體的產品測試工具，例如桌面軟體的 UI 自動化測試工具、JavaScript 自動化測試工具、Web 服務壓力/效能測試工具等。
在團隊的建設和技術選型上，遇到過一些困惑也走過一些彎路，總結出來有兩點經驗。
閱讀公司文化，借鑑成功團隊經驗
測試團隊一定要深刻閱讀和理解公司文化，作為其技術選型的首要考慮因素。比如，在微軟，無論是構建質量控制系統，還是開發各種產品測試工具，都以 Windows+IIS+.NET 作為技術框架；在騰訊，就會選擇 LAMP 這樣的開源技術框架。
在選定了技術框架的基礎上，還面臨一個問題，就是應該如何去設計和實現出具體的系統或者工具。一個非常重要的經驗就是一定要借鑑成功團隊的經驗，站在巨人的肩上。例如，當初在騰訊，我們需要評測 QQ 地圖的 POI 檢索功能的質量和使用者滿意度。於是，我們花兩週時間設計了一個自以為完美的盲測系統，結果在評審時才發現該盲測系統功能過於簡單而且效能達不到指標。後來，我們在與騰訊 SOSO 團隊討論時，才發現他們經過多年的研發，已經有一款非常完善的搜尋盲測系統，直接借鑑過來，就能很好地解決專案測試的問題。這點特別是對很多新任命的團隊負責人，是很重要的經驗。
敏捷務實，持續整合，切勿過設計
工程的基本要素是實用和強調執行力。對於一個軟體/網際網路企業或者團隊而言，最重要的是先解決眼前遇到的具體問題，而不是盲目追求系統的擴充套件性和效能。例如，我們在測評 QQ 地圖後臺服務的效能狀況時，首先想到的是選用的測試方案要具備良好的功能特性，可擴充套件性要強、足夠開放，能夠與已有的一個研發管理系統做整合。按照這個標準，我們選擇了 LoadRunner，這是一個比較複雜的工具，光配置就花掉了大量的時間。結果，導致實際測試的時間太靠後，發現的效能問題都無法在即將釋出的版本中得到修正。這就是一個非常典型的因為過設計而引發的技術選型耽誤工程進度的例子。後來，我們選用 http_load 這個開源、簡單、實用的工具對後臺服務做快速的壓力測試，從而在第一時間得到測試報告。然後在沒有測試任務的時候，花時間將該工具整合至研發管理系統中，做到了持續整合。
其實總結起來，測試團隊的技術選型首先要順應公司的框架性要求，然後在具體實施過程中，要以解決問題作為決策目標，多向成功團隊取經，敏捷務實，切勿過設計。
作者劉舒，阿里巴巴高階產品經理，曾任微軟測試開發工程師、騰訊測試經理