系統程序員成長計劃-寫得又快又好的秘訣(三) Thursday, December 04th, 2008 | Author: admin 轉載時請注明出處和作者聯系方式 文章出處:http://www.limodev.cn/blog 作者聯系方式:李先靜 代碼閱讀法 軟件工程實踐已經證明Code Review是提高代碼質量最有效的手段之一,極限編程(XP)更是把CodeReview推向極致,形成著名的結對編程工作方式,兩個程序員在一臺電腦前面工作,一個人編寫程序,另一個Review輸入每一行代碼,寫程序人的專注于目前細節上的工作,Review的人同時要從高層次考慮如何改進代碼質量,兩個人的角色會經;Q。 可惜我即沒有結對編程的經驗,也沒有在CMM3(及以上)團隊中工作過。不過現在我要介紹比結對編程更敏捷更輕量級,但是同樣有效的Review方法。這種方法不需要其他程序員配合,有你自己就夠了。為了把這種方法與傳統的Code Review區分開來,我把它稱為代碼閱讀法吧。 很多初學者包括一些有經驗的程序員,在敲完代碼的最后一個字符后,馬上開始編譯和運行,迫不急待的想看到自己的工作成果。快速反饋有助于滿足自己的成就感,但是同時也會帶來一些問題: 讓編譯器幫你檢查語法錯誤可以省些時間,但程序員往往太專注這些錯誤了,以為改完這些錯誤就萬事大吉了。其實不然,很多錯誤編譯器是發現不了的,像內存錯誤和線程死鎖等等,這些錯誤可能逃過簡單的測試而遺留在代碼中,直到集成測試或者軟件發布之后才暴露出來,那時就要花更大代價去修改它們了。 修改完編譯錯誤之后就是運行程序了,運行起來有錯誤,就輪到調試器上場了。花了不少時間去調試,發現無非是些低級錯誤,或許你會自責自己粗心大意,但是下次可能還是犯同樣的錯誤。更嚴重的是這種debug & fix的方法,往往是頭痛醫頭腳痛醫腳,導致低質量的軟件。 讓編譯器幫你檢查語法錯誤,讓調試器幫你查BUG,這是天經地義的事,但這確實是又慢又爛的方法。就像你要到離家東邊1000米的地方開會,結果你往西邊走,又是坐車又是搭飛機,花了一周時間,也繞著地球轉了一周,終于到了會議室,你還大發感慨說,現代的交通工具真是發達啊。其實你往東走,走路也只要十多分鐘就到了。不管你的調試技巧有多高,都不如一次性寫好更高效。 我以前也一樣,想趕時間結果花了更多時間,在經過很多痛苦的經歷之后,我開始學會放松自己,讓自己慢下來。寫完程序之后,我會花些時間去閱讀它,一遍兩遍甚至多遍之后,才開始編譯它,只要有時間,在通過測試之后,我還會閱讀它們,每讀一遍都有不同的收獲,有時候會發現一些錯誤,有時候會做些改進,有時候也有新的想法。 下面是我在閱讀自己代碼時的一些方法: o檢查常見錯誤。 第一遍閱讀時主要關注語法錯誤、代碼排版和命名規則等等問題,只要看不順眼就修改它們。讀完之后,你的代碼很少有低級錯誤,看起來也比較干凈清爽。第二遍重點關注常見編程錯誤,比如內存泄露和可能的越界訪問,變量沒有初始化,函數忘記返回值等等,在后面的章節中,我會介紹這些常見錯誤,避免這些錯誤可以為你省大量的時間。如果有時間,在測試完成之后,還可以考慮是否有更好的實現方法,甚至嘗試重新去實現它們。說了讀者可能不相信,在學習編程的前幾年,我經常重寫整個模塊,只我覺得能做得更好,能驗證我的一些想法,或提高我的編程能力,即使連續幾天加班到晚上十一點,我也要重寫它們。 o模擬計算機執行。 常見錯誤是比較死的東西,按照檢查列表一條一條的做就行了。有些邏輯通常不是這么直觀的,這時可以自己模擬計算機去執行,假想你自己是計算機,讀入這些代碼時你會怎么處理。這種方法能有效的完善我們的思路,考慮不同的輸入數據,各種邊界值,這能幫助我們想到一些沒有處理的情況,讓程序的邏輯更嚴謹。 o假想講給朋友聽。 據說在CodeReview時發現錯誤的,往往不是Review的人而是程序員自己。我也有很多這樣的經歷,在講給別人聽的時候,別人還沒有聽明白,自己已經發現里面存在的錯誤了。上大學時,我常常把寫的或者學到的東西講給隔壁寢室的一個同學聽,他說他從我這里學到很多知識,其實我從講的過程中,經常發現一些問題,對提高自己的能力大有幫助?上Р⒉皇请S時都能找到好的聽眾,幸好我們有另外一個替代辦法,記得剛開始寫程序時看過一本書(忘記名字了),作者說他在寫程序時,常常把思路講給他的布娃娃聽。我沒有布娃娃當聽眾,講給鼠標聽總是有點怪怪的,所以就假想旁邊有個朋友,我把自己的思路講給他聽,同時也假想他來質疑我。這種方法很效,能夠讓自己的思路更清晰,據說一些大師也經常使用這種方法。 這種代碼閱讀法會花你一些時間,但是可以省下更多調試時間,而且能夠提高代碼質量,可以說是名符其實的“又快又好的” 秘訣之一。至于讀幾遍合適,要根據情況而定,個人覺得讀兩到三遍是最佳的投資。 |
理論上如此,但是,很多問題,必須摸索才能發現。 俺現在的顯卡代碼不超過1000行,調試了幾個月,就是有些問題不太清楚, 只能不斷的實驗和摸索。關鍵點就是幾個數字。 |
lz說的這種代碼是需求及其明確,軟件工具沒有bug,對編程環境及其熟悉的情況。 也就是說,軟件工人級別的問題。 |
有幾個人不是工人級別? 老王很自信的說. |
純軟件的可以這樣,嵌入式軟件一定得調試,因為對硬件的理解有可能出現偏差。 |
多寫寫,就快了~~~~沒辦法的辦法 |
多寫,深度鉆研基礎功能模塊的原理,確保每個基礎模塊的穩定可靠,積累到一定程度就可以不斷的復用,包括基礎架構等等。尤其是在一個公司,做某個特定行業的開發,通常有很強的繼承性,積累3年之后,每個新項目實際需要的工作量其實只是有限的一小部分而已——到時候自然就“又好又快”了。 |
說的有理,溫故而知新嘛! |
“溫故知新”,要有足夠的耐性去溫...... |
冰凍三尺非一日之寒,為山九仞非一日之功,路很長啊 |
具體環境具體對待吧 |