能不能聊聊那些年你重构过的代码？
聊聊我曾经接手过的一个订单业务系统，有对接过三方或四方支付的开发同学相信你们都知道他的逻辑主流程都是一致的，基本上就是下面这样的一个大致流程：
这个流程里面因支付方式变化的就是：
- 向支付平台发起预付款请求；
- 三（四）方支付回调。
这个世界上有很多种支付方式，国内大家最熟悉的三方支付就是支付宝和微信，还有拉卡拉，这是属于三方支付的范畴。还有很多的四方聚合支付，比如京东数科、收钱吧、爱贝、哆啦宝。如果放眼国外，那就更多了，支付通道的API文档也是五花八门。
当时我接手的代码已经接入了七八家支付公司了，代码也是接一家支付就写一套上面的流程，每个支付的Service里面都是一堆业务判断，然后再创建订单信息，然后再调用各自的支付通道发起预付款请求，大致是这个意思：
相信大家看到上面的伪代码就已经知道问题了，就是每次再来一次支付就得写一次这样的代码，他会有几个问题：
- 大量的重复代码，新的支付方式进来后只能是粘贴、复制相同的代码；
- getProductInfo()、generateOrderNum()、createUserOrder()方法只要有代码或者业务变动，就得改所有的支付通道服务，意味着影响范围就是所有的支付方式，测试自然得回归测试所有的支付方式。
相信大家在平时开发中都或多或少的遇到过这种代码，甚至为了赶工期也写出了这样的代码，但是你是否想过什么时候去重构它呢？这才是要命的问题。
很多时候，我们第一次的设计写出来的代码往往代表的是最高的质量。随着业务的不断变动，加之业务方开发工期的步步紧逼，后面的代码是越来越差，越来越惨不忍睹而到最后难以维护，堆成屎山。
如何重构？
相信大家看到这里都有自己的重构方案了，基本原则就是把“变的”和“基本不变”的独立出来，那什么是变化的部分？基本不变的又是哪部份？分析清楚了基本上就可以得到下面的这种方案：
这样去设计的话，如果这个时候需要对接一个新的支付通道，我是不是只需要再针对特定的支付通道写一个XxxPayService和XxxAdapter就可以了，而且对其他任何服务都没有影响。
大家可以看到这个里面我加入了适配器，其实是为了屏蔽外部系统（支付服务）的变化对内部系统（订单服务）的影响，例如支付宝的支付接口发生了变更，我是不是只要变更一下AliPayAdapter这个类就可以了？而不会影响到其他的支付方式？
反过来看，如果订单服务有业务规则变化，是不是也对支付通道相关服务不影响？
这样就可以做到，日后不论业务如何变更，需要改动的代码范围缩小了，也就意味着扩展性高了。
写在最后
个人意见，大家对自己写过的代码还是要多回头去看看，去思索并不断重构优化，这其实就是大家平常总说的总结、沉淀。否则我们只能沉沦于业务而最终无法获得成长。
上大学时，C语言上机课，给同学修改不能编译和运行有问题的程序。老师的作业是随便写个50行左右的程序，自己选择是干嘛的，就是内容随意了，不能和别人一样。
有个女同学写了100多行的让我修改，是一次噩梦，几乎每一行都有语法错误，并且逻辑也是错的。然后就是我按照她说的逻辑重新敲了代码。我不能理解的是什么让她坚持敲了100多行，完全错误的代码。
要问为什么要帮？我写得快，找我帮忙的都帮了。
之前公司做地图导航用的自研引擎，后面由于车厂的需求，换成了高德的。但是保不齐，以后又要换回，甚至可能引入腾讯、百度、四维等图商的接口。为了一套框架适配多种引擎，采用adapter的设计模式，中间多了adpater层，用以对底层引擎的调用和组装，对上层js的接口保持一致，所以并集出来的接口函数及其参数有些空实现，但基本达到适配多种的目的
谢邀！2015年时候当时比较火的项目是营销路由器，就是公共场所免费提供Wi-Fi上网，但是需要认证才能上网，有的看几秒广告，有的关注某个公众号等。
有一套后台管理系统，而且这套管理系统还包含认证系统，当时公司就在网上找了一套免费的系统，用thinkphp开发的，改改版开始招商。
招来的小代理商前期使用量小了一点问题都没有，后来几个大代理进来，量大起来各种问题都来了，服务器cpu总是被打爆，没有办法只能加服务器临时解决问题。因为当时只懂得curd，对路由器认证那方面完全陌生，后来开始尝试自己编译路由器固件，稍微深入了解其实也不是很难，路由器固件都是开源的openwrt固件，认证也是开源的wifidog模块，客户端连接Wi-Fi后wifidog模块会重定向到认证服务器。
重点来了手机端有很多app（例如像高德、滴滴等等）后台服务不停地联网打到认证服务器，所以认证服务器压力相当大，php处理一个连接请求就要启动一个进程，所以cpu会打爆。后来用nodejs把认证服务给抽离出来了，同时也把服务器数量给降下来了。没有黑编程语言的意思，每种语言都有各自擅长的领域。
代码重构好难聊，多看看设计模式，有时候碰到一些跟你想法一致的前辈就会觉得很开森^_^，但是更多的是想骂娘，边改边骂那种。
作为一名工作将近20年的老程序员，现在还在写代码，说的好听一点叫“笔耕不辍”，难听的就不说了，说出来都是泪，对于重构代码，总有很多要吐槽的经历。
资深的老程序员，不在于他写代码的速度有多快，更多的时候是注重对用户需求的理解和对新程序员代码的管理。特别是看着好多新手程序员写的代码，往往恨不得自己重新写一遍。但是在软件工程时代，这个想法是不现实的。所以更多的时候是对这些代码进行局部的重构。
说的具体一点，从一段代码到一个功能模块，有的时候第一个版本的代码往往思路不清晰，结构很混乱。老程序员在运行功能的时候发现bug，总会深入的去看其他人写的代码，这个时候，顺利的情况是修改掉小的bug，事情就结束了。不刻意的时候可能需要对代码的结构作调整，甚至和程序员商量，按照新的思路和算法重写一份。
这几年主要的工作都是维护和升级SaaS云系统，在延誉宝这个平台下，最早期的商品管理和订单管理的基本逻辑被继承下来了，但是上面追加的新的功能需求，随着时间的推移在不断地推陈出新。因此经常发现原有的业务逻辑不能满足新的有需求。但是由于形成的用户数据库非常大，更改数据库表结构基本不现实，而且会出现系统的短暂中断，这是不能接受的。所以能够做的就是重构，封装和二次开发。
以这个供货商系统为例，既要保持原有的商品陆续库结构的稳定，又要适应不同的商品可能来自不同的供货商。在前端用户下单之后，如果这个商品来自供货商，还需要对订单做自动拆单，这个重构的过程非常漫长，至今还有与一些潜藏的bug。