专栏名称: 凤凰牌老熊
互联网金融，软件架构，资深Java工程师
目录
相关文章推荐
芋道源码  ·  为什么王者荣耀不使用微服务架构？ ·  昨天  
芋道源码  ·  Guava的这些骚操作，让我的代码量减少了50% ·  昨天  
芋道源码  ·  Web 实时消息推送的 7 种实现方案 ·  2 天前  
芋道源码  ·  后端行情变了，差别真的挺大。。。 ·  3 天前  
芋道源码  ·  为什么很多程序员讨厌低代码？ ·  3 天前  
51好读  ›  专栏  ›  凤凰牌老熊

重构中的外部准备工作

凤凰牌老熊  · 公众号  · Java  · 2017-03-07 00:19

正文

技改在任何时候都是个敏感的事情。大量的问题需要摆平，天时地利人和，缺一不可。

天时

即选择合适时机进行技术改造工作。在时机的选择上，我们经历了三个阶段。

空闲时段
在开发企业应用时，技术改进也是常见的工作。企业应用开发的特点是有忙有闲。在版本发布前都紧锣密鼓进行开发工作；在老版本发布之后，新版本刚刚启动开发时，有相对空闲时间，可以进行技术改进。 而当这一套方法搬到互联网应用开发上时，却发现基本行不通。互联网应用开发是两种情况：很忙和非常忙。预留大片的时间进行技术改进，几乎是不现实的。如果有业务可以有空闲时间做技改，那基本上也就没必要改了，因为这也意味着这个业务进入稳定和衰退期。

随需改进
既然找不到空闲时段，另一个选择是随需进行，也就是在项目开发过程中，对涉及到的模块进行改进。而在实践中，我们也发现这种做法难度很大。

  1. 遗留系统的模块依赖关系往往令人匪夷所思，改进过程中，经常会发现需要对所依赖的底层模块进行大调整，导致改进工作无法进行。

  2. 就算是所依赖的模块没有问题，改进工作也会导致更多的时间开销，2~3倍都是正常的。这个延迟不是所有项目都能够承受的。

优化团队
比较适合互联网应用开发的做法，是组建专门团对进行技术改进。预留大约30%的开发能力来进行技改。这些人可以是专门负责架构改进的，也可以从项目组中抽调轮岗。

  1. 改进前，制定改进计划，循序将近进行。涉及到具体模块改进时，抽调负责该模块的技术人员来参与。

  2. 如果模块改进和业务开发工作同时开展，则可以考虑将这两个工作合并进行。

技改不能一哄而上，也不能蜻蜓点水的做。他是一个持续的过程，循序将近，不要中断。项目紧的时候挑选风险小的任务来执行，少安排几个重构点。项目松的时候重构下核心接口，多安排些重构。但是不要中断。 一旦中断，往往结果是没有人会愿意继续。重构往往是个前人栽树 后人乘凉的事，风险又大，短期看不到效果，大家做着做着，往往就放弃了。所以持续改进是必须的，避免半途而废。

还有一个大家容易忽略的地方，对于特别看重绩效的团队，按照产出来度量工作成果，那必须果断避开绩效考评的这段敏感时期。

地利

所谓地利，从软件角度，主要是基础设施的建设。在针对现有系统进行改进，推动微服务架构前，需要评估下当前的基础设施建设是否能够满足要求。 服务所需要的基础设施包括:

虚机环境或者docker
不同服务的线上压力和运行环境需求不同，内存，CPU，磁盘需求也不一样。按照服务需要自动弹性创建所需要的环境，是微服务部署的前置条件。







请到「今天看啥」查看全文


推荐文章
芋道源码  ·  为什么王者荣耀不使用微服务架构？
昨天
芋道源码  ·  Guava的这些骚操作，让我的代码量减少了50%
昨天
芋道源码  ·  Web 实时消息推送的 7 种实现方案
2 天前
芋道源码  ·  后端行情变了，差别真的挺大。。。
3 天前
芋道源码  ·  为什么很多程序员讨厌低代码？
3 天前
潘幸知  ·  控制狂，不能嫁
8 年前
优秀网页设计  ·  对不起，今天的设计稿我必须过！
8 年前
科尔沁都市报  ·  好消息！内蒙古政府发通知，要增加城乡居民收入！看看都有哪些惠民政策……
7 年前
人民日报  ·  【荐读】运气好的人有个共同点
7 年前
众视DVBCN  ·  【专访】国广东方全方位布局OTT广告！携手合作方共同挖掘百亿市场
7 年前
Sov5搜索   ·   小百科   ·   今天看啥   ·   移动版
51好读 - 好文章就要读起来!