2004年4月下旬，項目後期人員進入開發現場，參加軟件項目的收尾工作。從合作雙方來說，要達到客戶滿意的要求，這是一個必經的階段。而對於項目人員是一種難得的機會，但同時也是一種艱苦的考驗。（背景省略100字。）
B票就是記錄BUG的文檔，既作爲過程文檔，又作爲結果文檔。從技術上說，是修正程序的依據；從管理上說，是計算工時的依據。當然，B票不是唯一的參考資料，但是它非常重要。
一個月時間除休息日，共投入工作日25天，其中通霄5個，修改B票29個，總修改代碼行約2500。因爲BUG是隨機出現的，所以對每日的工作範圍不易掌握，一度比較疲勞，遇到休息日一般12點起牀，不過還好，客戶對編程質量比較滿意，爲引出觀點，不妨回憶一下修改的幾個BUG。
在不做選擇的情況下，列舉幾個編號，作一下基本的分析。
Bug No.1:
簡介：一個數據表信息的編輯畫面，用戶可以在數個輸入框中填寫數據，也可以從已有的數據中通過點擊按鈕取到一些現有的數據再稍做修改，按鈕旁邊有一個下拉框，用於選擇要拷貝的源數據名稱。
錯誤：下拉框中的文字包含單引號時，點擊按鈕出現系統錯誤。
過程：首先再現此錯誤，發現並非單引號的問題，但是會有偶然的時候出現錯誤。這個問題困擾了兩、三個小時，終於發現只要連續點兩次按鈕就出現錯誤。
分析：這個錯誤值得總結的地方在於測試的目的不在於證明程序正確，而在於發現錯誤，而我們側重於前者，對自己的程序不做過多的嚴格測試，或者說不願意破壞性的測試。從編碼上來看，註釋不太夠，但是邏輯清晰，版面整齊，兩次對DB的寫入用重複的主鍵(畫面未遷移，使用上一次得到的ID)，造成BUG，僅僅反映了經驗的不足，所以類似的錯誤在以後的項目中完全可以避免。
Bug No.2:
錯誤：HTML畫面應該是2行2列，結果是第一行是3列，第二行是2列。
分析：這樣的BUG對於修改人員是很省事的，但仔細想想也是可以避免的，只要編程者知道最後的結果應該是什麼，並且往瀏覽器上一放看一遍就可以避免了。
Bug No.3:
簡介：畫面1對應一個數據表的一條記錄，上有一個按鈕，對應打開與這條記錄關聯的多條記錄。一條記錄與關聯記錄的最新更新日期有前有後，要求分別比較並提示。
錯誤：編碼漏掉了此項內容。
分析：編碼期間可能花1個小時，這時卻用了5.5個小時，結果是修改文件3個，代碼23行。這種問題需要在瀏覽代碼時檢查出來。
Bug No.4:
簡介：設計書漏掉的功能。
分析：這種BUG考驗代碼的可維護性，經閱讀源碼，因爲註釋不夠，多花了不少時間DEBUG和分析源碼。因爲大規模開發階段已經過去，僅有幾個人留在後期維護，必然接觸到其他人完成的代碼。源碼註釋量不夠，好在層次較爲清晰，而且需要增加的部分正好在一個方法內，這樣其影響範圍可以清楚的表現。增加這部分功能時，又寫了數個小方法，然後在調用處增加兩三行即可。這說明多寫小方法是有利於程序維護的。但要注意，一定要定義常量和規範的註釋，利於再次的修改完善。所以要編寫可維護性強的代碼。
上面的BUG只反映了一小部分和編碼有關的信息，從實際的情況看，可以在編碼期間避免的錯誤佔10%左右，有很大的提高空間。
如何對待BUG？最簡單的想法就是找到問題所在，查看其影響範圍，修改完成。但項目裏是如何對待的呢？如果該問題很通用，則調查所有具有相同特徵的業務，列舉出來。然後逐個對照，統一處理。這個問題其實我注意到了，但這些工作是否要做，首先要看這個BUG消除了沒有，確保任務之進展，其次只能做到列舉部分相關的共性提出可能的影響，而不會一板一眼的畫出一張彙總表，這恐怕正是值得虛心學習的地方。