qileilove

　　大公司或者大一點(diǎn)的團(tuán)隊的技術(shù)選型幾乎不需要太多討論，因為最后會不可避免地繞到技術(shù)官僚的話題上去。這里我簡單說說技術(shù)型創(chuàng)業(yè)團(tuán)隊的技術(shù)選型問題。

　　擁抱開源技術(shù)

　　如果只能選擇微軟的 技術(shù)路線，比如團(tuán)隊只會用微軟技術(shù)，也不想學(xué)別的，那么似乎沒有別的辦法，將就一下吧。如果還有的選擇，盡量使用開源技術(shù)。這樣不但可以有效降低軟硬件成 本，還有更多的部署方案可供選擇，服務(wù)器上線甚至還能避免病毒的侵襲。開源技術(shù)的好處是出了問題，你總有辦法可以找到答案。而用微軟的產(chǎn)品，可能平時不出 問題，但一出問題，你根本沒什么辦法。微軟的產(chǎn)品使用門檻倒是低，但復(fù)雜度可一點(diǎn)都不小，而且隨著發(fā)展，成本越來越高。國內(nèi)有幾個大中型網(wǎng)站，比如天涯、 5173、大眾點(diǎn)評、京東等，怕是深有感觸吧，有的因為成本太高而繼續(xù)被捆綁，有的則破釜沉舟要擺脫這種束縛，但不管怎樣，總要付出一定的開銷。

　　開源技術(shù)路線有數(shù)種分支，該怎樣選擇呢？選擇大路貨，選擇可以掌控的開源技術(shù)產(chǎn)品、語言、程序、框架，乃至解決方案。比如PHP，比不上Ruby陽春白雪，但用戶基數(shù)大，總能找到不錯的工程師。PHP雖然粗糙，但是管用。以PHP作為開發(fā)語言的成功產(chǎn)品不計其數(shù)，很多東西根本不需要你再開發(fā)，稍加定制即可。技術(shù)本身沒有高下之分，差別在于使用技術(shù)的人。

　　避免過度炫技

　　技術(shù)人員創(chuàng)業(yè)最容易犯的一個錯誤就是“炫技”，即熱衷于使用最新、最時髦的技術(shù)。新東西的確可以給技術(shù)人員以滿足感，但也很快會將你的時間資源消耗進(jìn)去，除非你準(zhǔn)備做的是一款基礎(chǔ)產(chǎn)品，否則你要花時間去學(xué)新規(guī)范、熟悉新功能、對付新出現(xiàn)的軟件Bug……但這時你最需要做的是開發(fā)產(chǎn)品，而不是搗鼓其他東西。一些新技術(shù)或者方案，可以花些時間分析一下但沒必要立刻就用，只需確保將來有一天能真的用上時，對一些重大的陷阱或是缺陷能夠了然即可。

　 　很多人神往37Signals的成功，但你一定要知道類似37Signals的團(tuán)隊，默默無聞地夭折掉的不知道有多少。每當(dāng)看到創(chuàng)業(yè)團(tuán)隊就那么1~2個 人還整天搗鼓Go、Erlang這些東西，并想硬生生地用到產(chǎn)品中去，我就知道，這樣的團(tuán)隊要懸了。有這些精力和能力，應(yīng)該想辦法盡快讓技術(shù)變現(xiàn)，研究一 下怎樣改進(jìn)產(chǎn)品、怎樣給用戶帶來更大的價值，而這些不一定用最好的技術(shù)才能做好。想辦法盡快讓產(chǎn)品發(fā)布，盡快接受更多人給你第一輪反饋，只憑創(chuàng)業(yè)團(tuán)隊幾個 人閉門冥想是很難出來好產(chǎn)品的，有時產(chǎn)品推出的時機(jī)比完備的功能更重要：GroupOn最早不過是搭建在WordPress上的幾個頁面，而阿里巴巴網(wǎng)站最初也不過是一個論壇，你又何必等到所有細(xì)節(jié)都打磨好呢？

　　擁抱開源技術(shù)，避免過度炫技，如果技術(shù)型團(tuán)隊創(chuàng)業(yè)（做互聯(lián)網(wǎng)），這兩條都能堅持的話，我想你已經(jīng)抓住了問題的80%的部分，基本上你不會做太多的無用功。

　　另外，剛啟動時不要直接招技術(shù)總監(jiān)、技術(shù)經(jīng)理、架構(gòu)師這些看起來級別很高的人，因為他們未必認(rèn)同你的想法和你現(xiàn)在的團(tuán)隊。建議找能實現(xiàn)你產(chǎn)品想法的人。最后有一點(diǎn)必須要說一下：不要因為一個人的技術(shù)喜好而舍棄整個技術(shù)團(tuán)隊，在任何時候這都是很愚蠢的事情。

　　作者馮大輝，丁香園網(wǎng)站CTO

　　在重大產(chǎn)品決策或者大規(guī)模應(yīng)用開發(fā)前一般需要進(jìn)行技術(shù)選型，其目的是為了降低產(chǎn)品研發(fā)的技術(shù)風(fēng)險。所以首先需要明確為什么需要技術(shù)選型、需要達(dá)到什么目的，整個過程需要有一套的組織流程來保證。

　 　一般可以將整個過程分為調(diào)研、候選對比、關(guān)鍵技術(shù)驗證、原型驗證幾個階段。在調(diào)研階段主要調(diào)研對象是目前該范圍業(yè)內(nèi)主要產(chǎn)品以及開源產(chǎn)品，需要了解其主 要技術(shù)特點(diǎn)和各自的優(yōu)勢和劣勢；在候選對比階段，是在前一階段基礎(chǔ)上選出兩種傾向用于最終路線的技術(shù)進(jìn)行進(jìn)一步的研究和對比。在關(guān)鍵技術(shù)驗證階段，需要列 出所有的技術(shù)驗證點(diǎn)，對驗證點(diǎn)描述、驗證方法、驗證步驟、驗證前提、驗證環(huán)境以及最后的交付物和評估方法指標(biāo)在驗證方案中體現(xiàn)；在原型驗證階段，主要是針 對重點(diǎn)關(guān)注的場景，通過一個原型來整體驗證比較。在這個階段一般需要進(jìn)行概念模型、編程模型以及結(jié)構(gòu)設(shè)計例如設(shè)計時視圖、系統(tǒng)結(jié)構(gòu)圖等，定義需要的 API，必要時還需要劃分子場景，在場景中包括場景描述、Feature、預(yù)研點(diǎn)以及相關(guān)設(shè)計。

　　當(dāng)然也需要對人員角色進(jìn)行分工，一般劃分程序經(jīng)理、開發(fā)人員、測試人 員幾種角色。程序經(jīng)理需要確定原型目標(biāo)范圍，編寫原型目標(biāo)文檔并組織評審；制訂和跟蹤原型開發(fā)計劃，對原型進(jìn)行驗證，確保原型符合原型目標(biāo)要求。開發(fā)人員 需要從開發(fā)角度提出原型需求，評審原型目標(biāo)文檔，按照原型目標(biāo)文檔和原型開發(fā)計劃完成原型相關(guān)設(shè)計和開發(fā)。測試人員需要Review原型目標(biāo)文檔，根據(jù)原 型目標(biāo)文檔采用一定的測試手段驗證原型是否符合原型目標(biāo)要求。

　　在最近我們進(jìn)行的ESB新產(chǎn)品中，就采用了類似上述的流程。我們確信技術(shù) 選型的最主要目標(biāo)是要自主掌控，所以從非常底層的技術(shù)開始，重點(diǎn)關(guān)注并發(fā)、資源隔離這樣的目標(biāo)，解決在不確定環(huán)境中實現(xiàn)交易控制和可擴(kuò)展的目標(biāo)。所以我們 設(shè)計了一個三段式的SEDA架構(gòu)，基本原則是要實現(xiàn)架構(gòu)的資源可分配性，提升吞吐率，當(dāng)然最初實現(xiàn)的功能可以比較簡單。通過上述流程，有效保證了我們在新 產(chǎn)品研發(fā)過程中的效率和產(chǎn)品架構(gòu)質(zhì)量。

　　最后，在技術(shù)選型產(chǎn)出物上，一般的結(jié)果可以有三類，有馬上轉(zhuǎn)化應(yīng)用的新產(chǎn)品，也可以是結(jié)合現(xiàn)有產(chǎn)品的一個解決方案，或者是某個方面的一個提升點(diǎn)（如一個新的組件）。

　　作者馮興智，普元信息資深架構(gòu)師

　　下面我結(jié)合自己公司的實際情況，談?wù)劤鮿?chuàng)企業(yè)或小型開發(fā)團(tuán)隊的技術(shù)選型。技術(shù)選型涉及產(chǎn)品/項目開發(fā)流程中各個環(huán)節(jié)所用到的工具和技術(shù)。例如項目開發(fā)前期的需求收集、整理分析工具、開發(fā)階段的IDE和版本控制系統(tǒng)、測試階段的測試工具等。

　　我們作為初創(chuàng)企業(yè)在進(jìn)行技術(shù)選型時會根據(jù)產(chǎn)品的需求、技術(shù)的復(fù)雜性、可擴(kuò)展性、跨平臺可移植性以及成本來做出最終的決策。

　　成本因素

　　初創(chuàng)企業(yè)的資源特別是資金往往不是很充裕，如果采用商業(yè)化的技術(shù)解決方案，往往價格不菲，像Visual Studio專業(yè)版、Windows Server、SQL Server的價格動輒上萬，這種情況下不妨考慮一些免費(fèi)開源的技術(shù)框架。比如使用SharpDevelop代替Visual Studio，MySQL代替SQL Server。此外，也可關(guān)注并加入一些針對初創(chuàng)企業(yè)的扶植計劃。例如我們創(chuàng)業(yè)前所工作的公司采用的都是微軟技術(shù)，大家對微軟技術(shù)掌握得很熟練，這樣自己 成立公司開發(fā)自己的產(chǎn)品時同樣優(yōu)先考慮微軟技術(shù)。我們通過加入微軟的BizSpark計劃，有效降低了成本。

　　復(fù)雜性，成熟度

　　我們在做技術(shù)選型時最忌諱的就是盲目追崇新技術(shù)和框架。有些技術(shù)剛剛面世不久，還沒有成熟的社區(qū)支持和成功案例。如果這時為了趕時髦或者在產(chǎn)品 的推廣宣傳上加點(diǎn)花頭而采用新技術(shù)的話，往往會導(dǎo)致項目陷入泥潭。采用不成熟技術(shù)而導(dǎo)致失敗的案例比比皆是，如網(wǎng)景在Java剛面世不久就使用Java重 寫Netscape Navigator瀏覽器，導(dǎo)致用戶體驗大幅下降及用戶群的流失。還有當(dāng)時被稱為下一代Windows客戶端技術(shù)的WPF，到現(xiàn)在發(fā)展得仍然不瘟不火，如 果僅僅是為了更炫的展現(xiàn)效果而使用WPF，結(jié)果肯定會得不償失。

　　產(chǎn)品自身因素

　　技術(shù)選型不可避免地要以產(chǎn)品為中心。如果產(chǎn)品是Windows智能客戶端軟件，那么微軟的技術(shù)框架必然成為優(yōu)先考慮。如果開發(fā)Android軟件，Eclipse和Android SDK同樣必不可少。

　　作者石鈺，奈特軟件聯(lián)合創(chuàng)始人、首席架構(gòu)師

　　我在微軟和騰訊從事了三年的軟件測試和團(tuán)隊管理工作，期間涉及兩大類的研發(fā)工作：第一，用于質(zhì)量控制的各種平臺系統(tǒng)，例如缺陷管理系統(tǒng)、用例管 理系統(tǒng)、產(chǎn)品健康指數(shù)可視化系統(tǒng)、自動測試管理系統(tǒng)等；第二，用于具體的產(chǎn)品測試工具，例如桌面軟件的UI自動化測試工具、JavaScript自動化測 試工具、Web服務(wù)壓力/性能測試工具等。

　　在團(tuán)隊的建設(shè)和技術(shù)選型上，遇到過一些困惑也走過一些彎路，總結(jié)出來有兩點(diǎn)經(jīng)驗。

　　閱讀公司文化，借鑒成功團(tuán)隊經(jīng)驗

　　測試團(tuán)隊一定要深刻閱讀和理解公司文化，作為其技術(shù)選型的首要考慮因素。比如，在微軟，無論是構(gòu)建質(zhì)量控制系統(tǒng)，還是開發(fā)各種產(chǎn)品測試工具，都以Windows+IIS+.NET作為技術(shù)框架；在騰訊，就會選擇LAMP這樣的開源技術(shù)框架。

　　在選定了技術(shù)框架的基礎(chǔ)上，還面臨一個問題，就是應(yīng)該如何去設(shè)計和實現(xiàn)出具體的系統(tǒng)或者工具。一個非常重要的經(jīng)驗就是一定要借鑒成功團(tuán)隊的經(jīng) 驗，站在巨人的肩上。例如，當(dāng)初在騰訊，我們需要評測QQ地圖的POI檢索功能的質(zhì)量和用戶滿意度。于是，我們花兩周時間設(shè)計了一個自以為完美的盲測系 統(tǒng)，結(jié)果在評審時才發(fā)現(xiàn)該盲測系統(tǒng)功能過于簡單而且性能達(dá)不到指標(biāo)。后來，我們在與騰訊SOSO團(tuán)隊討論時，才發(fā)現(xiàn)他們經(jīng)過多年的研發(fā)，已經(jīng)有一款非常完 善的搜索盲測系統(tǒng)，直接借鑒過來，就能很好地解決項目測試的問題。這點(diǎn)特別是對很多新任命的團(tuán)隊負(fù)責(zé)人，是很重要的經(jīng)驗。

　　敏捷務(wù)實，持續(xù)集成，切勿過設(shè)計

　　工程的基本要素是實用和強(qiáng)調(diào)執(zhí)行力。對于一個軟件/互聯(lián)網(wǎng)企業(yè)或者團(tuán)隊而言，最重要的是先解決眼前遇到的具體問題，而不是盲目追求系統(tǒng)的擴(kuò)展性 和性能。例如，我們在測評QQ地圖后臺服務(wù)的性能狀況時，首先想到的是選用的測試方案要具備良好的功能特性，可擴(kuò)展性要強(qiáng)、足夠開放，能夠與已有的一個研 發(fā)管理系統(tǒng)做集成。按照這個標(biāo)準(zhǔn)，我們選擇了LoadRunner，這是一個比較復(fù)雜的工具，光配置就花掉了大量的時間。結(jié)果，導(dǎo)致實際測試的時間太靠 后，發(fā)現(xiàn)的性能問題都無法在即將發(fā)布的版本中得到修正。這就是一個非常典型的因為過設(shè)計而引發(fā)的技術(shù)選型耽誤工程進(jìn)度的例子。后來，我們選用 http_load這個開源、簡單、實用的工具對后臺服務(wù)做快速的壓力測試，從而在第一時間得到測試報告。然后在沒有測試任務(wù)的時候，花時間將該工具集成 至研發(fā)管理系統(tǒng)中，做到了持續(xù)集成。

　　其實總結(jié)起來，測試團(tuán)隊的技術(shù)選型首先要順應(yīng)公司的框架性要求，然后在具體實施過程中，要以解決問題作為決策目標(biāo)，多向成功團(tuán)隊取經(jīng)，敏捷務(wù)實，切勿過設(shè)計。

　　作者劉舒，阿里巴巴高級產(chǎn)品經(jīng)理，曾任微軟測試開發(fā)工程師、騰訊測試經(jīng)理

　　轉(zhuǎn)載自：http://www.programmer.com.cn/8514/