當乙個程式設計師寫完**以後，（這樣說其實很空泛，怎樣規模的**呢，暫且認為是乙個將要交付的系統功能的**），並初步測試通過後不要急於提交，應該先自己
review
一遍，其目的在於檢查**中能夠通過肉眼而非
debug
就可以發現的問題。比如：
l定義的變數是不是都用上了，定義了但沒有使用的變數顯然影響其他人的閱讀。更為嚴重是自己定義的區域性變數是不是和某些全域性變數同名，如果存在可能使得整個系統出現莫名其妙的問題，而且很難跟蹤到。
l注釋是不是都完整了。如果說在程式設計期間為了一氣呵成而沒有詳細注釋的話，這個時候應該補上了，我想其意義大家一定都很清楚了吧。特別的，許多人（包括我自己在內），經常為了省事而將現成的**直接拷貝過來稍加修改就大功告成。就在內心喜悅的同時卻忽略了乙個小小的細節就是原來的注釋沒有改掉。結果拐過頭來
review
的時候卻發現摸不著頭腦，這都那跟那阿。為了防止被同事甚至領導取笑，相信我，這個時候就好好檢查一下吧。
l該釋放的資源是不是還駐留在記憶體中。這一點對c、
vc程式設計師尤為重要，導致的後果也無需多說，盡量在造成系統崩潰前就解決掉吧。
……上述的這些都是些雞毛蒜皮，花不了多少時間也不會立刻引起使用者的注意，關鍵在於功能邏輯是否正確，這個並非靜態跟蹤所能實現的，程式設計師也很難懷疑自己犯了怎樣的錯誤。其實把詳細設計說明書或者需求分析書（如果兩樣都沒有，呵呵，反正從頭到尾都是在裸奔，還有啥好害怕的），拿出來逐項對照著在執行起來的程式上
check
一遍，就足以發現絕大部分問題了。但是這個時候，由於每個人的關注點不一樣，解決問題的方式也不一樣，所以檢查的粗細程度也不相同，該怎麼辦呢。最好是有個書面的東西，這就是所謂的測試列表（
check list
）。大概的形式應該如下：
機能名稱：
xx製作人：
xx最終完成日期：
***x-xx-xx
大專案中專案小專案
測試概要
負責人check
日期xx窗體(
頁面)的**檔案
xx 有
/無
xx窗體(頁面
)的sql指令碼檔案
xx 有
/無
xx窗體(頁面
)的dll檔案
xx 有
/無
xx窗體(頁面
) xx
子窗體(
子頁面)
功能xx(如
xx明細的計算
)
原始明晰資料
***，計算的結果
***，所用公式或方法
… ………
程式設計師最後往往需要提交許多內容，如源**檔案，使用的
sql指令碼檔案以及其他指令碼檔案（視具體情況），編譯生成的
dll檔案、
exe檔案等，稍不注意就會遺留什麼，因此就在這張測試列表的開頭全部列出來，回頭提交時作為條目清單。
bug修改掉之後再繼續。
當測試列表全部完成後，應將源**連同該測試列表一同交給上級的負責人，上級負責人會對照著測試列表做一次
review
。實際上，正是有了這張測試列表，上級
review
的時候才有的放矢，將其負擔減輕了不少。最終到測試人員甚至客戶那裡，潛在的
bug已經少了很多，除非需求本身也有問題。
也許有人會問，現在各個公司都在使用各種**檢查工具、管理工具，甚至還遵循怎樣的標準規範，誰還會用這樣土的辦法啊。然而，**管理工具並不能幫你
debug
出邏輯上的錯誤，**檢查工具也不可能智慧型到將相互關聯的邏輯中存在的錯誤一一羅列出來，實際許多情況下程式設計師可能並不會也不願意花時間去編寫那些測試指令碼。而那些標準規範呢，呵呵，它阻止不了人們偷懶，而且如果都能夠製作出乙份完整詳細的測試列表不也是在遵循一種規範嗎。
程式設計師如何減少BUG
最近乙個專案出了大量的bug，很是慚愧，有沒有可以盡量規避bug的良方呢？可能沒有，但總有儘量減少bug出現機率的方 吧 我個人覺得在企業應用開發中，bug大致可以分為如下三類 一 程式本身語義上的bug。執行時bug。比如np之類的。二 需求理解方面的差異導致的bug。簡單說，就是程式本身語義沒有...
程式設計師之路 Linux幫助命令
幫助命令man manual指南 1 獲取指定命令的幫助 man 命令 例如 man ls 檢視ls的幫助 2 檢視命令擁有哪幾個級別的幫助 man f 命令 相當於whatis 命令 例如 man 5 passwd man 4 null man 8 ifconfig 3 檢視和命令相關的所有幫助 ...
程式設計師怎樣減少心理壓力
一是不要故意給自己加壓。不少人對社會對家庭對自己都有不同程度的不滿，她們中有些人喜歡在壓力中生活，在壓力中挑戰難題，便有一種愜意的滿足。但不是每次都有好運氣，壓力多了會壓得自己喘不過氣來，久而久之會禍及自己的身心健康。二是以獨特的方式適應社會，每個人都有每個人的活法，你走你的陽光道，我過我的立交橋，...