46 | 架构重构内功心法第二式：合纵连横

Aug 11, 2018

46 | 架构重构内功心法第二式：合纵连横-极客时间



下载APP





关闭

讲堂部落提薪训练营云原生训练营架构实战营企业版极客商城兑换中心 App下载浏览器插件

渠道合作

推荐作者

46 | 架构重构内功心法第二式：合纵连横

2018-08-11 李运华来自北京

《从0开始学架构》

课程介绍



讲述：黄洲君

时长07:56大小3.63M



上一期我给你讲了我的架构重构内功心法的第一式：有的放矢，需要架构师透过问题表象看到问题本质，找出真正需要通过架构重构解决的核心问题，而不是想着通过一次重构解决所有问题。
今天我来传授架构重构内功心法的第二式：合纵连横。
合纵架构重构是大动作，持续时间比较长，而且会占用一定的研发资源，包括开发和测试，因此不可避免地会影响业务功能的开发。因此，要想真正推动一个架构重构项目启动，需要花费大量的精力进行游说和沟通。注意这里不是指办公室政治，而是指要和利益相关方沟通好，让大家对于重构能够达成一致共识，避免重构过程中不必要的反复和争执。
一般的技术人员谈到架构重构时，就会搬出一大堆技术术语：可扩展性、可用性、性能、耦合、代码很乱……但从过往的实际经验来看，如果和非技术人员这样沟通，效果如同鸡同鸭讲，没有技术背景的人员很难理解，甚至有可能担心我们是在忽悠人。
例如：
技术人员说：我们系统现在的可扩展性太差了，改都改不动！
产品人员想：咦，可扩展性，和扩胸运动有关吗？扩展什么呢？怎么会改不动呢？不就是找个地方写代码嘛……
技术人员说：我们的可用性太差，现在才 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 系统短期的改动比较大，要将十几个功能都从直接读写数据库改为跨系统接口调用。刚开始 C 系统也是觉得重构对他们没有什么作用，后来我们经过分析和沟通，了解到 C 系统其实也深受目前这种架构之苦，主要体现在“数据经常出错要排查”（因为 C 系统和 M 系统都在写同一个数据库，逻辑很难保证完全一致）、“要跟着 M 系统同步开发”（因为 M 系统增加表或者字段，C 系统要从数据库自己读取出来，还要理解逻辑）、“C 系统要连两个数据库，出问题不好查”（因为 C 系统自己还有数据库）……这些问题其实在 M 系统重构后都可以解决，虽然短期内 C 系统有一定的开发工作量，但从中长期来看，C 系统肯定可以省很多事情。例如，数据问题排查主要是 M 系统的事情了，通过 M 系统的接口获取数据，无须关注数据相关的业务逻辑等。通过这种方式沟通协调，C 系统很乐意跟我们一起做重构，而且事实也证明重构后对 C 系统和 M 系统都有很大好处。
当然如果真的出现了对公司或者部门有利，对某个小组不利的情况，那可能需要协调更高层级的管理者才能够推动，平级推动是比较难的。
对于“这部分我们现在不急”问题，有的人可能会认为这是在找借口，我也不排除这种可能性。但就算真的是找借口，那也是因为大家没有达成一致意见，可能对方不好意思直接拒绝。所以这种情况就可以参考上面“这对我有什么好处”问题的处理方法来处理。
如果对方真的是因为有其他更重要的业务，此时勉为其难也不好，还是那句话：换位思考！因为大部分重构的系统并不是到了火烧眉毛非常紧急的时候才开始启动的，而是有一定前瞻性的规划，如果对方真的有其他更加重要的事情，采取等待的策略也未尝不可，但要明确正式启动的时间。例如，3 个月后开始、6 月份开始，千万不能说“以后”“等不忙的时候”这种无法明确的时间点。
除了计划上灵活一点，方案上也可以灵活一点：我们可以先不做这个系统相关的重构，先把其他需要重构的做完。因为大部分需要重构的系统，需要做的事情很多，分阶段处理，在风险规避、计划安排等方面更加灵活可控。
小结今天我为你讲了架构重构中的沟通和推动方法，希望对你有所帮助。
这就是今天的全部内容，留一道思考题给你吧，有的人认为：架构师不是技术岗位吗，为何还要做这些事情，沟通和推动的事情让项目经理做就可以了！你怎么看这个观点？
欢迎你把答案写到留言区，和我一起讨论。相信经过深度思考的回答，也会让你对知识的理解更加深刻。（编辑乱入：精彩的留言有机会获得丰厚福利哦！）

分享给需要的人，Ta购买本课程，你将得20元

生成海报并分享

赞 11

提建议

45 | 架构重构内功心法第一式：有的放矢

47 | 架构重构内功心法第三式：运筹帷幄

 写留言

精选留言(38)

李奋斗
2018-08-11
1 需求相对明确，周期明确，项目经理去沟通比较合适；架构重构，可深可浅，能宽能窄，亦长亦短，有很多不确定的东西，在沟通中又有很多技术专业性、细节性的东西，架构师去合适 2 按时交付项目是项目经理的主要诉求，架构合理演进是架构师的主要诉求 3 架构重构，有时候项目经理也在被游说的范围内
作者回复: 非常正确，架构重构的很多事情技术性太强，只有架构师能够讲清楚
共 3 条评论
81
海滨
2018-08-13
首先项目经理是对项目整体进度负责的，从职责上来看项目经理大多是反对系统重构的，因为重构或多或少会影响项目进度；其次就算有少部分项目经理有较高的思想觉悟，由于对当前系统重构的必要性和痛点认知的不够深刻，也很难大力的去推进系统重构。对于系统重构感受最深，需求最强烈的是谁？是架构师，架构不合理开发痛苦，架构师就会被责难，因此架构师最有动力也最适合去推进系统重构。
作者回复: 理解深刻，你是有故事的人吧😄
共 2 条评论
35
文竹
2018-08-26
之前有看到老师评论说架构师需要具有5项技能, 一下子找不到了，请问这5项是？由于架构重构是与纯技术相关的，项目经理很难理解技术，并将技术转换为通俗易懂的话。如果架构师负责转换技术为易懂话语，项目经理进行游说和推动，中间会有更大的沟通成本和信息不同步问题，交由架构师闭环处理为佳。
作者回复: 应该是：沟通，判断，技术，管理，决策这几个吧😀
19
Adun Ton
2018-08-12
李老师这两期讲重构方面的内功心法，非常经常和有收获。讲一下自己遇到的几个案例： 1. 有一个健康的外部环境很重要，之前一家公司销售跟客户过度承诺，同时展开软件项目的客户又多，所有的研发资源都消耗在这些项目上，应付时间点和需求变更都很吃力，完全没有精力做重构，造成恶性循环，代码质量越来越差，随着人员流动产品里面谁都不知道干嘛的代码越来越多； 2. 有一个懂技术的老大很幸运，之前另一家公司，产品做到一定规模需要安排时间做重构，跟老板和销售负责人沟通如果不做重构，后面新功能开发和架构改造容易产生问题，得到的答复是你们研发团队的工作就是做好开发工作，优化的这些事情要在周期内完成，完不成就加班做，让大家积极性受打击； 3. 跟非技术部门沟通有时可能简单粗暴一些效果反而比较好。跟非技术部门沟通有时不容易，比如工程、销售团队。你问预期的访问量多少，答曰系统能支持的越高越好，你问希望交付的时间，答曰越快越好。后来索性做个表格，关键功能和性能参数后面直接关联对应的时间，你自己选，自动加出来一个包含一定缓冲的人日，低于这个时间实现不了，这样还能更简单的在这些方面达成一致。
展开
作者回复: 第2是关键，有了2，其它都好说，我们也遇到你说的情况，原话：技术优化是你们自己考虑的事情，我只管业务实现😂😂
共 4 条评论
18
孙振超
2018-10-08
架构师是技术岗位，但想把新架构设想落地就需要工程师去实施，如果自己同时带团队并且只需要自己团队的工程师去参与就比较容易；如果自己只有建议权、还需要其他团队配合的情况下，就要发挥各种软实力了，合纵连横、见缝插针、各种布道游说，才能把架构落地，要不然空有一肚子才华无法开花结果。
作者回复: 架构师要求高啊😄
9
lecury
2018-08-12
感觉这章写的很好，现在也在慢慢体会到这个道理了，要以数据为导向，要给出明显的收益，不然做了也是瞎做。。。现在做方案设计的时候，都会阐述业务背景，分析现状的不足之处，给出多种方案选择，成本效率的折中，定下方案，给出预期收益～
作者回复: 沟通就是要让人看得懂嘛😄
9
JasonZ
2019-01-13
李老师，最近遇到一个架构问题。我们是微服务架构。有一个配置中心A系统。现在所有的上层系统都是依赖这个A系统。导致A系统的压力加大，一旦A系统被某一个sql拖垮了，导致上游系统接口超时。影响全局。那应不应该把读DB的请求让上游的系统自己去捅库？还有应该全部调用A系统接口？
作者回复: 配置中心可以做成读写分离的，因为配置不会经常边
共 2 条评论
6
krugle
2018-08-13
soa还有必要学习吗
作者回复: 不建议，传统企业的技术也向互联网靠拢了
共 2 条评论
7
钱
2019-09-05
课后思考及问题架构师不是技术岗位吗，为何还要做这些事情，沟通和推动的事情让项目经理做就可以了！你怎么看这个观点？我所见的事实和华仔讲的恰恰相反，这可能和小组结构和角色定位相关。我们架构师，主要工作据我了解如下：第一代码评审，除页面外基本都让他看看写的是否OK 第二疑难问题解决，各种奇怪问题可以找他一起看第三技术选型支持，提供方案供领导选择第四大促或者平时基础架构部推动的事情，他分配到各组执行第五人员面试，一面是高工，他主要负责二面第六对外撕技术方案提供，比如：部门间合作有些事让我们做，他需要判断具体方案是否可行第七技术探索，如果要用新技术他会先实验实验，调研一下，宣讲一下，然后交给具体人员实施我的观点是视情况而定，技术相关的事情架构可以推动沟通，不过其他的事情比如：啥时候联调，啥时候上线，需要项目经理来推动沟通了。合纵连横的合作技巧是通用的，不过具体是谁负责，是事环组过来决定的。 1：本文核心观点老师你太逗啦！列举的场景能让我笑一个早上😊 1-1：合纵——我的理解是，统一战线，将朋友搞得多多的，敌人弄得少少的，越多人支持一件事越容易搞定。沟通技巧——在沟通协调时，将技术语言转换为通俗语言，以事实说话，以数据说话，是沟通的关键！ 1-2：连横——我的理解，其实和合纵本质一样，区别在于结盟的对象不同。拉人技巧——换位思考、合作双赢、关注长期。
展开
作者回复: 项目经理搞不定技术判断和取舍
5
拉欧
2018-09-18
项目经理只能站在项目的角度思考问题，许多技术难点他们既不懂也讲不明白，在对程序员说话时也会出现鸡同鸭讲的情况（我就遇到过）；架构师的职责或者说牛逼在于一个问题，可以从技术角度搞定研发，也可以从业务角度搞定产品
作者回复: 所以架构师工资高，哈哈😄
5
长脖子树
2020-09-22
以事实说话，以数据说话, 换位思考、合作双赢、关注长期这篇很精彩!
作者回复: 看来你应该是有所体会，有的人说这样的文章看起来比较虚��
5
微风
2018-09-29
我能说架构师就是个适配器吗？呃，其实一直认为架构师是个很神圣的岗位：军师。
作者回复: 架构师就是系统的军师😂
4
flyCoder
2020-10-24
在跨职能和部门沟通的工作有比较多的情况很难达到双赢，因为有一些架构优化的工作真的就是针对某个部门单方面受益的，这个时候还是要上升到大部门或者整个公司的利益出发点的。
作者回复: 找老板拍板
2
小胖狗
2018-08-13
架构师的软技能篇。😁😁😁
作者回复: 这只是架构重构用到的，软技能很多，有的读者建议我写另外一个专栏，但我不太会写这类软技能😀
2
张潇赟
2020-12-15
项目经理是负责推进项目进度的，比如一个项目已经确定好方案开始实施后大部分的推进工作应该是pm。但是如果项目的方案还在讨论、项目范围还没有确定，需要说服别人认同某个方案并一起参与进来一定是架构师的职责。
作者回复: 是的，这个说服过程就是架构师能力的体现
1
闻逸
2020-12-03
现在不是产品经理听不懂技术术语，而是搞技术的听不懂产品术语，尤其是说几句就蹦出一个英文单词的，或者中英文夹杂着的
作者回复: 这些都是小case，产品能蹦出的也就是那几个指标英文，你稍微学习一下就会了，例如ROI、DAU、MAU，ARPU等，网上都能查到。
1
谭方敏
2020-03-15
合纵需要跟利益相关方沟通好，让大家对于重构能够达成一致共识，避免重构过程中不必要的反复和动作。在沟通的时候，将技术语言转换为通俗语言，以事实说话，以数据说话，是沟通的关键，需要将问题分解为可以理解和更好沟通的程度。连横换位思考，合作双赢，关注长期。找出共同关注点。架构师是技术岗，在架构重构的过程，是需要很强的技术专业能力的，沟通和推动的时候，大部分是技术语言，并且需要架构师将技术语言转化为通用语言，而这过程是以项目语言为主的项目经理做不了的。
展开
1
J.Smile
2020-02-24
一句话：凡事好商量。两句话：一次把事情做好。
1
Jun
2019-12-22
跨组合作最后一定落实到具体的技术问题，需要架构师在技术层面沟通。产品经理在业务需求上沟通。项目经理在时间计划和优先级层面沟通。
1
波波安
2018-09-05
我感觉问题就在于，都想自己改动调整最少。
作者回复: 确实如此😀😀这就需要架构师的推动能力了
1

