如前面2次手记提到的这个既有视频功能也有地图GIS业务的客户端，它的确有瑕疵（要开发的面面俱到，毫无问题的确困难）。
这次遇到了其实可以归为“面向方面编程”的问题。问题的出现其实是一个研发老大难问题，典型的患病过程如下：

1. 开始先做客户端软件的原型（研究大框架，大应用场景，平台互通情况，模块调用个情况等）;//没啥问题
2. 逐的添加单一的功能来迎合需求的增长（相对独立的功能）;//没啥问题；
3. 功能开始增多，场景也多了，开发人员从1个变为2个，4个，6个，而且遇到了全国各地多处研发节点的联合开发；//代码开始冗余，但问题不大；
4. 为快速发布到现场拿合同和项目，产品经理最关心的是快速实现功能，而不是重构和优化，因大框架优秀才勉强支撑主体开发，代码细节开始走上不归路；//代码冗余加剧，开始患病；
5. 开始出现张三在实现功能A时引起功能B失效，只能不断回归测试，投入巨大人力，高手介入后发现代码冗余问题，开始抱怨；//代码问题不能再忽视和忍受了；
6. 勉强经过添油加醋，让产品经理（掌控人力）认识到问题严重，同意开始做细腻的代码剥离；也就是今天的主题，优化；//越晚重构代价代价越大，几何增长！不划算！
7. 获得人力支持，选高手1枚，普通开发1枚（其他高手还要应付主线同步开发呢！），带上系统和测试各一枚，咱就开始梳理和剥离代码，原理和过程较多，仅列举核心步骤如下：

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，但风险是一段时间内无法发增量版本，这方面的软件工程内容及敏捷实践，笔者另篇详述。

这里的剥离其实算是重构的一种，对敏捷开发来说重构是极其重要的内涵，而重构最大的秘诀就是master（敏捷教练）的执着；

一个优秀的master通常应该具备：非常熟悉开发技术+善于找“茬”+喜欢“折腾”+完美主义者+能守住“程序之魂”的人；
master最好还是：测试老法师，开发老法师，沟通老法师，设计老法师，架构老法师，文档老法师；这基本是不可能的；

祝全天下用血肉实践着敏捷开发的人们！