我坐在球面顯示器前，旁邊是半杯喝剩的咖啡和散發著噪音的塞揚
366卡匣式
cpu，此時是凌晨兩點，我聚精會神地用
jcreator
除錯乙個紙牌遊戲，最後乙個
bug終於排除了，我伸了個懶腰。**休息前我突然想到乙個有趣的問題，如果我運氣不好輸給了電腦，應該經過一點小小的刺激後再重新開始：當漂亮的藝術字「
game over
」消失後會出現乙個可惡的白色桌球，它在
800×
600的古老螢幕中來回亂竄，碰到牆壁後快速**，我需要用滑鼠準確地點中它才可以開始新一輪遊戲。重新畫圖計算公式……當我實現這個功能時已經是次日中午。
那是五年前的一天，當時我還在大學學習，第一次接觸到物件導向並樂在其中。
不久前的乙個週末，我坐在寬敞的辦公室，雙眼發直地看著
thinkpad
中標註了紅燈的進度列表。「a
要完蛋了，三天時間對他來說太少了。」「b
要完蛋了，憑他乙個人完成這個功能至少要五個月。」「c
更要完蛋了，等他做出這個功能就得下輩子見了。」
……以上只是乙個小小的故事，我幾乎忘了講這個故事的初衷。但是進入正題前我還要再講乙個。
在我職業生涯的開始，開發人員遞交給我一些
excel
**，我的任務是將這些**中的資料分類整理，重新美化
excel
的樣式。這並不是個輕鬆的工作，**中充斥著大量雜亂無章的字型，各種型別的資料被混雜在一起，
excel
複雜的特性被亂用了一遍又一遍……就這樣耗去了我
21天，最後換來的僅僅是一聲謝謝。這個場景我們是不是似曾相識？就發生在閱讀別人**的時候。
東方有線單據影像專案暫時告一段落，按照慣例，我將做乙個簡要的回顧。
似乎很久以前就開始著手準備這個專案，專案評審早在08年
11月就已經通過，但是由於客戶和我們都在忙於發票審核模組，這個專案暫時被遺忘在角落。
牛年伊始，我們終於見到了盼望已久的需求文件。讓人鬱悶的是，短短十幾頁的文件中有五頁以上的八股文，可以提取的有效資訊極少，我們要做的是為空中樓閣搭建一些地基。值得一提的是，這個專案分為
c/s採集和
b/s展現兩部分，在我主要負責的
b/s部分一籌莫展時，
c/s已經接近尾聲，提交客戶正式試用。
正像開發人員的不良傳統一樣，我對需求文件向來缺乏重視，於是這個空中樓閣一直懸在半空，每次開會都是無疾而終，其他開發人員似乎比我還不善於閱讀文件，匱乏的想象力讓我們畫不出有效的介面圖例。
就這樣一瘸一拐地走了大約兩周，這段時間每個人都極其懶散，理由也似乎很充分：這種文件怎麼做？需求是需要不斷完善的，遺憾的是我們並沒有意識到這一點。直到有一天，忍耐許久以至近乎發瘋的測試人員終於集中火力向我開炮，他們抱怨文件的東西太少，無法有效寫出測試用例……我這才意識到我們做的簡直差到了極點。既然知道了自己的無知就要勇於改正，我自問不缺少這份勇氣，於是我用了大約一周時間細化需求文件，在這個過程中加深了對問題的理解，也發現了一些與
c/s部分存在的焊接點問題，這些問題被轉換成列表一一記錄在案。
上個專案中我們在需求文件上吃了大虧，大量的需求變更碎片無人整理，我們甚至無法有效確定客戶新發的變更是否是需求反覆。單據影像專案中，我們計畫將需求以版本號的形式公升級，保留以前的版本以便隨時對照，實際上我們正是這麼做的。
有了細化的文件，我們終於打下了第一根地基，由於
b/s部分功能相對簡單，設計部分耗時較少。
很快迎來了編碼工作，大量的問題也在這時集中暴露出來。
先來看一下**統計結果：
1w行左右的**說明這僅僅是個小模組，如果去掉我加入的部分單元測試**，總數將更少。與之相對的是乙份缺陷統計圖：
嚴重性高的
bug佔了總數的
41.56%
，這是個極其丟臉的統計結果。
我和測試人員的對話多少可以反應這個結果：
「以前沒做過軟體嗎？」
「當然做過。」
「提交測試組前做了測試嗎？」
「做了，但是顯然還不太充分。」
「為什麼會出現這樣的結果？」
「……（天曉得）」
我自信自己的**做了足夠的測試，即使出現一些問題我也仍然較為自信，其他人呢？連續四版冒煙測試不通過令我極為惱火，大家似乎懶於為自己的**做測試，或者說並未掌握測試的基本技術，這對於軟體質量或許是致命的，因為我看到了大量由於缺少校驗而引起的異常，我過濾的其中的大部分，發布版本時仍不免有漏網之魚。我將幾個主要問題總結如下：
1.缺少文字域長度校驗導致的異常（為什麼這種錯誤百般強調仍一再發生？）；
2.正規表示式導致的校驗錯誤（有一次我發現了乙個奇怪的錯誤，剖開**發現其中的正規表示式根本不貼邊？是何種力量驅使這名程式設計師寫出了它？）；
3.sql
語句不熟練導致的異常（不對
sql語句有一定的了解是做不了企業級應用的，基礎中的基礎）；
4.基礎不紮實導致的錯誤；
5.缺少問題轉換的方法，人為導致問題複雜化從而引起不易修復的錯誤；
6.缺乏自測導致的錯誤（尤為嚴重的一點）。
我們也不幸遇到了技術風險：乙個預覽功能需要呼叫
webservice
介面，這段**在
tomcat
和weblogic10
上可以順利執行，但是客戶不巧用到了
weblogic9.2
。負責此功能的程式設計師花了大量時間嘗試不同的方法，依然沒有結果。當我們得到正確結果時又發現修改的範圍大到了需要修改整個系統。由於其他人也需要呼叫這段程式，於是測試人員不斷地崔問，我每次都試圖轉移話題。這是個黑洞問題，沒法**解決問題的時間，或許有一天我們靈感突發解決了它，但是無法**這一天發生在什麼時候。最後，我們改變了設計方案，用古老的共享目錄方式暫時解決了這個問題。
版本發布計是重中之重，能否按時並有效地發布直接反應了計畫的合理性和程式完成情況。上個專案的版本控制極為混亂，很幸運我們即時吸取了教訓（仍然感謝測試組的提醒，否則我一無是處）。從
v0.02
版開始我編寫了詳細的版本計畫並即時予以更改，在文件中註明了每個版本對應的需求、設計、增加的功能、修正的
bug等。這份計畫讓我對進度有了更好的把握。下圖是版本發布統計：
bug的遞增是可以預見的，隨著功能的增加逐漸遞增，在所有功能基本完成時逐漸遞減，從
v0.07
開始主要修改
bug。重新開啟的
bug大幅度減少，較之上個專案有了大幅度提高，下圖是重新開啟缺陷統計：
單據模組終於可以提交客戶試用，我們可以稍微松一口氣。這個專案中有提高也有不足，也讓我第一次認真思考自己適合做軟體，再次感謝測試組對我的幫助。
最後，我想以一句看了三年但仍未真正理解的話結尾：「軟體是一種態度」。
影像系統價值之我見
最近專案比較多，一直沒有更新部落格，今天抽空寫下最近在上海參加共享服務峰會時回答來賓提問的乙個問題。這個問題我在電信集團參加集體規範討論時也再次遇到。問題很簡單，就是上影像系統到底有沒有價值。有客戶曾經徵集過一些答案，但並沒有使他滿意。這些 括 1 使領導能夠在電子審批的同時見到影像。事實上很多企業...
流量系統專案總結
這兩周技術部安排我開發公司的流量系統，從拿到需求直到完成整個過程，才明白開發系統的定義是什麼，具體來說分為一下幾部分 第一 技術上 拿到需求後我的第一件事就是要確定整個系統開發的過程中難點在什麼地方，經過自己的思索以及技術主管陳從雲的指點，那就是演算法比較複雜，我想這個應該是 沒有什麼問題 基本上把...
答題系統專案總結
背景 最近這一段日子，絕大部分時間花在乙個答題系統上，專案預期是利用掃瞄器獲取到試卷的資料，隨後對資料進行處理以及匹配規則，最終算出該題目的正確答案。目前系統已經開發到第二版本，現在還僅僅是乙個簡易型的demo，但是其中涉及到一部分坑以及在工作的時候發現的一些問題，鑑於此，使用文字記錄下來，為以後成...