系統程式設計師成長計畫寫得又快又好的秘訣三

**閱讀法

軟體工程實踐已經證明code review是提高**質量最有效的手段之一，極限程式設計(xp)更是把code review推向極致，形成著名的結對程式設計工作方式，兩個程式設計師在一台電腦前面工作，乙個人編寫程式，另乙個review輸入每一行**，寫程式人的專注於目前細節上的工作，review的人同時要從高層次考慮如何改進**質量，兩個人的角色會經常互換。

可惜我即沒有結對程式設計的經驗，也沒有在cmm3(及以上)團隊中工作過。不過現在我要介紹比結對程式設計更敏捷更輕量級，但是同樣有效的review方法。這種方法不需要其他程式設計師配合，有你自己就夠了。為了把這種方法與傳統的code review區分開來，我把它稱為**閱讀法吧。

很多初學者包括一些有經驗的程式設計師，在敲完**的最後乙個字元後，馬上開始編譯和執行，迫不急待的想看到自己的工作成果。快速反饋有助於滿足自己的成就感，但是同時也會帶來一些問題：

讓編譯器幫你檢查語法錯誤可以省些時間，但程式設計師往往太專注這些錯誤了，以為改完這些錯誤就萬事大吉了。其實不然，很多錯誤編譯器是發現不了的，像記憶體錯誤和執行緒死鎖等等，這些錯誤可能逃過簡單的測試而遺留在**中，直到整合測試或者軟體發布之後才暴露出來，那時就要花更大代價去修改它們了。

修改完編譯錯誤之後就是執行程式了，執行起來有錯誤，就輪到偵錯程式上場了。花了不少時間去除錯，發現無非是些低階錯誤，或許你會自責自己粗心大意，但是下次可能還是犯同樣的錯誤。更嚴重的是這種debug & fix的方法，往往是頭痛醫頭腳痛醫腳，導致低質量的軟體。

讓編譯器幫你檢查語法錯誤，讓偵錯程式幫你查bug，這是天經地義的事，但這確實是又慢又爛的方法。就像你要到離家東邊1000公尺的地方開會，結果你往西邊走，又是坐車又是搭飛機，花了一周時間，也繞著地球轉了一周，終於到了會議室，你還大發感慨說，現代的交通工具真是發達啊。其實你往東走，走路也只要十多分鐘就到了。不管你的除錯技巧有多高，都不如一次性寫好更高效。

我以前也一樣，想趕時間結果花了更多時間，在經過很多痛苦的經歷之後，我開始學會放鬆自己，讓自己慢下來。寫完程式之後，我會花些時間去閱讀它，一遍兩遍甚至多遍之後，才開始編譯它，只要有時間，在通過測試之後，我還會閱讀它們，每讀一遍都有不同的收穫，有時候會發現一些錯誤，有時候會做些改進，有時候也有新的想法。

o檢查常見錯誤。

第一遍閱讀時主要關注語法錯誤、**排版和命名規則等等問題，只要看不順眼就修改它們。讀完之後，你的**很少有低階錯誤，看起來也比較乾淨清爽。第二遍重點關注常見程式設計錯誤，比如記憶體洩露和可能的越界訪問，變數沒有初始化，函式忘記返回值等等，在後面的章節中，我會介紹這些常見錯誤，避免這些錯誤可以為你省大量的時間。如果有時間，在測試完成之後，還可以考慮是否有更好的實現方法，甚至嘗試重新去實現它們。說了讀者可能不相信，在學習程式設計的前幾年，我經常重寫整個模組，只我覺得能做得更好，能驗證我的一些想法，或提高我的程式設計能力，即使連續幾天加班到晚上十一點，我也要重寫它們。

o模擬計算機執行。

常見錯誤是比較死的東西，按照檢查列表一條一條的做就行了。有些邏輯通常不是這麼直觀的，這時可以自己模擬計算機去執行，假想你自己是計算機，讀入這些**時你會怎麼處理。這種方法能有效的完善我們的思路，考慮不同的輸入資料，各種邊界值，這能幫助我們想到一些沒有處理的情況，讓程式的邏輯更嚴謹。

o假想講給朋友聽。

據說在code review時發現錯誤的，往往不是review的人而是程式設計師自己。我也有很多這樣的經歷，在講給別人聽的時候，別人還沒有聽明白，自己已經發現裡面存在的錯誤了。上大學時，我常常把寫的或者學到的東西講給隔壁寢室的乙個同學聽，他說他從我這裡學到很多知識，其實我從講的過程中，經常發現一些問題，對提高自己的能力大有幫助。可惜並不是隨時都能找到好的聽眾，幸好我們有另外乙個替代辦法，記得剛開始寫程式時看過一本書(忘記名字了)，作者說他在寫程式時，常常把思路講給他的布娃娃聽。我沒有布娃娃當聽眾，講給滑鼠聽總是有點怪怪的，所以就假想旁邊有個朋友，我把自己的思路講給他聽，同時也假想他來質疑我。這種方法很效，能夠讓自己的思路更清晰，據說一些大師也經常使用這種方法。

系統程式設計師成長計畫 寫得又快又好的秘訣 三

系統程式設計師成長計畫 寫得又快又好的秘訣 三

系統程式設計師成長計畫 寫得又快又好的秘訣 三

系統程式設計師成長計畫 寫得又快又好的秘訣 二

相關推薦

系統程式設計師成長計畫寫得又快又好的秘訣三

系統程式設計師成長計畫寫得又快又好的秘訣三

系統程式設計師成長計畫寫得又快又好的秘訣三

系統程式設計師成長計畫寫得又快又好的秘訣二