2016-03-22-信息系統實踐手記3-按業務展開的代碼剝離

---

layout: post
title: 2016-03-22-信息系統實踐手記3-按業務展開的代碼剝離
key: 20160322
tags: 測試 重構 方面編程 優化 持續集成 master PO 開發 剝離
modify_date: 2016-03-22
---

信息系統實踐手記3-按業務展開的代碼剝離

說明：

• 本文發佈於: gitee,github,博客園
• 轉載和引用請指明原做者和鏈接及出處.

正文：

• 信息系統實踐手記系列是系筆者在平時研發中前後遇到的大小的問題，其中比較典型的內容加以收集和分享。
• 信息系統實踐手記目錄：博客園(或查看源碼的README.MD文件)

摘要：

• 介紹一下業務相關的代碼優化（比較抽象，偏系統分析和設計）。

正文

1. 問題出現

如前面2次手記提到的這個既有視頻功能也有地圖GIS業務的客戶端，它的確有瑕疵（要開發的面面俱到，毫無問題的確困難）。
此次遇到了其實能夠歸爲「面向方面編程」的問題。問題的出現實際上是一個研發老大難問題，典型的患病過程以下：

1. 開始先作客戶端軟件的原型（研究大框架，大應用場景，平臺互通狀況，模塊調用個狀況等）;//沒啥問題
2. 逐的添加單一的功能來迎合需求的增加（相對獨立的功能）;//沒啥問題；
3. 功能開始增多，場景也多了，開發人員從1個變爲2個，4個，6個，並且遇到了全國各地多處研發節點的聯合開發；//代碼開始冗餘，但問題不大；
4. 爲快速發佈到現場拿合同和項目，產品經理最關心的是快速實現功能，而不是重構和優化，因大框架優秀才勉強支撐主體開發，代碼細節開始走上不歸路；//代碼冗餘加重，開始患病；
5. 開始出現張三在實現功能A時引發功能B失效，只能不斷迴歸測試，投入巨大人力，高手介入後發現代碼冗餘問題，開始抱怨；//代碼問題不能再忽視和忍受了；
6. 勉強通過添油加醋，讓產品經理（掌控人力）認識到問題嚴重，贊成開始作細膩的代碼剝離；也就是今天的主題，優化；//越晚重構代價代價越大，幾何增加！不划算！
7. 得到人力支持，選高手1枚，普通開發1枚（其餘高手還要應付主線同步開發呢！），帶上系統和測試各一枚，咱就開始梳理和剝離代碼，原理和過程較多，僅列舉核心步驟以下：

2. 問題解決

1. 會診啓動：找（系統，開發，測試）各角色會診問題，明確解決路徑和目標，及大體時間要求和尺度；
2. 檢視源碼：開發集中review相關代碼塊，作到心中熟悉（功能上百個，通過十來人開發多年，早就忘記誰開發過什麼）；
3. 場景梳理：從測試角度，按功能不一樣，區分不一樣的場景入口及功能展示，將它們做爲線頭，梳理成文檔；
4. 場景分類：從之前一味的實現大量功能，到如今按場景類別，區分出幾種典型的場景{S1，S2，...，Sn}，符合：
5. Sx間具獨立性（低耦合）：不互相依賴，使用上運行存在時空重疊狀況而互不影響的；這涉及到：
5.A. 客戶端代碼角度：Sx的代碼片斷應該互相獨立，不該該公用公共變量，數據結構或共享CACHE，以便互不干涉，支持同時GUI呈現；
5.B. 服務器代碼角度：要考慮Sx的功能接口互相獨立，各自運行；
5.C. 通常來講，SERVER的設計原則老是「service on demand/按需服務」以及「independent/獨立性」！
6. Sx內的依賴性（高內聚）：在Sx的同類場景內，幾種細分的功能或業務不能同時展示GUI,互斥狀況。
6.A. 客戶端代碼角度：Sx的同類場景只能單選激活，代碼上容許（甚至應該）共享公共變量，相同邏輯或數據結構，CACHE等，框架上應提高關聯性。
6.B. 服務器代碼角度：要考慮對Sx同類的場景提供服務時的鑑權，狀態變遷，各類約束等狀況，以避免出現場景混亂和互相影響。
7. 剝離代碼：按不一樣業務場景分類Sx，開始剝離代碼，對客戶端代碼作檢視，掃描實體動做代碼依賴的「CACHE緩存，數據結構，上下文依賴，等等程序片斷和元素」，而後該複製的複製，該用框架整合歸併的歸併。
8. 代碼測試：剝離後，開發層面本身作MT（模塊測試），而後打包給測試同事作SIT（系統集成測試），最終將分支合併到主線（若是以爲控制得住版本及發佈節奏，可不拉分支，直接在主線同步作新開發和代碼重構；
   這省去了合併分支的巨大effort，但風險是一段時間內沒法發增量版本，這方面的軟件工程內容及敏捷實踐，筆者另篇詳述。

3. 多說幾句

這裏的剝離其實算是重構的一種，對敏捷開發來講重構是極其重要的內涵，而重構最大的祕訣就是master（敏捷教練）的執着；

一個優秀的master一般應該具有：很是熟悉開發技術+善於找「茬」+喜歡「折騰」+完美主義者+能守住「程序之魂」的人；
master最好仍是：測試老法師，開發老法師，溝通老法師，設計老法師，架構老法師，文檔老法師；這基本是不可能的；

祝全天下用血肉實踐着敏捷開發的人們！

END