程式的成長過程

程式如何才叫做好了

原創文章，如有轉載，請註明出處：http://blog.csdn.net/yihui823/article/details/6737757

我們總是在加班，在加班。總是在提交測試後發現自己的程式是那麼多BUG，總是在交貨前一天發現好多問題。在領導問我們，程式做的怎麼樣的時候，我們是怎麼回答的？做好了。是的，做好了。可是結果呢。

從程式員的角度，程式做好了的定義，和測試人員的角度定義的“做好了”，還是有很大差距了。那麼，我們的程式，到底如何才能算“做好了”呢?我覺得，這裡是有一個流程的：

1        開發人員做好了。

這個階段，只是程式員自己把程式調通了。一般的項目，都會有架構，都會有與其他系統的介面，都會有一些硬體模擬器。開發人員只是在自己的一小塊功能裡實現好了。例如，A程式員只是開發一個登入功能，B程式員開發的只是對話功能。那麼B程式員說的做好了，一定是類比登入成功的情況，或者是他的程式不需要登入就能用，或者是他已經把登入資訊寫死了，或者其他的什麼。

這個階段的代碼，精簡有效，基本沒什麼錯誤處理。

2        小組聯調。

聯調是一個很重要的步驟。任何多人開發的工程，聯調的時候都會出這樣那樣的問題。聯調通過，那麼系統的功能才算是流暢了，業務的流程才算是可以走通了。例如，B程式員開發的對話功能，一定是登入過後才能使用。、

在聯調的時候，需要各個程式員耐心細緻的找問題。這個階段，最考驗團隊合作能力。一個到處推卸責任的人，會影響大家計程車氣；到處都是推卸責任的人，則這個團隊會陷入扯皮的境地。

這個階段的代碼，一不小心會就陷入高耦合的杯具中。所以要及時調整代碼架構。

3        與硬體環境調試。

系統多多少少都會與外界有介面，一些是與硬體的介面，一些是與環境的介面。例如登入需要指紋驗證，那麼剛開始調試的時候，可能只是類比了一個指紋驗證裝置，我們按照協議發送一定格式的資料給一個軟體模擬器，然後軟體模擬器再返回一個結果。但是一旦真正把裝置接入到程式，總會出現各種各樣的問額。

這個階段，是項目攻堅階段，需要有精兵強將，人海戰術是不行的。

這個階段的代碼，開始加入許多介面。一定要注意保持良好架構，不要讓程式的耦合度越來越高。

4        可以展示

與硬體環境調試成功後，這個程式就可以拿去展示了。但是在展示前的預示範過程中，會發現各種異常情況，各種沒考慮到的情況。展示可能是給領導看，可能是放在展覽會上，也可能是給客戶示範。不管怎樣，展示之前是需要示範的，那麼展示的內容是可控的。這個時候，可以根據展示的具體情況，做一些應急措施去解決棘手的問題。例如，對話的時候，如果有人發送了”stop”字樣，程式就會退出。這是個BUG，但是不是必須修改的，因為展示的時候記住不要輸入”stop”就行了。

這個版本的代碼，應該是充滿了TODO，到處都是寫死和注釋掉的代碼。

5        測試人員測試。

用來展示的版本，只能作為主線版本的一個分支，大量充斥了臨時方案，這個對系統的進化是有害的。這就像周芷若練九陰真經，以速成的方式，總是會有問題的。主線版本裡，還是需要提交測試人員，經過精心安排的測試case，把程式的各個功能，各個路徑都驗證好。

測試是個反覆的過程，需要幾輪的沉澱。測試出的BUG，也是以一個曲線方式消減下來。也就是說，每天發現的BUG數，是慢慢降下來的過程。你無法用一輪測試就找出所有的問題，有些問題是有相互依賴的，A問題不解決，B問題就根本發現不了。

幾輪測試之後，系統趨於穩定，各個功能都能正常工作，各個商務程序都能走通。這樣系統就算是可以使用了。

經過測試的代碼，有了大量的錯誤處理和容錯機制。一般來說，之前寫的if，在這個階段都會加上寫else之類的。

6        客戶現場調通。

永遠不要指望，測試完美的程式能在客戶現場一遍就安裝成功。客戶現場與開發環境總是有這樣那樣的不同。把我們自認為測試完好的系統，在客戶現場部署、安裝，這是一個曲折的過程。你可能發現，客戶的網路根本不足以承受我們系統的流量，客戶的伺服器不足以運行我們的系統，還有其他各式各樣的問題。

客戶現場調通，需要有很強的交流溝通能力，因為有時候客戶答應做一點點改動，就能節省我們幾個通宵。

代碼開始有壞味道。為了趕快調通，達到客戶想要的結果，代碼開始不遵守編碼規範。架構開始傾斜。所以這個時候一定要注意保持清醒的頭腦，不能越改越亂。

7        客戶驗收

客戶現場調通之後，就交付客戶使用了。不要指望交付使用就大功告成，就可以催著客戶驗收了。客戶驗收之前，在客戶的使用過程中，你會發現我們的系統是多麼脆弱。為什麼客戶會這麼操作，為什麼客戶不按照我們的提示來，為什麼客戶會用這麼不可思議的方式折磨我們的系統？不要問為什麼，是他們花錢讓我們做東西，那麼我們就得讓人家用的舒服，不是嗎？

這裡同樣需要注意，不能完全按照客戶說的來做，我們要挖掘客戶深層次的需求，有時候我們可以給點提議，稍微改動一點他們的想法，可以節省我們很多的工作。例如，客戶需要在對話的過程中，加入一些可以自行配置的表徵圖。我們就需要跟客戶仔細溝通，是否真的需要做到“自行配置”，能不能我們在程式裡給他們配好一些表徵圖，然後告訴他們配置表徵圖的方式。這裡的差別是，“自行配置”就需要做一個配置頁面，而手工配置可能就是告訴他們如何改一個xml檔案而已。

這個時候，看上去系統已經穩定了，但是代碼已經開始走向衰減。除非下定決心重構，否則代碼開始慢慢的臃腫，開始到處都是補丁，開始越改越難改。但是重構一定要在迴歸測試的基礎上，否則很可能帶來新的問題，讓客戶咆哮。

8        成為產品

以上說的，是針對一個客戶的情況。很多時候，跟客戶搞好關係，會讓你減少很多工作量。並且，客戶的需求是單一的，可控的。但是作為產品，那就沒這麼好的事情了。

產品是針對大量客戶的情況。單一客戶，我們還可以引導客戶的使用習慣，但是大量客戶的話，只能產品去湊合客戶的習慣。當然，擁有大量粘性高的使用者，可以去引導客戶的習慣，例如QQ和360。但是成為這種產品之前，最好還是老老實實的去迎合各種客戶的使用習慣。

並且，客戶的操作會更讓你崩潰。知道手機出廠前會做一個什麼測試嗎？就是隨機亂操作上萬次，要保證手機不會死機。這就是說，你根本無法預測客戶會怎麼操作的。不是產品的系統，你可以跟你的客戶說，你這麼操作是不對的，我有操作手冊在此。但是產品呢？如果約束太多，人家就不用你的產品了啊。