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