本文總結開發實踐思考系列文章，本文是第一篇。

本文內容來源平時工作中的一些思考，每一點都是實戰經驗，之前都是零散記錄在各個文件中，是時候彙總梳理，每篇文章以10個點為準，以備記錄。

1. 定義列舉變數，一定要定義無效值。

   定義無效值有以下好處：

   1. 方便有確定含義的列舉變數初始化，與正常值區分開。
   2. 將其他值轉換為列舉型別時，如果遇到無法匹配，可轉換為無效值。

2. 對成員變數的操作不建議跨層級。

   舉個例子，一個父類的protect型別成員變數，可以在子類中進行賦值，在父類中進行使用嗎？
   從語法上說，是可以做到的，但從實現上看，父類的資料成員在子類中被直接改變，這是不合適的。如果跨層級直接修改，感覺父類和子類對該變數的職責各佔一份，一來職責混淆，二來新增子類時，容易遺漏。如果確有場景這樣操作，建議對變數進行封裝，禁止子類直接，只能通過介面進行操作。

   例如：網路層的響應處理中

   
   void CNetReq：OnResponse(CResult& ret)
   {
   	if (!ret.IsSuccess())
   	{
   		m_rspInfo.m_nRetId = ERROR;
           m_rspInfo.m_nErrCode = ret.GetErrCode();
   		m_rspInfo.m_strErrMsg = ret.GetErrMsg();
   	}
   	
   	OnResponse(ret);
   }
   
   

   上述例項程式碼，將網路響應包的錯誤處理統一提取處理，正確的處理放到OnResponse中，這就隱含了一個要求，每一個響應包的OnResponse都必須對m_rspInfo進行正確情況的賦值，而響應頭m_rspInfo的預設構造是正確的，但這個約定是很脆弱的。如果新寫的響應有遺漏，或者上層複用了該請求，可能會出現這樣的錯誤，第一次響應失敗，後續即使響應成功，上層也認為是失敗，這是很隱蔽的問題，一定要注意。

   上面還有個隱含的問題，網路層的錯誤資訊和應用層的錯誤資訊屬於不同層級關心的事情，要有明確區分，不要混在一起處理。

3. 越是到發版前，發現的問題越多。

   經歷過若干次發版經歷後，發現上述現象。越是到發版前，發現的問題越多，感覺是不是快到每個版本的發版的deadline時，工作效率越高？

4. 版本除錯級別建議至少3個

   這三個級別分別是DEBUG、PRE_RELEASE、RELEASE級別：

   • DEBUG級別：輸出最多最詳細的除錯資訊，輔助測試
   • PRE_RELEASE級別：預釋出級別，給測試用的，相比於DEBUG級別，去掉詳細的除錯資訊，當發生嚴重錯誤時，才進行顯式提示。
   • RELEASE級別：生產級別，最終生產環境使用的版本，只有很少的除錯資訊，開啟各種優化措施，提高執行效率。

   在程式碼中，可通過_DEBUG、PRE_RELEASE巨集來包裹除錯程式碼，用於定位問題。

5. 處理介面返回的業務資料，比如比例、利率等處理

   要明確瞭解介面返回的業務數值含義，例如比例、利率等。搞清楚介面返回的是小數形式，還是百分比形式。由於不同介面是不同人開發的，有可能同一個變數，不同介面返回的形式不一樣，前端展示時，不能想當然的認為是小數形式，保證顯示單位和實際數值內涵保持一致。

   更近一步，推薦後端在返回此類資料值，指定規則，統一按什麼規則來返回，方便前端理解和使用。

6. bool變數的預設取值

   針對bool型別的預設變數，本身限制了取值範圍(false和true)。這種場景下，預設值取true還是false呢？實踐上看，如果該變數大部分時間為true，只有特殊場景下才會被外部設定false，那預設值取true較好，反之亦然。

7. 遇到"錯錯得正"的場景時，要特別慎重

“錯錯得正”是自己踩過坑的場景，前端送參送錯了，而後端恰好又沒有關心該入參，導致最終結果雖然是對的，但從邏輯上是有隱患的。一旦後端完善此問題，那之前正常的功能可能會變得不正常，但介面描述上又沒有更改，這會引發非常難以排查的問題。

在進行code review時，排查“查交易批次號”功能，發現當前端送的引數不對時，後臺也能返回正確結果，此功能早已上線，參照介面要求，該入參是必填值，詢問後臺開發人員得知，他們在實現該介面時，內部實現與介面描述不一致，對入參只做了簡單有效性判斷，具體查詢邏輯沒用到入參。這導致，看起來結果是對的，但前端和後端實現都有錯誤，這很大的隱患。

回顧這一點，要求後臺介面實現人員和介面文件說明要強一致，必填的引數都要檢查並且在業務邏輯中使用。

8. 介面入參轉換要直截了當，不要加冗餘的操作

例如某個介面的入參要傳空字串，那最佳實踐就是傳空字串。在實際中，我看到有這樣的程式碼:

char cArg = 0;
CString strArg;
strArg.Format("%c", cArg);

上述做法，乍一看，非常像傳了空指標進入，再仔細一看，發現CString對於這種情況會隱含處理，顯示為空字串。這種繞圈的做法，不直觀，很容易出錯，不建議這樣用。

入參要直接了當，要求什麼型別就傳什麼型別，不要依賴一些轉換類的隱含操作來保證。

9. 分頁查詢定位串問題

在涉及到大資料量查詢時，常見的解決方案有分頁查詢。在獲取定位串時，要注意獲取的正確性，不要拿非定位串的欄位，當做定位串欄位。在這種情況下，查詢小資料量是正確的，因為所有資料都小於1頁的資料量。而在大資料量，且當天資料超過1頁時，會出現重複同一個定位串的問題，造成重複查詢。

分頁查詢相關問題，需要多測試幾種邊界值，同時做好重入查詢的防範。

10. 概要設計中梳理與此需求緊密相關的介面資訊

在接到需求以及後臺介面時，需要在概要設計階段，理清需求要求展示的每個欄位的資料來源以及展示說明，有時候介面給的很多，但針對此需求，只需要關心涉及到的欄位，將涉及到的欄位重新整理出來，以便方便後續開發和測試。

作者：浩天之家 出處： http://www.cnblogs.com/cherishui/ 本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連線，否則保留追究法律責任的權利. 頂 Top 收藏 關注 評論