• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            那誰(shuí)的技術(shù)博客

            感興趣領(lǐng)域:高性能服務(wù)器編程,存儲(chǔ),算法,Linux內(nèi)核
            隨筆 - 210, 文章 - 0, 評(píng)論 - 1183, 引用 - 0
            數(shù)據(jù)加載中……

            方法與工具

            從最近遇到的幾個(gè)故事說(shuō)起.

            故事一:
            某天晚上和室友聊天,談到使用Vim閱讀代碼,室友也是使用Vim的人,他說(shuō)用類似ctags的查找定位功能不多,更多的時(shí)候,他閱讀一段代碼,要定位一個(gè)功能點(diǎn),首先是從閱讀代碼文件的組織,了解項(xiàng)目的功能等入手,等這些都基本清楚了,定位起來(lái)就會(huì)快很多.我雖然認(rèn)為,ctags實(shí)在是Vim里面一個(gè)很不錯(cuò)的功能,不用這個(gè)實(shí)在可惜,但是他說(shuō)的那套定位思路其實(shí)也是不錯(cuò)的方法.其實(shí)我自己用慣了ctags類的功能之后,閱讀代碼的時(shí)候也會(huì)用惰性,更多的時(shí)候是要靠這些工具來(lái)幫我定位,而不是通過(guò)自己主動(dòng)的思考和分析.

            故事二:
            我的經(jīng)驗(yàn)里面,寫(xiě)完一段代碼之后的第一次編譯,如果編譯器報(bào)錯(cuò)越少,那么可以認(rèn)為這段代碼將來(lái)可能出現(xiàn)bug的幾率越小,簡(jiǎn)而言之,我認(rèn)為代碼的質(zhì)量與第一次編譯的報(bào)錯(cuò)數(shù)量成反比(哦,不用拿helloworld類的程序跟我鉆牛角尖了:).有些人寫(xiě)的代碼,嘩嘩的寫(xiě)了一大段,寫(xiě)之前不考慮好,只想著到時(shí)候?qū)懙牟粚?duì)了可以在編譯由編譯器的報(bào)錯(cuò)來(lái)幫忙找問(wèn)題,這個(gè)思路是不對(duì)的.編譯報(bào)錯(cuò)越少的代碼,說(shuō)明了作者寫(xiě)的時(shí)候思路更清晰一些,考慮的更周全一些,所有的這些流程上的步驟走的都不錯(cuò)了,所以才有最后編譯報(bào)錯(cuò)少的結(jié)果.編譯報(bào)錯(cuò)應(yīng)該是寫(xiě)代碼的結(jié)果之一,而不應(yīng)當(dāng)當(dāng)成了找代碼問(wèn)題的手段,這樣的思路,本末倒置了.

            故事三:
            進(jìn)入新項(xiàng)目組后,組內(nèi)對(duì)代碼編碼的流程有比較嚴(yán)格的要求,包括寫(xiě)一個(gè)API之后需要寫(xiě)一個(gè)針對(duì)這個(gè)API的各種情況的測(cè)試用例,提交代碼的時(shí)候,需要走codereview流程,需要使用cpplint檢驗(yàn)代碼風(fēng)格,需要將對(duì)應(yīng)的測(cè)試用例也提交上去.這一套流程走下來(lái),提交代碼的頻率比之以前,降低了很多,但是不可否認(rèn)的是,也確實(shí)提高了代碼的質(zhì)量.假設(shè)一個(gè)功能,由N個(gè)API構(gòu)成,如果能對(duì)這N個(gè)API都做過(guò)詳細(xì)的測(cè)試,保證它們的輸入和輸出在各種情況下都能符合要求,那么很顯然的,最后這個(gè)功能也應(yīng)該是正確的.反之,越是到了測(cè)試階段需要使用類似gdb這樣的調(diào)試器來(lái)定位問(wèn)題的,會(huì)越讓人不放心---因?yàn)闆](méi)有制度和流程的保證,誰(shuí)也不能說(shuō)將來(lái)可能在哪個(gè)點(diǎn)會(huì)出問(wèn)題.它可以幫你定位問(wèn)題,但是沒(méi)有辦法告訴你已經(jīng)沒(méi)有問(wèn)題了,最后這一點(diǎn),最終還是要通過(guò)嚴(yán)格的單元測(cè)試等流程來(lái)保證的.與第二個(gè)故事相同,我認(rèn)為,在測(cè)試階段使用gdb定位問(wèn)題的次數(shù)也與代碼的質(zhì)量成反比:)

            這幾個(gè)故事綜合起來(lái),想要表達(dá)的是,做一件事情,需要有流程,制度的保證,當(dāng)然也需要工具(比如這幾個(gè)故事里面提到的Vim,gcc,gdb),但是工具就是工具,它只是一種手段,沒(méi)有辦法替代正確的思路,流程和制度等,僅能在整個(gè)過(guò)程中起到輔助的作用.而且,過(guò)分依賴工具,也會(huì)給人以惰性(比如前面提到的使用編譯器編譯代碼來(lái)找錯(cuò),比如使用gdb來(lái)保證功能正確性等).

            所以,更應(yīng)該提倡的是正確的流程,制度,有了這些,項(xiàng)目的質(zhì)量才能有所保證.比如,在寫(xiě)一個(gè)功能點(diǎn)時(shí),需要具體分解為哪幾步,每一步有哪幾個(gè)API,針對(duì)它們的測(cè)試用例有哪些,測(cè)試時(shí)的輸入和輸出有哪些,需要考慮的異常情況有哪些,等等的.這些都考慮清楚了,再動(dòng)手寫(xiě),久而久之,我想這方面的能力會(huì)慢慢的提高.



            posted on 2010-04-15 00:57 那誰(shuí) 閱讀(9417) 評(píng)論(8)  編輯 收藏 引用 所屬分類: 經(jīng)驗(yàn)教訓(xùn)

            評(píng)論

            # re: 方法與工具  回復(fù)  更多評(píng)論   

            謝謝了,確實(shí)說(shuō)的挺在理的。
            2010-04-15 07:48 | uhziel

            # re: 方法與工具  回復(fù)  更多評(píng)論   

            很同意第二條
            2010-04-15 09:37 | zuhd

            # re: 方法與工具  回復(fù)  更多評(píng)論   

            我用VIM 從來(lái)不帶插件
            2010-04-15 10:41 | cui

            # re: 方法與工具[未登錄](méi)  回復(fù)  更多評(píng)論   

            @cui
            你閱讀代碼一個(gè)10W行的代碼也不用ctag那只能說(shuō)明要不你是高手,要不你有傻逼或者裝逼之嫌。。。
            2010-04-15 12:52 | helloworld

            # re: 方法與工具  回復(fù)  更多評(píng)論   

            @helloworld
            呵呵,沒(méi)有說(shuō)不用吧,這里的意思只是強(qiáng)調(diào)方法比工具更重要些.
            2010-04-15 12:54 | 那誰(shuí)

            # re: 方法與工具  回復(fù)  更多評(píng)論   

            看來(lái)是linux的哦!
            2010-04-15 15:53 | 夢(mèng)在天涯

            # re: 方法與工具  回復(fù)  更多評(píng)論   

            我喜歡將程序設(shè)計(jì)成類型敏感的,也就是說(shuō),只要計(jì)算過(guò)程發(fā)生明顯變化,那么其函數(shù)或結(jié)果的類型也會(huì)發(fā)生變化。這個(gè)時(shí)候就可以讓編譯器最大程度來(lái)替我們檢查出忘記修改的地方了。
            2010-04-15 15:54 | 陳梓瀚(vczh)

            # re: 方法與工具  回復(fù)  更多評(píng)論   

            @陳梓瀚(vczh)
            如你這樣目標(biāo)明確的使用工具,倒是很好,我不是反對(duì)使用工具,只是覺(jué)得不應(yīng)該本末倒置,方法比工具重要.
            2010-04-15 18:10 | 那誰(shuí)
            亚洲va久久久噜噜噜久久| 久久久久亚洲?V成人无码| 久久青青草原精品国产| 精品午夜久久福利大片| 久久国产影院| 中文字幕无码精品亚洲资源网久久| 久久精品国产亚洲AV无码娇色 | 久久精品成人欧美大片| 成人久久久观看免费毛片| 久久99精品国产麻豆婷婷| 久久无码人妻一区二区三区 | 日韩人妻无码一区二区三区久久 | 一本色道久久88综合日韩精品| 久久精品国产亚洲AV麻豆网站| 国产精品无码久久综合网| 久久久久久久精品妇女99| 国产精品无码久久综合网| av午夜福利一片免费看久久| 久久伊人色| 麻豆精品久久久一区二区| 精品久久久久久中文字幕大豆网| 久久93精品国产91久久综合| 丰满少妇人妻久久久久久| 综合久久国产九一剧情麻豆| 日日狠狠久久偷偷色综合96蜜桃| 一本久久a久久精品综合夜夜| 亚洲国产欧美国产综合久久| 天天影视色香欲综合久久| 久久人人爽人人爽AV片| 久久久久久狠狠丁香| 97精品伊人久久大香线蕉app | 色综合久久夜色精品国产| 婷婷久久综合九色综合98| 国产欧美久久久精品| 日本三级久久网| 999久久久国产精品| 99久久国产综合精品网成人影院| 久久r热这里有精品视频| 国产日产久久高清欧美一区| 99久久综合狠狠综合久久止| 久久久久无码精品国产不卡|