代碼可讀性這個(gè)話(huà)題一直以來(lái)都是備受關(guān)注,但是可讀性高與不高卻沒(méi)有統一的標準。畢竟各個(gè)公司,甚至于各個(gè)項目的規范都是不一樣的。我們不能說(shuō)一個(gè)抽象性極好,靈活度極高卻讓人十天半個(gè)月都難以搞清楚的代碼的可讀性高,也不能說(shuō)一個(gè)長(cháng)達幾千行卻從頭至尾邏輯性比較好的代碼的可讀性差。那么怎樣的代碼才算是合理的,才算是可讀性高的呢?我想不同之中必有共性,那就是經(jīng)過(guò)審查的、能夠被項目組其他成員接受并能盡快看懂的代碼就是可讀性好的。
為什么要做代碼審查呢?
要對代碼可讀性做審查,這需要人力、物力、以及項目寶貴的時(shí)間。對于一個(gè)項目來(lái)說(shuō)成本是一個(gè)重要的考慮因素,然而審查無(wú)疑會(huì )增加項目的成本,那么為什么還要做審查呢?其實(shí)任何一個(gè)項目經(jīng)理都清楚一個(gè)成功的項目都是難以一蹴而就的,開(kāi)發(fā)過(guò)程必然會(huì )遇到各種各樣的問(wèn)題和阻力,這也驗證了那句老話(huà):“軟件開(kāi)發(fā)中唯一不會(huì )變的就是需求永遠會(huì )變化”。我們也清楚問(wèn)題越早的被發(fā)現那么損失就會(huì )越小,補救花費的時(shí)間就會(huì )越少,自然成本就越低。但是我們有多大的機會(huì )可以盡早的發(fā)現問(wèn)題呢?這不是我們說(shuō)早發(fā)現問(wèn)題,問(wèn)題就會(huì )跟我們招手說(shuō):“看你態(tài)度不錯,就讓你早發(fā)現吧!”這么簡(jiǎn)單的。迭代開(kāi)發(fā)為什么會(huì )出現,瀑布式開(kāi)發(fā)為什么難以應對大型的商業(yè)、行業(yè)項目?思考一下我們不難會(huì )發(fā)現,客戶(hù)難以一次性的、整體的、詳盡的把自己想要的東西表達清楚,只有當客戶(hù)看見(jiàn)實(shí)實(shí)在在的東西之后,他才更明確自己想要什么。好比我們去買(mǎi)褲子,你告訴一個(gè)人說(shuō):“我要一條簡(jiǎn)約的牛仔褲”;然后那個(gè)人去幫你買(mǎi),但是具體的顏色你確定么,是黑色還是藍色?衣服的口袋你確定么,是有扣子的還是沒(méi)扣子的?只有當你真真切切的到專(zhuān)賣(mài)店里面,看到了試過(guò)了你才能確定:我要的就是那條180的藍色的口袋上沒(méi)扣子的XXX牌的褲子。也就是說(shuō)我們很少能夠盡早的從客戶(hù)口中獲得問(wèn)題,除非我們指著(zhù)我們做出來(lái)的東西說(shuō):看看,這是不是你想要的。既然如此,要控制的不是盡早的去發(fā)現問(wèn)題,而是如何在問(wèn)題出現之后盡早的找出問(wèn)題所在,并解決問(wèn)題,進(jìn)而降低項目的成本。
其實(shí)軟件開(kāi)發(fā)的主要時(shí)間是花費在調試上,然而調試中花費的大部分時(shí)間又在于讀代碼。倘若之前開(kāi)發(fā)該模塊的人員已遠在天邊,面對幾千行混亂無(wú)序的代碼任誰(shuí)都難以承受。因而花費成本在代碼審查上是值得的,而且是必須的??上У氖?,現在很少有人去關(guān)注代碼的規范性、可讀性,甚至在大公司都是如此。項目管理者過(guò)于注重項目的進(jìn)度,只要開(kāi)發(fā)者把自己的任務(wù)做完了,很少有人去關(guān)注他寫(xiě)的代碼,甚至開(kāi)發(fā)者自己都不會(huì )再去看。
代碼審查有何好處呢?
首先代碼審查可以提高軟件的質(zhì)量,以及可維護性。這樣就可以減少查找錯誤的時(shí)間,提高解決bug的效率,提高開(kāi)發(fā)效率的同時(shí)降低后期的維護成本。
其次,經(jīng)過(guò)審查的代碼是能夠迅速被項目組其他成員看懂的,這樣有利于項目其他成員更全面的了解業(yè)務(wù),對于成員之間交流也有很好的促進(jìn)作用,當其中負責某個(gè)模塊的開(kāi)發(fā)人員離職之后其他人員能夠迅速的接手相關(guān)的開(kāi)發(fā),并能夠盡快的培養新人彌補空缺。
最后,代碼審查的過(guò)程是總結提高的過(guò)程,也是交流的過(guò)程,可以有效的提高開(kāi)發(fā)人員的技術(shù)水平以及業(yè)務(wù)素養,增強公司的競爭力,通過(guò)總結交流甚至可以從不同項目中提取共性,做出相關(guān)產(chǎn)品,從而形成公司自己的核心競爭力,做到行業(yè)領(lǐng)先。
如何去做代碼審查?
從參加人員來(lái)說(shuō),應該是項目的整體參與者,如果項目太大,整體參加的成本很高,那么可以以模塊為組進(jìn)行審查。因為他們之間負責的業(yè)務(wù)是緊密相關(guān)的,使用的技術(shù)是接近程度比較大的,因而開(kāi)發(fā)的規范應該是統一的。
從審查內容來(lái)說(shuō),應該是代碼的命名規范,以及組織結構。每個(gè)項目都有自己的規范,但是如果項目?jì)炔渴褂貌煌囊幏侗厝粫?huì )增加發(fā)現問(wèn)題、解決問(wèn)題的難度同時(shí)增加后期的維護成本。
從審查時(shí)間來(lái)說(shuō),應該在每個(gè)模塊開(kāi)發(fā)完成之后進(jìn)行,便于開(kāi)發(fā)人員之間交流問(wèn)題以及體會(huì ),并且每個(gè)人的講解時(shí)間不要超過(guò)30分鐘,因為模塊的業(yè)務(wù)復雜度不會(huì )那么復雜,30分鐘都講不清的業(yè)務(wù)邏輯如何保證代碼是清晰的。
從審查的結果來(lái)說(shuō),經(jīng)過(guò)審查的代碼應該是參加成員大部分能認同的,并且參加者每個(gè)人都能讀懂的邏輯清晰的代碼,并且通過(guò)交流提高項目成員的凝聚力,提高其業(yè)務(wù)認知度,最好能形成項目之間可以共同使用的產(chǎn)品。
原文轉自:http://kb.cnblogs.com/page/54460/