如何編寫可信賴的代碼

 

        軟件， 邏輯之塔， 精微的藝術。

       遵循嚴格的代碼規範， 學習好的編程模式，  避免常見的編程錯誤， 持續小步重構改進，  嚴格測試與必要文檔，  理解所寫的每一行代碼， 正確使用 API， 代碼 Review ，  追求更好的解決方案， 注重總體設計 。  

什麼是好的代碼

     做爲一名合格的程序員， 須要知足的兩個最基本要求：

        1.  可以編寫值得信賴的程序和文檔；

        2.  可以無障礙地與團隊成員進行探討交流。

     假設咱們是一段代碼的使用者， 對代碼的要求會是怎樣的？  

         代碼有必要的文檔， 詳細說明了它的主要意圖及設計思想；

         代碼出色地完成了它所聲稱的工做， 對於不合法狀況可以給出合理的返回結果或友好提示； 可以應對大數據量；

         代碼穩固， 在異常狀況下依然堅挺， 至少能夠給出友好提示， 或降級運行；

         容易讀懂、修改和擴展。

         一般狀況下， 主要考慮如下質量屬性： 正確性、性能、 健壯性、 可維護性。 

 

 

可信賴代碼之道

     編寫可信賴的代碼， 須要採用多種方法和手段去逐步逼近。 如下是一些好的作法： 

      1.   肯定一種嚴格的代碼風格和規範， 嚴格遵行它。  

         

             良好的代碼風格不會保證程序的正確性， 但能保證代碼清爽易讀，更容易找出錯誤；

   

 

      2.   掌握好的編程理念和模式，  儘量使用習慣用法和推薦用法。

 

              a.   自頂向下， 意圖導航；  

             b.   搭建原型， 逐步細化；

             c.   接口與實現分離解耦；

             d.   構造與使用分離解耦；

             e.   事件與處理器鏈分離解耦；

             f.     「一個事實」原則； 「對修改關閉， 對擴展開放」原則； KISS 原則； 

             g.   充分利用已有成熟庫和組件；

             h.   經過封裝， 屏蔽低層複雜性， 使用容易理解的高層語義構建程序；

             i.    First Make it Right, Then Make it Good.

 

     推薦書籍：《 Effective Java 》, 《代碼整潔之道》， 《Writing solid code》、 《編寫可讀代碼的藝術》，《代碼大全》, 《Unix / Linux 設計思想》，《敏捷技能修煉》， 《程序設計實踐》（K&R） 。 

 

      3.  熟悉常見錯誤代碼模式， 避免犯相同的錯誤。

 

       聰明的人從別人的錯誤中汲取教訓。 《Code Quality: The Open Source Perspective》 這本書從代碼層面深刻討論了各類編程錯誤。

 

       參閱： 《 CR常見代碼問題》

       根據二八定律， 80% 的 BUG 是由 20% 的編程錯誤引發的， 所以， 熟悉這 20% 的編程錯誤並避免之， 就能避免 80% 的BUG 。此外， 有些 BUG 多是由系統集成致使的， 屬於更精微的層面， 另當別論。 充分利用編譯器及靜態代碼分析工具檢測代碼。

 

       4.   持續小步重構改進，消除重複和代碼壞味。

            a.   重複代碼抽取爲公共方法；

            b.   類似邏輯提煉微框架處理；

            c.   使用設計模式優化結構；

            d.   充分使用短小函數；

            e.   刪除未用到的代碼；   

    

       5.  設立嚴格的檢驗關卡， 仔細測試。

            a.   優先級： 關鍵部件 》 經常使用部件 》 不經常使用部件；

            b.   正常狀況測試；

            c.   臨界狀況測試: 空/越界/一/二/；

            d.   等價類測試；

            e.   分支測試；

            f.    性能壓力測試； 

 

      6.   深刻理解實現原理和細節，準確理解和使用 API， 理解代碼所作的事情。

         

            a.   完整理解 API 含義， 而不是隻知其一;不知其二的狀況下調用；

            b.   檢測 API 返回值並做出合理的措施；

​            c.   理解本身所編寫的每一行代碼， 它是如何與框架進行交互的；

      7.   代碼講解，有助於發現所犯的錯誤， 也能鍛鍊口頭表達能力。

          

            a.   團隊成員之間進行代碼 Review；

            b.   給本身講解所編寫的代碼；

      8.   思考更好的表達方式和方案， 追求更好的可維護性。

            a.   使用多線程併發處理 IO 調用， 而不是迭代；

            b.   使用異步調用改善響應流暢性；

            c.   使用 API 接口代替數據庫查詢；

            d.   對於簡單方案的性能較低的實現方式， 思考更有效率的實現方式； 

            e.   對於代碼中不太清晰的地方， 逐步替換爲更清晰的實現；

      9.   閱讀優秀開源項目代碼，  潛移默化地汲取優秀的作法、思路和方案。

    10.   關注總體設計、細緻編程、考慮周全。

 

       有些問題是由總體設計引入的， 好比總體的錯誤處理，  沒法經過局部層面來解決。

         

       不當的架構設計會使代碼修改和擴展變得困難， 迫使開發者編寫大量臨時方案去解決某個具體問題； 日積月累， 整個系統就會愈來愈腐爛， 愈來愈難以維護。 始終保持簡潔有效的架構設計。          

       造成開發與測試的良性循環，創建高質量編程的一套方法和習慣（包括開發時間估算）， 對每個功能都能遵守這種方法和習慣。

       時間與質量的平衡。

 

後記參考

什麼是不可信賴的代碼 

        1.  沒有文檔；

        2.  不能（正確有效地）完成代碼文檔所聲稱的事情；

        3.  不能處理不合法狀況；

        4.  沒法應對大數據量的狀況；

        5.  沒有錯誤提示或不友好；

        6.  可能被惡意代碼攻擊；

        7.  難以讀懂、理解和修改。

       

逼近高質量的基本方法

       這就有幾個問題要思考一下， 能夠根據這幾個問題按圖索驥， 一步步地逼近高質量編程。

        1.   這段​代碼想要完成什麼樣的工做？ 要求怎樣的輸入， 能夠預期得到怎樣的輸出（輸入-輸出模型）？

        2.   什麼是合法狀況， 什麼是不合法狀況？ 如何統一處理， 減小這種合法性檢測的時間成本？

        3.   代碼所要應對的數據量有多大？ 是否可能存在時間或空間上的性能瓶頸？ 若是有， 須要仔細設計好的結構和算法去解決；

        4.   代碼所運行其中的環境如何（數據庫操做/網絡調用/文件讀寫）？ 可能發生怎樣的異常，致使什麼錯誤？ 如何進行異常處理？  

        5.   如何保證代碼可讀？  是否有可擴展性需求？ 若是有， 須要在哪些方面提供靈活性？ 

     

        基本方法：

        1.  編寫文檔， 描述所要完成的工做， 輸入是什麼， 輸出是什麼；  這是一個自我表達的過程， 有助於清晰思路；

        2.  編寫有效的測試用例， 設立檢驗關卡。

        3.  編寫代碼， 持續小步重構、改進， 必要的時候同步更新文檔，  經過測試用例；

        4.  代碼Review.  添加新的測試用例或需求， 持續改善。

     

       以上採用的是「文檔與測試導引」 的方法。既要寫文檔， 又要寫測試， 這種方法看上去工做量大， 實際上反而多是一種捷徑。 實際上， 文檔、測試、開發三者的本質都是表達， 彼此會是相輔相成的。 固然， 與「測試驅動論」或「文檔驅動論」不一樣， 編寫文檔以及經過測試用例並非最終目的， 只是一種檢驗途徑。 還須要盡力去編寫可讀性良好的代碼。