信息系统实践手记3-按业务展开的代码剥离
说明：
正文：
- 信息系统实践手记系列是系笔者在平时研发中先后遇到的大小的问题，其中比较典型的内容加以收集和分享。
- 信息系统实践手记目录：博客园(或查看源码的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最好还是：测试老法师，开发老法师，沟通老法师，设计老法师，架构老法师，文档老法师；这基本是不可能的；
祝全天下用血肉实践着敏捷开发的人们！
