作者****：李先靜
**閱讀法
軟體工程實踐已經證明code review是提高**質量最有效的手段之一，極限程式設計(xp)更是把code review推向極致，形成著名的結對程式設計工作方式，兩個程式設計師在一台電腦前面工作，乙個人編寫程式，另乙個review輸入每一行**，寫程式人的專注 於目前細節上的工作，review的人同時要從高層次考慮如何改進**質量，兩個人的角色會經常互換。
可惜我即沒有結對程式設計的經驗，也沒有在cmm3(及以上)團隊中工作過。不過現在我要介紹比結對程式設計更敏捷更輕量級，但是同樣有效的review方 法。這種方法不需要其他程式設計師配合，有你自己就夠了。為了把這種方法與傳統的code review區分開來，我把它稱為**閱讀法吧。
很多初學者包括一些有經驗的程式設計師，在敲完**的最後乙個字元後，馬上開始編譯和執行，迫不急待的想看到自己的工作成果。快速反饋有助於滿足自己的成就感，但是同時也會帶來一些問題：
讓編譯器幫你檢查語法錯誤可以省些時間，但程式設計師往往太專注這些錯誤了，以為改完這些錯誤就萬事大吉了。其實不然，很多錯誤編譯器是發現不了的，像 記憶體錯誤和執行緒死鎖等等，這些錯誤可能逃過簡單的測試而遺留在**中，直到整合測試或者軟體發布之後才暴露出來，那時就要花更大代價去修改它們了。
修改完編譯錯誤之後就是執行程式了，執行起來有錯誤，就輪到偵錯程式上場了。花了不少時間去除錯，發現無非是些低階錯誤，或許你會自責自己粗心大意， 但是下次可能還是犯同樣的錯誤。更嚴重的是這種debug & fix的方法，往往是頭痛醫頭腳痛醫腳，導致低質量的軟體。
讓編譯器幫你檢查語法錯誤，讓偵錯程式幫你查bug，這是天經地義的事，但這確實是又慢又爛的方法。就像你要到離家東邊1000公尺的地方開會，結果你 往西邊走，又是坐車又是搭飛機，花了一周時間，也繞著地球轉了一周，終於到了會議室，你還大發感慨說，現代的交通工具真是發達啊。其實你往東走，走路也只 要十多分鐘就到了。不管你的除錯技巧有多高，都不如一次性寫好更高效。
我以前也一樣，想趕時間結果花了更多時間，在經過很多痛苦的經歷之後，我開始學會放鬆自己，讓自己慢下來。寫完程式之後，我會花些時間去閱讀它，一 遍兩遍甚至多遍之後，才開始編譯它，只要有時間，在通過測試之後，我還會閱讀它們，每讀一遍都有不同的收穫，有時候會發現一些錯誤，有時候會做些改進，有 時候也有新的想法。
o檢查常見錯誤。
第一遍閱讀時主要關注語法錯誤、**排版和命名規則等等問題，只要看不順眼就修改它們。讀完之後，你的**很少有低階錯誤，看起來也比較乾淨清爽。 第二遍重點關注常見程式設計錯誤，比如記憶體洩露和可能的越界訪問，變數沒有初始化，函式忘記返回值等等，在後面的章節中，我會介紹這些常見錯誤，避免這些錯誤 可以為你省大量的時間。如果有時間，在測試完成之後，還可以考慮是否有更好的實現方法，甚至嘗試重新去實現它們。說了讀者可能不相信，在學習程式設計的前幾 年，我經常重寫整個模組，只我覺得能做得更好，能驗證我的一些想法，或提高我的程式設計能力，即使連續幾天加班到晚上十一點，我也要重寫它們。
o模擬計算機執行。
常見錯誤是比較死的東西，按照檢查列表一條一條的做就行了。有些邏輯通常不是這麼直觀的，這時可以自己模擬計算機去執行，假想你自己是計算機，讀入 這些**時你會怎麼處理。這種方法能有效的完善我們的思路，考慮不同的輸入資料，各種邊界值，這能幫助我們想到一些沒有處理的情況，讓程式的邏輯更嚴謹。
o假想講給朋友聽。
據說在code review時發現錯誤的，往往不是review的人而是程式設計師自己。我也有很多這樣的經歷，在講給別人聽的時候，別人還沒有聽明白，自己已經發現裡面存 在的錯誤了。上大學時，我常常把寫的或者學到的東西講給隔壁寢室的乙個同學聽，他說他從我這裡學到很多知識，其實我從講的過程中，經常發現一些問題，對提 高自己的能力大有幫助。可惜並不是隨時都能找到好的聽眾，幸好我們有另外乙個替代辦法，記得剛開始寫程式時看過一本書(忘記名字了)，作者說他在寫程式 時，常常把思路講給他的布娃娃聽。我沒有布娃娃當聽眾，講給滑鼠聽總是有點怪怪的，所以就假想旁邊有個朋友，我把自己的思路講給他聽，同時也假想他來質 疑我。這種方法很效，能夠讓自己的思路更清晰，據說一些大師也經常使用這種方法。
這種**閱讀法會花你一些時間，但是可以省下更多除錯時間，而且能夠提高**質量，可以說是名符其實的「又快又好的」 秘訣之一。至於讀幾遍合適，要根據情況而定，個人覺得讀兩到三遍是最佳的投資。
系統程式設計師成長計畫 寫得又快又好的秘訣 三
作者 李先靜 閱讀法 軟體工程實踐已經證明code review是提高 質量最有效的手段之一，極限程式設計 xp 更是把code review推向極致，形成著名的結對程式設計工作方式，兩個程式設計師在一台電腦前面工作，乙個人編寫程式，另乙個review輸入每一行 寫程式人的專注 於目前細節上的工作，...
系統程式設計師成長計畫 寫得又快又好的秘訣 二
作者 李先靜 1.好與快的關係 幾年前和乙個朋友聊天時，他抱怨他的上司說，要我寫得好又要寫快，那怎麼可能呢？我當時一愣，反問到，寫不好怎麼可能寫得快？他也一愣。傳統觀點認為在功能 成本 人 時間 和質量這個鐵三角中，提高質量就意味投入更多成本或者減少一些功能。在功能不變的情況下，不可能在提高質量的同...
系統程式設計師成長計畫 寫得又快又好的秘訣 二
1.好與快的關係 幾年前和乙個朋友聊天時，他抱怨他的上司說，要我寫得好又要寫快，那怎麼可能呢？我當時一愣，反問到，寫不好怎麼可能寫得快？他也一愣。傳統觀點認為在功能 成本 人 時間 和質量這個鐵三角中，提高質量就意味投入更多成本或者減少一些功能。在功能不變的情況下，不可能在提高質量的同時降低開成成本...