環(huán)境、現(xiàn)狀與反思

　　我們所處的環(huán)境是一個(gè)追求“革命性技術(shù)”的業(yè)界。公司追求著多、快、好、省地解決問題的捷徑，管理者關(guān)注的只是軟件進(jìn)度、發(fā)布版本、成本和利潤，在他們背后，軟件缺陷已經(jīng)埋了下來。專注代碼質(zhì)量的程序員往往不受青睞，因?yàn)樗麄兯伎嫉母?，在開發(fā)進(jìn)度方面往往不盡人意。當(dāng)項(xiàng)目負(fù)責(zé)人無法評估或不關(guān)注代碼質(zhì)量時(shí)，客戶只會(huì)得到一堆調(diào)試不良的代碼。

1.2 人才流失

　　今天的程序員大多數(shù)都不會(huì)長期從事某一種技術(shù)，這與收入緊密掛鉤。程序員會(huì)傾向與轉(zhuǎn)型為更高收入的技術(shù)隊(duì)伍，或者退出IT業(yè)。隨著市場供求關(guān)系，各個(gè)陣營市場占有率，利潤等多種因素左右著程序員的收入。即便是在某個(gè)技術(shù)上十分出眾的程序員，面對經(jīng)濟(jì)上的現(xiàn)實(shí)差距，也無法抵抗金錢的誘惑而轉(zhuǎn)投其他技術(shù)隊(duì)伍?，F(xiàn)在的市場，不再尊重那些資深從業(yè)者，而是迎合“現(xiàn)學(xué)現(xiàn)賣”的投機(jī)者。歸其根本在于，對代碼質(zhì)量的低要求，使得技術(shù)硬手無用武之地。

1.3 系統(tǒng)交互復(fù)雜

　　今日的信息化系統(tǒng)已經(jīng)不能由獨(dú)立的公司或軟件產(chǎn)品承擔(dān)，而是趨于多公司，多平臺(tái)的相互協(xié)作與交互?，F(xiàn)實(shí)的挑戰(zhàn)就是，更大的系統(tǒng)，更多的平臺(tái)，更繁瑣的流程，更復(fù)雜的整合需求，以及更多的標(biāo)準(zhǔn)。

1.4 技術(shù)快餐

　　與之前不同，現(xiàn)今的開發(fā)者更為大膽。他們敢于將未經(jīng)驗(yàn)證的新技術(shù)應(yīng)用與產(chǎn)品或項(xiàng)目。開發(fā)者可能經(jīng)過短暫的學(xué)習(xí)（一周或者幾天）就將學(xué)到的并不熟練的技術(shù)應(yīng)用于項(xiàng)目，之后的風(fēng)險(xiǎn)全部轉(zhuǎn)嫁的測試或者客戶身上。而此后也不再對這些新技術(shù)繼續(xù)安排學(xué)習(xí)。程序的可靠程度和可維護(hù)性大大降低。

1.5 產(chǎn)品團(tuán)隊(duì)不堪重負(fù)

　　與項(xiàng)目不同，產(chǎn)品的代碼版本及分支路線更為復(fù)雜，其生命周期更長。當(dāng)你進(jìn)入某個(gè)產(chǎn)品項(xiàng)目，你很可能面臨的是，缺失或低質(zhì)的項(xiàng)目文檔，多種風(fēng)格并存的代碼以及潦草的少的可憐的注釋。那些最先搭建系統(tǒng)的前輩可能已經(jīng)離職，開發(fā)團(tuán)隊(duì)組成也許已經(jīng)經(jīng)過幾代，你聽到的最多的是抱怨。面對那些延期的bug和新的需求，沒人通曉這些堆積如山的代碼，牽一發(fā)往往動(dòng)全身。閱讀和理解代碼占據(jù)工作的大部分，面對客戶的各種要求往往不堪負(fù)重。

2 一些成功的經(jīng)驗(yàn)

2.1 提高代碼質(zhì)量

改進(jìn)QA流程 多數(shù)QA僅僅依靠大范圍的人工測試來評價(jià)項(xiàng)目質(zhì)量，即多數(shù)公司的QA依靠的是測試團(tuán)隊(duì)。理想情況下，大范圍的測試并不會(huì)有很高的錯(cuò)誤檢出率。（如果你的團(tuán)隊(duì)，每次發(fā)布版本，你們的新建和重新打開的bug數(shù)量仍然很高，我只能說你們的公司尚處于軟件作坊階段，真正成熟的團(tuán)隊(duì)，是不會(huì)允許交付測試團(tuán)隊(duì)一堆調(diào)試不良的代碼的，即便是在趕工時(shí)。）檢查缺陷最有效，同時(shí)也是檢出率最高的方法，就是——代碼審查。因此，必須在計(jì)劃階段，就為代碼審查預(yù)留時(shí)間，以便讓開發(fā)人員參與進(jìn)來。
激勵(lì)手段 在績效結(jié)構(gòu)中，應(yīng)該與質(zhì)量、進(jìn)度、復(fù)雜度等掛鉤，而不是單純地只看進(jìn)度。
測試每一個(gè)關(guān)鍵里程碑 理想情況下，測試每個(gè)版本，測試用例做到100%的覆蓋率。但現(xiàn)實(shí)中，出于時(shí)間、成本等因素，測試不可能細(xì)化到邊邊角角。但對每個(gè)里程碑進(jìn)行全面回歸測試是最低的要求，這樣軟件的bug更少，開發(fā)團(tuán)隊(duì)更能受到激勵(lì)（例外是測試報(bào)告不盡如人意）。
樂觀的對待錯(cuò)誤 不要把測試當(dāng)成是對代碼的雞蛋里面挑骨頭，不要埋怨為什么測試現(xiàn)在才測試出之前某個(gè)版本的缺陷。PM一定要避免開發(fā)團(tuán)隊(duì)和測試團(tuán)隊(duì)之間的相互指責(zé)。
要求清晰、簡潔、明清的測試報(bào)告 測試報(bào)告應(yīng)該言簡意賅，不要過于追求樣式華麗，技術(shù)型文檔能夠用一句話說明白就別啰嗦。
使用缺陷核對表 “缺陷核對表”我也想不起它的出處了，也或許是我的主觀創(chuàng)造，但從項(xiàng)目實(shí)踐角度講，“缺席核對表”能夠有效降低缺陷數(shù)量。下列顯示了一種簡單的缺陷核對表：

問題描述	根本原因	缺陷類型	嚴(yán)重程度	出現(xiàn)次數(shù)	解決方法
修改下拉列表內(nèi)容后，進(jìn)行操作會(huì)觸發(fā)未處理異常。	數(shù)據(jù)完整性約束被破壞，阻止操作。	設(shè)計(jì)缺陷	嚴(yán)重	4	禁止修改下拉列表選項(xiàng)。
上傳大文件報(bào)錯(cuò)。	服務(wù)端限流。	配置缺陷	一般	2	修改配置文件的消息大小限制。
...	...	...	...	...	...