開發小結-設計類

本文主要彙總了本身在軟件設計方面的一些經驗總結。

設計評審

對於一些基礎組件的重構改進，在本身作完相關設計後，務必要請組內其餘人一塊兒評審下，不要以自我爲中心，覺得本身寫的接口就是完美的。多與人討論，無論討論的對象是老手、仍是小白，多個角度去審視已有設計，於人於己都是大有益處的。

基礎類接口的設計務必要慎重，一旦成型後，再想改動，難度就很大。舉個例子，我以前負責的基類代碼，其中有些接口以及內部實現寫的不合理，外部用起來很彆扭，但因前期使用範圍較小，彆扭就彆扭的用了。隨着時間的流逝，該基類被愈來愈多的人使用，吐嘈聲不斷，本身有太重構接口的想法和具體方案，但礙於改動牽涉到的面較大，就沒有推進改進下去了。

UI設計

UI顯示邏輯，顯示數據來自後臺響應，在後臺響應數據以前，「當前界面的原始數據是否要清空，有兩種見解：

清空界面數據：優勢每次不會看到舊數據，缺點是當網絡很差時，顯示界面會空白。

不清空界面數據：優勢是在網絡還沒有返回數據時，用戶體驗好。缺點是，看到的數據是舊數據。

具體採用哪一種措施，我的覺的取決於當前數據對用戶的重要程度以及更新頻率，若是數據很重要而且頻繁更新，那最好在先清空界面數據，再日後臺發送請求。若是不是那麼重要，並且更新頻率不高，那麼不清空界面數據帶來的體驗較好。

從開發流程一致性上來看，統一清空界面數據的心智負擔較小。

對於一個界面來講，進入和退出的處理，最好要有相互呼應的地方。怎麼理解呢？好比說，打開的時候有清空、申請資源、發送請求、初始化操做的動做，那麼退出也要有清空、釋放資源、取消請求和卸載操做的動做。不論是某個界面，某個模塊，子系統和整個系統，一致性操做要保證，不然就有潛在的泄露問題。

解決方案設計

在從新設計時，不要被已有的實現方案所束縛。假設這個模塊是從0開始，你會怎麼去組織和設計各類信息。

腦子裏面首先想出來的方案，每每不是最佳的，確定有改進的空間。
每個設計方案，首先都有它的總體的設計思路，隨後的鋪陳展開，都圍繞這個總體思路來作。

任何一個需求或者功能的實現，均可以致少定出兩三個方案，在開始具體編碼以前，要分析各個方案在實現基本功能以外的優缺點。由團隊一塊兒來討論，看看在這種場景下，使用哪一種方案較好。

將各個模塊所使用到的全局數據能夠集中彙總到全局類中，如要實現配置熱更新功能，則可在配置改變時，只須要更新此類中的內容便可。外部賴該數據的模塊，無需改變，只需在全局配置改變事件中從新初始化便可。

如可以動態計算的內容，不須要額外用變量來保存，對外提供接口函數，在每次獲取時，從新計算或者發消息獲取。

對於枚舉類型和字符類型的相互轉換，若是枚舉類型只定義了4種，每一種有對應的數值，

enum ETest
{
    TEST_1 = 1,
    TEST_2 = 2
};

ETEst a = (ETEst)1;
a = (ETEst)3;        // 這句能夠編譯經過

枚舉類型的強制轉換，若是cTemp的值來自於網絡流，網絡流數據又可能不在已有枚舉範圍內，會存在無效狀況，而這在編譯階段時不會報錯不會報錯，在運行階段，該枚舉值就有潛在的隱患，爲了消除該隱患，建議枚舉類型統一經過函數來轉換，對於不在枚舉值中的轉換，提示錯誤，返回錯誤類型的枚舉值。

高內聚低耦合

什麼樣的功能須要高內聚在一塊兒，在今天的討論中，好比斷線重連提示框的控制和提示框自己實現。

就這兩個功能來講，提示框自己做爲一個較獨立的功能，若要複用，那麼提供的接口函數粒度就能夠比較細，讓外部使用者根據具體功能來調用各個接口，實現本身的功能。從提供方來講，是能夠了。

但在有些場景下，外部使用者只想設置它關心的數據，其餘類型的配置它不想關心，但這些設置有是有必要的，好比位置、Logo等，這個時候，有兩種作法：

方法一：在提示框中，各種設置均有一個有意義的默認值，若外部不設置，則使用默認值。

方法二: 若外部不想關心與它無關的設置，可在提示框外再提供一個初始化函數，內部設置好默認配置下提示框，提供給外部使用。外部只須要調用者一個初始化函數便可，如有其餘的需求，接着調用其餘接口就行。

功能的提供者和功能的使用者關注點是不同的，提供者提供的粒度可小可大，但從設計原則上來看，每一個接口實現的功能要足夠細化，而一些較複雜，須要組合各個接口實現的功能，可由使用者來安排，也增長一箇中間層，由中間層來構造較高級的接口，高級接口的設計，按照接口一致性來，有create就必定有對應的destory。

高內聚的另外一種角度的理解：

代碼被閱讀的次數要遠遠大於它被修改的次數，所以，代碼可讀性決定了可維護性，代碼定義的關聯性（相關代碼定義和對應輔助函數）要大於分散性。

相同語意的語句要內聚到一塊兒。具體表現爲一組相關的數據類型定義，應該聚合在一塊兒，方便一塊兒閱讀理解。好比和登陸相關的，登陸類型和認證類型就適合放在一塊兒。相互關聯的定義以及接口函數，應該或者說必須放在一塊兒。

顏色的複用

在程序中涉及到顏色數值，確定不會直接寫死，而是用顏色ID映射具體顏色數值。這裏有一個問題，相同的顏色數值，要不要對應同一個顏色ID呢？若是這兩個相同的顏色數值用在兩個不一樣的地方，那麼他們就是兩個不一樣的顏色ID，即便他們所映射的數值相同。假想將來某個地方顏色值有修改，那隻修改對應顏色數值便可，不用影響其餘界面。

爲了減小顏色的適配工做量，同時爲之後的切換顏色方案打好基礎，開發須要限制設計可以容許的顏色取值範圍，不能讓設計無休止的提各類不一樣的顏色需求，例如，每一類顏色只提供可選的10左右的ID段範圍，能夠有多類(12類)顏色，設計提供的總的顏色數值總量控制，具體數值能夠自定。

消息設計

消息通常有操做系統原生消息，系統級別請求響應消息，系統級別訂閱發佈消息，還有各個子模塊內部使用的自定義消息。每種層級的消息須要定義好使用界限，什麼層級的代碼使用什麼類型範圍的消息，在架構設計時，就須要有嚴格的定義。

消息宏的定義要全局系統惟一，消息的定義惟一可避免不一樣模塊定義了相同數值的不一樣功能的消息。要作成全局惟一，最佳實踐是在同一層級目錄下，定義全局消息，事先定義好各個業務的消息起始段和結束段。

每一種消息的定義要清楚明確，好比顯示用戶信息，清除顯示這兩個功能，

第一個功能能夠定義 WM_SHOW_INFO ，帶用戶標識可。

第二個功能的話，有兩種作法：

• 複用WM_SHOW_INFO，傳空的用戶標識表明清楚顯示內容。

• 單獨定義清空界面顯示消息，WM_CLEAR_INFO

這兩種作法，推薦使用第二種，它符合消息功能的惟一性。

針對消息發送來講，不容許跨層消息傳遞，只容許向上一層發送消息，只響應本模塊負責的消息，若不屬於本模塊的職責，向上繼續傳遞消息。

消息的命名規範，與現有工程中的消息命名規則保持一致，若不一致，則須要修改使其一致，同時，將本次修改做爲單獨提交。

消息的使用場景、使用方法、入參說明以及正常的使用範例，至於消息負責人，能夠從SVN的blame功能中推導出來，須要隨着消息的定義一同清晰明確的給出。

對於消息的定義和使用，一種消息帶的參數，必定有明肯定義，通常不建議傳遞可變長度的消息，例如以下這種：

struct NMClickNum
     {
        CString m_strName;
        vector<CString> m_vInfo;
     };

在消息中傳上述結構體，是有安全隱患的。由於接受者有額外的心智負擔，須要考慮傳遞的順序和對應的一致性，很容易用錯。好比A界面vector裏面塞3個數據，B界面塞3個數據，但不一樣順序的數據含義不一樣，在消息接收端，首先判斷消息的個數是否符合要求，即便是符合要求，也不能確保特定索引位置上的消息必定是想要的，由於沒法判斷錯誤。這種送不定長的消息只適用於網絡流層面，在業務層是禁止使用。

業務層面的消息的目的性要惟一，不能造一個通用層面的消息，攜帶各類數據，在各類組件之間穿梭。而是，針對特定的業務和界面，定義特定的消息，好比說

A界面須要3個數據
B界面須要另3個數據
C組件產生這3個數據是A界面須要的
D組件產生的3個數據是B界面須要的

那麼，在定義消息時，A-C之間定義一個消息，D-B之間定義另外一個消息，不一樣消息攜帶的參數要有明顯的區分定義，以防用錯。