在互聯(lián)網(wǎng)系統(tǒng)中，開(kāi)發(fā)效率與系統(tǒng)穩(wěn)定性與產(chǎn)品成敗非常相關(guān)。開(kāi)發(fā)效率在一定程度反映了團(tuán)隊(duì)的執(zhí)行力，快速開(kāi)發(fā)能力帶來(lái)了產(chǎn)品的競(jìng)爭(zhēng)優(yōu)勢(shì)。系統(tǒng)穩(wěn)定性（包括安全及性能等）則是產(chǎn)品的后防線，稍有失誤則會(huì)給產(chǎn)品帶來(lái)很大傷害。因此開(kāi)發(fā)效率與系統(tǒng)穩(wěn)定性是衡量互聯(lián)網(wǎng)系統(tǒng)開(kāi)發(fā)成熟度最重要的兩個(gè)指標(biāo)。

在軟件開(kāi)發(fā)周期不同階段，這兩者如何控制？

在需求階段，對(duì)開(kāi)發(fā)效率的影響常見(jiàn)的是溝通理解偏差帶來(lái)的技術(shù)風(fēng)險(xiǎn)，之外最常見(jiàn)的還有需求變更的風(fēng)險(xiǎn)。后者大多是來(lái)自市場(chǎng)環(huán)境的變化作出調(diào)整，技術(shù)主管更多的是積極心態(tài)去應(yīng)對(duì)。但對(duì)前者溝通理解偏差導(dǎo)致效率問(wèn)題也不罕見(jiàn)，更值得警惕。

在技術(shù)設(shè)計(jì)階段***的風(fēng)險(xiǎn)是技術(shù)方案，找個(gè)無(wú)需多講，考驗(yàn)團(tuán)隊(duì)的架構(gòu)能力以及對(duì)當(dāng)前系統(tǒng)的駕馭程度。

開(kāi)發(fā)階段***的風(fēng)險(xiǎn)是單元測(cè)試不到位或缺失。很多號(hào)稱(chēng)“敏捷”型項(xiàng)目依賴(lài)在線上測(cè)試及修改，當(dāng)模塊增多后，這樣代碼健壯性就會(huì)變得比較脆弱，不少團(tuán)隊(duì)也會(huì)越走越慢。

Review階段風(fēng)險(xiǎn)是簡(jiǎn)潔性及性能。除了壓力測(cè)試能達(dá)標(biāo)之外，警惕那些不易懂的代碼，這些代碼將來(lái)會(huì)成為事故多發(fā)地帶。

部署階段***的風(fēng)險(xiǎn)是上線計(jì)劃把控，上線過(guò)程中操作錯(cuò)誤的情況并不罕見(jiàn)，如去年Amazon EC2的故障就是由于操作失誤造成。

從宏觀看來(lái)，技術(shù)方案的風(fēng)險(xiǎn)***，由于模塊很多，具有豐富經(jīng)驗(yàn)的高手不可能參與每一個(gè)環(huán)節(jié)，這就會(huì)出現(xiàn)木桶的短板效應(yīng)，架構(gòu)師認(rèn)為不重要的地方總是會(huì)出問(wèn)題。給用戶(hù)體驗(yàn)造成極大傷害。

另外還有團(tuán)隊(duì)文化的風(fēng)險(xiǎn)。大部分團(tuán)隊(duì)很難形成書(shū)面交流的習(xí)慣?？陬^溝通需求、討論方案對(duì)創(chuàng)業(yè)團(tuán)隊(duì)非常適合。在團(tuán)隊(duì)變大之后，這樣的習(xí)慣會(huì)造成信息流動(dòng)障礙，可能會(huì)給工作效率帶來(lái)更多負(fù)面問(wèn)題。同時(shí)大部分團(tuán)隊(duì)也對(duì)流程、模板、規(guī)范缺乏了解與重視，過(guò)多依賴(lài)參與人的內(nèi)部驅(qū)動(dòng)力及能力，無(wú)法依靠制度與流程來(lái)取勝。

原文鏈接：http://blog.jobbole.com/10504/

【編輯推薦】

1. 程序員應(yīng)該讀的故事：三個(gè)事和三個(gè)問(wèn)題
2. 怎樣做一個(gè)快樂(lè)的ASP.NET程序員
3. 為什么我們不要.NET程序員
4. 程序員，你應(yīng)該立馬修改有問(wèn)題的代碼
5. 一個(gè)六年級(jí)、12歲的程序員的演講【視頻】