在這次ITOO技術小組裡，我選擇了“程式碼規範”這個方向進行研究，在對程式碼註釋、命名、SVN規範等了解了之後，最讓我感到興奮的一點就是：程式碼的健壯性。

   期初淺顯理解：

   健壯性是指軟體對於規範要求以外的輸入情況的處理能力。所謂健壯的系統是指對於規範要求以外的輸入能夠判斷出這個輸入不符合規範要求，並能有合理的處理方式。

   也就是說，最初的理解類似在機房收費系統中，輸入的文字框是否是規範的值，比如卡號輸入一些亂碼等，這樣的理解僅僅停留在了表象上。

   後期深層次理解：

   健壯性是指程式可以適應正常和非正常的執行環境，都可以正確地執行；隨著業務量的增加，不會出現阻塞和不可用的情況（官方概念）。

   舉一個簡單的例子：如果一個人很健壯，那麼他在遇到一些小毛病的時候，比如感冒，能夠很快恢復，而不至於遇到感冒就倒掉了

對比過來，就是如果一個程式很健壯，那麼他在遇到感冒的時候（比如，想要開啟的檔案不存在），也能夠很快恢復（處理異常情況，輸出錯誤資訊等），然後繼續執行下去，而不至於一遇到感冒就die了。

   簡單的說，健壯性的程式碼就是遇到問題不容易崩潰的程式碼。

   健壯性的思想：

    (1) 正常執行的程式碼. 首要追求高效性

這個"高效性"如果從邏輯的角度來解釋, 那麼一方面是"高效"地對正確的資料執行正確的演算法(方法/策略), 另一方面是"高效"地找出異常, 然後丟給異常處理程式碼去處理

    (2) 處理異常的程式碼. 首要追求健壯性.

就是程式必須能從異常中自我恢復. 由於程式碼多數時間跑的是"正常"邏輯, 少數情況下才不得不處理"異常", 所以"異常"處理的程式碼中, 首要任務是健壯, 跑不死, 而高效性則是次要的.

   “正常執行的程式碼”和“異常處理的程式碼”類似於：

//或者使用try catch 方式
if (判斷傳入引數的型別是否匹配)  
{  
    //"正常執行程式碼"
     //匹配，走正常處理流程, 直接把返回值傳給上層邏輯處理  
}   
else  
{  
    //"異常處理程式碼"  
     //不匹配，走異常處理流程，重新掃描傳入的資料，或者給出提示
8. }  
 

   健壯性運用的思考：

   1、在做前臺頁面過程中，對於ASP.NET驗證控制元件的使用、正則表示式的使用，要融入到我們的日常程式設計習慣當中。傳到後臺的錯誤（類似於到B層邏輯判斷進行不下去）才發現的錯誤，在前臺一定要保證根本不讓這些引數傳入到後臺，扼殺在搖籃中。

   2、合理佈局函式返回值，保證函式返回值一致

   之前很多時候寫函式往往很隨性，返回值型別可以能代表函式執行成功或者失敗的Bool型，也會有代表實際結果的Str或者Int等型別。這樣的函式在外部呼叫時痛苦非常，因為在函式呼叫後處理時，處理不當就會出現typeError，所以在函式編寫前，要思考後本函式的作用，同時確定返回值型別，在函式的所有涉及到返回結果時，給予一致型別的返回值，方便外部呼叫。

   3、必要情況下的Try…Catch…處理

   Try…Catch…出來處理異常是各種語言都有的模式。但到底在何處使用卻有講究。在沒有拋異常的語句使用try語句，會降低效能，帶來程式碼冗餘，而在需要處理的語句未加異常處理，則會帶來執行崩潰的可能。所以，要深刻的瞭解程式碼的語句，是否存在拋異常的可能，對可能拋異常的語言要加以處理。（這方面的介紹在下一篇實戰部落格中會進行講解）

   4、清理程式碼，去掉冗餘程式碼

    很多時候，我們的程式碼都是迭代開發的。往往會羅列一些無用的函式，引入一些無用的類庫。這些內容貌似無意義，但卻是程式碼中的隱患。可能在後續的類庫更新或者函式變更中爆炸。所以，程式碼要保持清理，對於無用的引用和定義，要加以清除。

   其實對於健壯性的思考，咱們在做系統開發的時候，現階段考慮的比較少，主要是對於實現功能的追求，在做過幾個專案之後，這方面的涉獵應該開始了，保證自己功能實現的情況下， 讓自己的系統“不容易那麼崩潰”，才是我們所追求的。

    另外，解鈴還須繫鈴人，在進行程式碼健壯性思考的時候，一定要去檢視常見的程式碼錯誤的幾種型別（是邏輯錯誤還是編譯有問題？等），從問題出發，就能更好的進行健壯性處理。

   下一篇部落格將從“異常處理”的角度對程式碼規範進行實戰總結。