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

2021-08-23 11:16:48 字數 1991 閱讀 5743

作者****:李先靜

**閱讀法

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

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

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

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

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

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

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

o檢查常見錯誤。

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

o模擬計算機執行。

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

o假想講給朋友聽。

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

歡迎到linux mobile development上交流

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

作者 李先靜 閱讀法 軟體工程實踐已經證明code review是提高 質量最有效的手段之一,極限程式設計 xp 更是把code review推向極致,形成著名的結對程式設計工作方式,兩個程式設計師在一台電腦前面工作,乙個人編寫程式,另乙個review輸入每一行 寫程式人的專注 於目前細節上的工作,...

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

作者 李先靜 閱讀法 軟體工程實踐已經證明code review是提高 質量最有效的手段之一,極限程式設計 xp 更是把code review推向極致,形成著名的結對程式設計工作方式,兩個程式設計師在一台電腦前面工作,乙個人編寫程式,另乙個review輸入每一行 寫程式人的專注 於目前細節上的工作,...

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

作者 李先靜 1.好與快的關係 幾年前和乙個朋友聊天時,他抱怨他的上司說,要我寫得好又要寫快,那怎麼可能呢?我當時一愣,反問到,寫不好怎麼可能寫得快?他也一愣。傳統觀點認為在功能 成本 人 時間 和質量這個鐵三角中,提高質量就意味投入更多成本或者減少一些功能。在功能不變的情況下,不可能在提高質量的同...