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