引用：
軟件質(zhì)量得控制牽涉到很多變量。關(guān)鍵是在每個(gè)步驟都需要管理和控制。需要規(guī)范化整個(gè)軟件開發(fā)過程。
1、需求得時(shí)候做需求評(píng)審。但是怎樣引導(dǎo)客戶來提出確切得需求，就需要很好得溝通技巧，在客戶需求了解得前提下，針對(duì)開發(fā)項(xiàng)目所做得技術(shù)需求，應(yīng)該進(jìn)行評(píng)審。
2、概要設(shè)計(jì)時(shí)體系結(jié)構(gòu)的評(píng)審、多次討論。并保證足夠的時(shí)間和精力來充分討論所做的概要設(shè)計(jì)是否真正滿足需求。不能以進(jìn)度太緊等借口將概要做的馬馬乎乎，直接開始代碼編寫。（這也是以前做項(xiàng)目時(shí)最常犯的毛病。）項(xiàng)目經(jīng)理必須有膽量有信心頂住老板的壓力，很多BOSS衡量進(jìn)度就會(huì)問，你編了幾行代碼了？怎么還在這里什么都沒做？
3、詳細(xì)設(shè)計(jì)盡可能統(tǒng)一、規(guī)范。編碼時(shí)要有統(tǒng)一的編碼規(guī)則。命名規(guī)則等約束。即使天才程序員也應(yīng)遵循適當(dāng)?shù)囊?guī)范。否則大家以后在維護(hù)天才的代碼的同時(shí)，肯定會(huì)在心里大罵。
4、測試要在需求和設(shè)計(jì)階段就開始，不能等到編碼結(jié)束再進(jìn)行。再編碼過程中的單元測試應(yīng)得到重視，程序員之間的交換測試可以取得一定的效果。發(fā)現(xiàn)問題越早，麻煩越少。
5、對(duì)重要的功能實(shí)現(xiàn)代碼做CODEREVIEW。為避免流于形式，在會(huì)前要充分協(xié)調(diào)，作好準(zhǔn)備。
6、版本控制。需求變動(dòng)控制。適當(dāng)?shù)厥褂霉ぞ哌M(jìn)行版本和需求變更的控制。避免后期版本混亂，做無用功。
7、當(dāng)然還有文檔，要做就做規(guī)范，做踏實(shí)。應(yīng)付檢查和交差的文檔不做也罷，浪費(fèi)時(shí)間而已。文檔太難控制的話，在編碼時(shí)作好注釋也可作為一種方法。
而現(xiàn)實(shí)中是：
1、產(chǎn)品中沒有白盒測試的概念，從最底層代碼開始，經(jīng)過多年的修改，已經(jīng)是千瘡百孔。具體一個(gè)函數(shù)有多少隱含的問題要進(jìn)行測試、統(tǒng)計(jì)一下。
2、代碼不進(jìn)行重構(gòu)，公司領(lǐng)導(dǎo)不重視重構(gòu)，導(dǎo)致代碼腐爛很嚴(yán)重。很簡單的事實(shí)，一個(gè)配置變量在多處進(jìn)行維護(hù)著 ，一旦進(jìn)行修改，就要去修改很多處。再加上模塊充斥著幾千行的類和幾千行的文件。最大的一個(gè)類triadapter達(dá)到了16258行，welldatamanager 17055行，類使用起來倒是很方便，要數(shù)據(jù)相關(guān)的東西，你只要找welldatamanager就好了，然后你就在幾萬行的代碼中徘徊吧。其他的代碼重復(fù)、過度依賴等等問題就更多了。
3、黑盒測試力度不夠。七八個(gè)人編碼，兩個(gè)人進(jìn)行測試。并且隨著時(shí)間長了，固定的兩個(gè)人對(duì)軟件產(chǎn)生了習(xí)慣性，導(dǎo)致很多地方測試不到。
4、沒有規(guī)范的軟件開發(fā)流程。軟件設(shè)計(jì)、測試用例編寫
5、測試時(shí)間不足，軟件發(fā)布前一周還在進(jìn)行軟件功能的開發(fā)。
6、需求不穩(wěn)定。需求反復(fù)修改帶來的問題。比如繪制刻度的時(shí)候，現(xiàn)實(shí)垂直畫、后來水平畫、再后來還是垂直畫