架构重构是一场战役，而非一次编程练习。
如果说"有的放矢"是这场战役的战略核心——明确要打什么；那么"穿针引线"就是这场战役的战术精华——在项目开发环境中，你怎么推动大家和你一起干活
当你确定了需要重构的系统，找到了要解决的核心问题，满怀信心地准备开始时，现实往往给你浇一盆冷水：业务团队说没时间、配合团队说优先级不够、产品经理说重构不如做新功能……
此时，技术沟通能力成为决定成败的关键因素。架构师不仅是技术专家，更应该是技术"销售"——将技术价值用非技术人员能理解的语言传达出去，争取资源和支持。
今天，我们来修炼架构重构内功心法的第二式：穿针引线。
架构重构是大动作，持续时间长，占用研发资源，必然影响业务功能开发。要推动重构项目启动，需要花费大量精力进行游说和沟通——这里说的不是办公室政治，而是与利益相关方充分沟通，确保大家对重构达成一致共识。
所谓穿针，每个角色都有自己的工作安排，你如何找到你这个事情的落脚点，让相关人员都觉得自己是这件事情的利益相关方
技术人员和非技术人员沟通时，经常搬出一大堆技术术语。但从过往经验看，这样沟通效果往往很差——对方听不懂，甚至可能怀疑你在忽悠人。
看看这些典型的"鸡同鸭讲"场景：
场景一
场景二
场景三
技术术语在跨领域沟通时很难达成共识。有效的沟通需要做到：以事实说话，以数据说话。
以智能门锁的按键响应为例，我们没有直接说“中断延迟太高，中断服务程序耗时过长”，而是整理了：
产品经理和项目经理一看，立刻意识到问题的严重性——这才是真正影响用户体验的核心问题。
以系统稳定性为例，我们没有直接说“出现优先级翻转，任务调度异常”，而是整理了：
项目经理和客户一看，系统的稳定性差距一目了然，立刻同意投入资源进行优化
除了和上下游沟通协调，有的重构还需要和其他配合系统的团队沟通协调。由于大家都是技术人员，共同语言多，这部分沟通相对容易，但阻力同样存在，主要来自两个问题：
有的技术人员会简单将对方的疑虑理解为自私，认为对方不顾大局，于是把问题拔高："你应该站在部门角度考虑"、"这对公司整体利益有帮助"……
这种沟通效果很差。首先，这种拔高太虚，无法明确，不同人理解不一样，无法达成共识。其次，如果方案对公司有利但对某小组没用甚至不利，那可能当前方案本身就不够好，需要考虑其他方案。
有效的策略是：换位思考、合作双赢、关注长期。
站在对方角度思考：重构对他有什么好处？能够帮他解决什么问题，带来什么收益？
以某工业网关项目为例，当时Linux主系统（A53核）与实时控制程序（M7核）通过共享内存直接读写数据。我们的重构方案是：引入RPMsg通信协议，将共享内存改为标准化的消息队列传输，实现异构双系统协同。
对实时控制程序团队来说，短期内改动较大——原有的指针直接访问要改为消息发送/接收，十几个传感器数据处理流程都要调整。刚开始他们觉得重构对他们没什么作用，反而增加了代码复杂度。
后来我们了解到，实时控制团队其实也深受现状之苦：
这些问题在引入RPMsg通信后都可以解决。虽然短期内实时控制团队有一定工作量，但从中长期看，他们省了很多事情——数据隔离由硬件机制保证，无需担心内存越界；通信接口标准化，无需关注Linux侧的内存布局变化；出现问题时可以通过消息日志快速定位，责任边界清晰。
通过这种方式沟通协调，实时控制团队很乐意一起做重构。事实也证明，重构后对双方都有很大好处——系统稳定性提升，故障排查时间从平均2天缩短到2小时，后续功能迭代效率也大幅提升。
当然，如果真的出现对公司或部门有利但对某小组不利的情况，可能需要协调更高层级的管理者才能推动。
有的时候，对方的推辞是因为确实有更重要的事情。此时勉为其难也不好——还是那句话：换位思考。
大部分重构并不是火烧眉毛才启动的，而是有一定前瞻性的规划。如果对方真的有更重要的事，采取等待策略也未尝不可，但要明确正式启动的时间，如"3个月后开始"、"6月份开始"，千万不能说"以后"、"等不忙的时候"这种无法明确的时间点。
方案上也可以灵活：先不做这个系统相关的重构，先把其他需要重构的做完。分阶段处理，在风险规避、计划安排等方面更加灵活可控。