代碼審查――為可讀性努力的巨大能量

代碼可讀性這個話題一直以來都是備受關注，但是可讀性高與不高卻沒有統一的標準。畢竟各個公司，甚至於各個項目的規範都是不一樣的。我們不能說一個抽象性極好，靈活度極高卻讓人十天半個月都難以搞清楚的代碼的可讀性高，也不能說一個長達幾千行卻從頭至尾邏輯性比較好的代碼的可讀性差。那麼怎樣的代碼才算是合理的，才算是可讀性高的呢？我想不同之中必有共性，那就是經過審查的、能夠被項目組其他成員接受並能儘快看懂的代碼就是可讀性好的。

 

為什麼要做代碼審查呢？

 

要對代碼可讀性做審查，這需要人力、物力、以及項目寶貴的時間。對於一個項目來說成本是一個重要的考慮因素，然而審查無疑會增加項目的成本，那麼為什麼還要做審查呢？其實任何一個專案經理都清楚一個成功的項目都是難以一蹴而就的，開發過程必然會遇到各種各樣的問題和阻力，這也驗證了那句老話：“軟體開發中唯一不會變的就是需求永遠會變化”。我們也清楚問題越早的被發現那麼損失就會越小，補救花費的時間就會越少，自然成本就越低。但是我們有多大的機會可以儘早的發現問題呢？這不是我們說早發現問題，問題就會跟我們招手說：“看你態度不錯，就讓你早發現吧！”這麼簡單的。反覆式開發法為什麼會出現，瀑布式開發為什麼難以應對大型的商業、行業項目？思考一下我們不難會發現，客戶難以一次性的、整體的、詳盡的把自己想要的東西表達清楚，只有當客戶看見實實在在的東西之後，他才更明確自己想要什麼。好比我們去買褲子，你告訴一個人說：“我要一條簡約的牛仔褲”；然後那個人去幫你買，但是具體的顏色你確定麼，是黑色還是藍色？衣服的口袋你確定麼，是有扣子的還是沒扣子的？只有當你真真切切的到專賣店裡面，看到了試過了你才能確定：我要的就是那條１８０的藍色的口袋上沒扣子的ＸＸＸ牌的褲子。也就是說我們很少能夠儘早的從客戶口中獲得問題，除非我們指著我們做出來的東西說：看看，這是不是你想要的。既然如此，要控制的不是儘早的去發現問題，而是如何在問題出現之後儘早的找出問題所在，並解決問題，進而降低項目的成本。

其實軟體開發的主要時間是花費在調試上，然而調試中花費的大部分時間又在於讀代碼。倘若之前開發該模組的人員已遠在天邊，面對幾千行混亂無序的代碼任誰都難以承受。因而花費成本在代碼審查上是值得的，而且是必須的。可惜的是，現在很少有人去關注代碼的規範性、可讀性，甚至在大公司都是如此。專案管理者過於注重項目的進度，只要開發人員把自己的任務做完了，很少有人去關注他寫的代碼，甚至開發人員自己都不會再去看。

 

         代碼審查有何好處呢？

 

         首先代碼審查可以提高軟體的品質，以及可維護性。這樣就可以減少尋找錯誤的時間，提高解決ｂｕｇ的效率，提高開發效率的同時降低後期的維護成本。

　其次，經過審查的代碼是能夠迅速被項目組其他成員看懂的，這樣有利於項目其他成員更全面的瞭解業務，對於成員之間交流也有很好的促進作用，當其中負責某個模組的開發人員離職之後其他人員能夠迅速的接手相關的開發，並能夠儘快的培養新人彌補空缺。

　最後，代碼審查的過程是總結提高的過程，也是交流的過程，可以有效提高開發人員的技術水平以及業務素養，增強公司的競爭力，通過總結交流甚至可以從不同項目中提取共性，做出相關產品，從而形成公司自己的核心競爭力，做到行業領先。

 

如何去做代碼審查？

 

從參加人員來說，應該是項目的整體參與者，如果項目太大，整體參加的成本很高，那麼可以以模組為組進行審查。因為他們之間負責的業務是緊密相關的，使用的技術是接近程度比較大的，因而開發的規範應該是統一的。

從審查內容來說，應該是代碼的命名規範，以及組織圖。每個項目都有自己的規範，但是如果項目內部使用不同的規範必然會增加發現問題、解決問題的難度同時增加後期的維護成本。

從審查時間來說，應該在每個模組開發完成之後進行，便於開發人員之間交流問題以及體會，並且每個人的講解時間不要超過３０分鐘，因為模組的業務複雜度不會那麼複雜，３０分鐘都講不清的商務邏輯如何保證代碼是清晰的。

從審查的結果來說，經過審查的代碼應該是參加成員大部分能認同的，並且參與者每個人都能讀懂的邏輯清晰的代碼，並且通過交流提高項目成員的凝聚力，提高其業務認知度，最好能形成項目之間可以共同使用的產品。

 

原創文章，轉載請註明出處！
All CopyRight Reserved ！

 

首頁：http://jingtao.cnblogs.com

QQ:307073463
Email:jingtaodeemail@qq.com
MSN:sunjingtao@live.com