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