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

昵稱10504424 2013-12-24

展開全文

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

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

1.2 人才流失

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

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

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

1.4 技術快餐

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

1.5 產(chǎn)品團隊不堪重負

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

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

2.1 提高代碼質量

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

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