1.可維護性
代碼的可維護性和可擴展性的第一責任在架構,因為架構要做相關的分析模型,劃分相關的單元模塊和接口,考慮組件和復用等各方面的問題. 架構設計是高層次的往往只抽象出相關的類和包,對于每一個類中應該設計哪些方法和函數,并如何組織這些方法和子函數的調用關系,還必須進行詳細設計,這是編碼的可維護性和可擴展性的兩個最基礎的內容.
能夠準確表達代碼實現意圖的言簡意駭的注釋是源代碼可讀性的一個重要內容.好的源代碼應該是可以自解釋的,因此注釋不應該太多也不應該全是些照字面翻譯語句的垃圾注釋.注釋的量一般占代碼總量的10-20%就可以了(如果注釋量超過30%說明垃圾注釋太多,代碼的自解釋性不好很多應該拆分為子函數的沒有拆分等原因).源代碼文件的文件頭要有注釋說明整個類的實現功能和流程,調用多個子函數的主方法方法頭要有明確的實現意圖和調用步驟的注釋(很重要),以方便維護人員和自己閱讀代碼.
方法和變量命名等要嚴格遵守相關的編碼規范進行命名.名稱不要怕長,名稱要能夠完全的體現出方法所實現的功能.如根據某一客戶編號查詢其的所有定單,則GetInfo,GetOrderInfo等不是最好的方法名.而應該采用GetOrderInfoByCustomerNo,通過這種方法名稱即使不加任何注釋其它人員也可以很好的閱讀你寫的代碼.
一個類文件建立代碼行不易超過2000行,超過2000行都應該拆分相關的擴展類或Helper類.在一個類文件中一個方法或函數不易超過50行,超過50行的可以考慮拆分相關的子函數.但這個規則也需要靈活考慮,比如對于一些數據有效性或完整性判斷的函數,超過50行一般不會存在任何問題.
每個軟件開發項目開發前都應該定義相關的編碼約定或規范,該文件包含了命名,縮進,注釋,布局等各方面的內容,在此就不再做過多的敘述.
2.可擴展性
編碼可擴展性的源頭是需求的可擴展性,首先需求人員要在需求分析過程中分析出哪些需求是易變化或會擴展的需求.只有需求考慮到了可擴展性,架構在設計過程中才能夠有針對性的進行設計,否則只能夠后期對代碼進行重構來實現源代碼的可擴展性.
可擴展性基于原有的經驗積累和他人的最佳實踐.充分理解面向對象分析和設計的思想和重要的設計模式.設計模式的精髓就是面向接口設計,而這個也是保持代碼的可擴展性的一個重要思路.另外在面向結構方法中我們對數據表的字段或方法參數預留一些擴展字段也是常用的支持系統擴展的方法.好的擴展性的判斷準則有
a.設計到需求變更或新需求時候或是新增類文件或是新增方法,而不是對已經有的多個源代碼文件造成影響
b.設計一些簡單的擴展時候,可以靈活的通過配置文件來實現而基本不用修改源代碼
我們對需求的理解也是逐漸細化的過程,因此一開始就得到完全健壯的代碼是很難的,通過需求的不斷細化和需求的變更來Review我們的代碼實現,適時而不斷的對代碼進行重構才可能得到健壯和可擴展的代碼.
3.安全性
安全性仍然屬于代碼內在質量的一個內容.但平時在開發過程中往往并不會特別注意代碼的安全性.對于軟件系統的安全性基本可以專門開專題來討論,在這里僅僅簡要說明一下.
首先是源代碼應該防止被反編譯,相關的重要數據和數據庫連接串等信息都應該加密進行存放.其實是在分布式應用中要注意數據傳輸的安全性,防止數據被非法獲取.對于暴露的遠程服務要注意身份認證和識別,防止他人偽造客戶端進行調用.其次整個系統應該有完善的權限模型,除了最簡單的業務功能權限外,還應該根據需要對系統中相關的業務對象有完善的靜態權限和動態權限的控制機制.
4.系統的健壯性
系統的健壯性比較重要的一點就是系統對異常的捕獲和處理能力.因此對于一個軟件系統應該有完善和獨立的異常處理和日志記錄機制.當出現不可預見的錯誤時候不會導致整個軟件系統或操作系統的崩潰.同時系統還需要記錄足夠的異常和日志信息,以方便后續維護人員對問題進行跟蹤和分析.
文章來源于領測軟件測試網 http://www.k11sc111.com/
