底层平台类的功能大多是以API形式对外提供服务。当平台持续扩充，人员一轮轮替换，不断修改bug后，会发现有一些BUG已经无法修改，增加一个新功能的代价几乎不可以承受，修改一些BUG会导致另一些BUG爆发。这个时候，就到了被迫重构的时候。
这个时候，应该怎么重构才能减少风险，减少对外部调用者的影响。
基本的原则：
一是不在重构时加入新功能
二是要重构不要重写
三是一小步一小步重构不要一口气完成整个重构
四是每一小步重构都要进行全面的验证后再进行下一步重构
五是每重构完一步都需要对之前已经验证过的重构代码进行再次验证
满足了这血泪得出的五个原则，就基本可以保证重构可以成功。
而每一个原则都可以有多种实现方式，无论是传统的瀑布开发还是敏捷开发都可以实施，无论是否使用UT、自动化还是手工测试也都可以达到目的，无论是否了解设计模式、设计原则或者DDD方法都可以进行重构。只不过要根据自己团队的基础、经验来选择合适的方式。
不过考虑到排除风险、快速重构、减少重复工作、提高重构质量，建议采取如下的方式组合。
第一，采用敏捷开发方式
第二，采用用户故事定义重构工作
第三，采用用户故事拆分技巧将重构工作拆分成互相独立的更小功能范围的重构用户故事。
第四，采用DDD技术划分领域范围，重新定义职责范围，并定义各个领域间的ACL。
第五，对于每个领域，采用软件设计原则重新设计领域内的功能职责，保证每个实现类满足下列原则：单一原则解决职责问题、开闭原则解决维护变更问题、里氏代换原则解决扩展问题、依赖倒置原则解决代码依赖问题、迪米尔原则解决代码耦合问题。
第六，熟练使用设计模式设计软件的静态结构和动态行为来满足以上提到的原则。
创建模式集合：
- 工厂模式，简化并标准化对象创建过程，保证得到的对象符合使用的标准
- 抽象工厂模式，简化了多个工厂创建多个产品系列的标准化问题，保证一类工厂可以生产出对应工厂的系列产品（对象）
- 构造者模式，简化了定制复杂产品的生产过程，可以使得复杂产品的生产过程可以通过参数定制化，从而简化了复杂对象的构建过程。
- 单例模式，保证了可以得到同一个产品。尤其是在高速生产的时候，无论以多高的速度生产，都只会生产出唯一的一个产品。
- 原型模式，保证了生产出来的产品自可以自我克隆。
结构模型集合：
- 适配器模式，保证不不同的产品间可以通过连接一个适配器满足对方产品的连接或连通方式。领域间的ACL多用适配器实现。
- 桥接模式，保证不同类别的产品都符合连接的规范，使得按照规范生产的产品可以互联互通。
- 装饰模式，保证生产的产品可以有不同的外观，可以随时替换。
- 代理模式，保证生产的产品可以先提供一个演示版，等需要的时候才真正生产产品。
- 外观模式，也叫总包模式，就是总装厂协调多家不同供应商提供原料最终组装成成品的生产产品方式
- 组合模式，生产俄罗斯套娃产品，只不过一个套娃里可以并列放入多个套娃。
- 享元模式，无论生产多少次，只要生产过，就只会得到同一个产品。大家分享着用吧。
行为模式集合：
- 策略模式：使用产品的时候，根据不同的使用场景，产品的实现功能会不同。
- 模板方法：同系列的不同产品都有一个相同的功能，冰箱、电饭煲都有一个相同的液晶显示板。
- 观察者模式：订阅者模式，订了份报纸，每天都能收到一份。
- 迭代模式： 对于各种各样的物品集合，总是能按照定义的顺序将物品取出。
- 责任链模式：对于发生的问题，总是能一层层向上汇报寻求能够决策处理人员。
- 命令模式：管理者模式，管理者只管发号施令，具体工作由责任人负责完成。
- 备忘录模式：回滚模式，记录每一步的修改内容，并可以随时回滚或前移。
- 状态模式：恋爱模式，对方的回应取决于对方当下的心情。
- 访问者模式：追星模式，歌迷见到歌星可能会表现出各种不同的行为。
- 中介者模式：自如模式，房东与租客可以互不见面，所有的交易活动由中介进行协调。
- 解释器模式：翻译模式，将一段外文进行翻译并按要求执行。
第七，朝着理想模式，划分出一小块，按照各语言的重构原则进行代码重构。
第八，自动化覆盖核心功能
第九，增加单元测试代码
第十，保留原有老代码，对比新老代码的结果
第十一，持续进行后续优化
第十二，重复第一步。
以上，就是比较稳妥的在敏捷中采用用户故事进行功能重构的方法。
网友评论