【合纵连横】
【合纵】
架构重构是大动作，持续时间比较长，而且会占用一定的研发资源，包括开发和测试，因此不可避免的会影响业务功能的开发。因此，要想真正推动一个架构重构项目启动，需要花费大量的精力进行游说和沟通。注意这里我不是指要谈办公室政治，而是指要和利益相关方沟通好，让大家对于重构能够达成一致共识，避免重构过程中不必要的反复和争执。
道理很简单，但如何做才是关键！
一般的技术同学谈到架构重构的时候，就会搬出一大堆技术术语：可扩展性、可靠性、性能、耦合、代码很乱。。。。。。但以我的实际经验来看，如果和非技术同学这样沟通，效果如同鸡同鸭讲，没有技术背景的同学很难理解，甚至有可能担心我们是在忽悠TA。例如：
技术同学说：我们系统现在的可扩展性太差了，改都改不动！
产品同学想：咦，可扩展性，和扩胸运动有关么？。。。。。扩展什么呢，怎么会改不动呢，不就是找个地方写代码嘛。。。。。。
技术同学说：我们的可靠性太差，现在才3个9，业界都是4个9！
项目经理想：啥是3个9，三九感冒灵？。。。。。。4个9和3个9不就是差个9嘛，和可靠有什么关系。。。。。。
技术同学说：我们系统设计不合理，A业务和B业务耦合！
运营同学想：咦，耦合，莲藕还是藕断丝连？。。。。。。A业务和B业务本来就是互相依赖的呀。。。。。。耦合为什么不合理呢？。。。。。
以上的样例并无嘲笑产品运营和项目同学不懂技术的意思，而是说明有的技术术语并不是很好理解，在跨领域沟通的时候，很难达成一致共识。
除此以外，在沟通时还经常遇到的一个问题是凭感觉而不是凭数据说话。比如说：技术同学说“系统耦合导致我们的开发效率很低”，但是没有数据，也没有样例，单纯这样说，其他同学很难有直观的印象。
所以在沟通协调的时候，将技术语言转换为通俗语言，以事实说话，以数据说话，是沟通的关键！
以M系统为例，我们把“可扩展性”转换为“版本开发速度很慢，每次设计都要考虑是否对门户有影响，是否要考虑对其它业务有影响”，然后我们还收集了1个月里面的版本情况，发现有几个版本设计阶段讨论1周甚至2周时间，但开发只有2天时间；而且一个月才做了4个版本，最极端的一个版本，讨论2周，开发2天，然后等了1个月才和门户系统一起上线，项目经理和产品经理一听都被吓到了。
以S系统为例，我们并没有直接说可靠性是几个9，而是整理线上故障的次数、每次影响的时长，影响的用户，客服的反馈意见等。。。。。。然后再拿其它系统的数据一对比，无论是产品还是项目还是运营，明显就看出系统的可靠性有问题了。
当然，如果以上技巧还不奏效，或者遇到极端情况，那就要考虑一些更加有效的手段了！比如说我们遇到一个产品人员，他认为技术优化和架构重构是研发的事情，他不关注，安排开发资源的时候也不考虑重构和优化的投入，要研发自己解决！没办法，只能上升到上级领导层面协调，甚至我们都放出狠话“如果你不同意安排资源进行优化，下次出故障我们就说产品不给人力进行优化和重构”。
【连横】
除了以上讨论的和上下游沟通协调外，有的重构还需要和其它相关或者配合的系统的沟通协调。由于大家都是做技术的，有比较多的共同语言，所以这部分的沟通协调其实相对来说要容易一些，但也不是说想推动就能推动的，主要的阻力来自“这对我有什么好处”和“这部分我这边现在不急”。
对于“这对我有什么好处”这个问题，有的人会简单理解为这是自私的表现，认为对方不顾大局，于是沟通的时候将问题人为拔高，例如“你应该站在部门的角度来考虑这个问题”、“这对公司整体利益有帮助”。。。。。。等等。这种沟通效果其实很差，首先是这种拔高一般都比较虚，没法明确，不同的人理解不一样，无法达成共识；其次是如果对公司和部门有利，但对某个小组没用甚至不利，那么可能是因为目前的方案不够好，还可以考虑另外的方案。
那如何才能有效的推动呢？我们的策略是“换位思考、合作双赢、关注长期”。简单来说就是站在对方的角度思考，重构对他有什么好处，能够帮他解决什么问题，带来什么收益。
以M系统为例，当时有另外一个C系统和M系统通过数据库直连共用数据库，我们的重构方案是要去掉两个系统同时在底层操作数据库，改为C系统通过调用M系统接口来写入数据库。这个方案对C系统来说，很明显的一点就是C系统短期的改动比较大，要将10几个读写数据库的地方改为接口调用，刚开始C系统也是觉得重构对他们没有什么作用，后来我们经过分析和沟通，了解到C系统其实也深受目前这种架构之苦，主要体现在“数据经常出错要排查”（因为C系统和M系统都在写同一个数据库，逻辑很难保证完全一致），“要跟着M系统同步开发”（因为M系统增加表或者字段，C系统要从数据库自己读取出来，还要理解逻辑）、“C系统要连两个数据库，出问题不好查”（因为C系统自己还有数据库）。。。。。。这些问题其实在M系统重构后都可以解决，虽然短期内C系统有一定的开发工作量，但从中长期来看，C系统肯定可以省很多事情，例如：数据问题排查主要是M系统的事情了，通过M系统的接口获取数据，无需关注数据相关的业务逻辑等等。通过这种方式沟通协调，C系统很乐意跟我们一起做重构，而且事实也证明重构后对C系统和M系统都有很大好处。
当然如果真的出现了对公司或者部门有利，对某个小组不利的情况，那可能需要协调更高层
级的管理者才能够推动，平级推动是比较难的。
对于“这部分我们现在不急”这个问题，有的人可能会认为这是在找借口问题，我也不排除这种可能性。但就算真的是找借口，那也是因为大家没有达成一致意见，可能对方不好意思直接拒绝。所以这种情况就可以参考上面“这对我有什么好处”这个问题的处理方法来处理。
如果对方真的是因为有其它更重要的业务，此时勉为其难也不好，还是那句话：“换位思考”！因为大部分重构的系统并不是到了火烧眉毛非常紧急的时候才开始启动的，而是有一定前瞻性的规划，如果对方真的有其它更加重要的事情，采取等待的策略也未尝不可，但要明确正式启动的时间，例如3个月后开始、6月份开始，千万不能说“以后”、“等不忙的时候”这种无法明确的时间点。
除了计划上灵活一点，方案上也可以灵活一点：我们可以先不做这个系统相关的重构，先把其它需要重构的做完。因为大部分需要重构的系统，需要做的事情很多，分阶段处理，在风险规避、计划安排等方面更加灵活可控。