上一期我给你讲了我的架构重构内功心法的第一式：有的放矢，需要架构师透过问题表象看到问题本质，找出真正需要通过架构重构解决的核心问题，而不是想着通过一次重构解决所有问题。
合纵
架构重构是一个耗时较长、资源需求较大的项目，包括开发和测试资源的占用。因此，为了顺利启动架构重构项目，需要大量的沟通和说服工作。这不仅仅是办公室政治，而是要与利益相关方充分交流，达成共识，避免过程中出现反复和争执。
通常，技术人员在谈论架构重构时会使用许多技术术语，如可扩展性、可用性、性能、耦合等。然而，对于非技术人员来说，这些术语难以理解，甚至可能会产生误解和担忧。
例如：
技术人员说：我们系统的可扩展性太差了，改都改不动！非技术人员可能会想：什么是可扩展性？为什么改不动？
技术人员说：我们的可用性太差，现在才3个9，业界都是4个9！非技术人员可能会想：3个9和4个9有什么区别？这和可用性有什么关系？
技术人员说：我们系统设计不合理，A业务和B业务耦合！非技术人员可能会想：A业务和B业务本来就应该有关联，耦合为什么不合理？
这些场景只是示例，并非嘲笑非技术人员不懂技术。在跨领域沟通时，技术人员需要将技术术语转换为通俗易懂的语言，并用数据和事实说话，这是沟通的关键。
此外，沟通时要避免凭感觉而不是凭数据说话。例如，技术人员可以通过数据证明系统耦合导致的开发效率低下，而不仅仅是空谈。
因此，架构师在进行沟通和协调时，需要注意将技术语言转换为通俗语言，以数据和事实说话，这样才能有效地与非技术人员沟通。
在这种背景下，架构师还应了解非技术人员的主要关注点，例如成本控制、业务需求和用户体验。通过将技术改进的好处与这些关注点挂钩，可以更容易地争取到他们的支持。例如，改进系统的可扩展性不仅能提升性能，还能减少未来扩展的成本，避免频繁的停机和维护，从而提升用户体验。
连横
除了与上下游系统的沟通协调，有些重构项目还需要与其他相关或配合的系统进行沟通。由于大家都是技术人员，有较多共同语言，这部分的沟通相对容易一些，但也不是说想推动就能推动的，主要的阻力来自于“这对我有什么好处”和“这部分我这边现在不急”。
对于“这对我有什么好处”的问题，有的人可能会简单理解为自私的表现，认为对方不顾大局。这种沟通效果很差，因为这种拔高一般都比较虚，不同人理解也不一样，无法达成共识。有效的策略是“换位思考、合作双赢、关注长期”，即站在对方的角度思考，看重构对他们有什么好处，能解决什么问题，带来什么收益。
在沟通协调时，还经常遇到凭感觉而不是凭数据说话的情况。技术人员可以提供数据支持，说明系统耦合导致开发效率低下，而不只是空谈。
举例来说，我们曾遇到一个系统 C 与系统 M 直接共用数据库的问题。我们的重构方案是改为系统 C 通过调用系统 M 的接口来写入数据库。起初，系统 C 认为重构对他们没有好处。但经过分析和沟通，发现系统 C 也受到目前架构的困扰，例如数据经常出错、要跟着系统 M 同步开发、要连两个数据库等。这些问题在重构后都可以得到解决。通过这种沟通方式，系统 C 也愿意参与重构，并且事实证明重构后对系统 C 和系统 M 都有很大好处。
对于“这部分我们现在不急”的问题，有的人可能认为这是找借口。但如果真的出于其他更重要的业务考虑，就需要灵活处理。可以先不做这个系统的重构，先把其他需要重构的做完。总之，灵活的计划安排和方案调整是推动重构项目的关键。
在实际操作中，灵活的项目管理和分阶段的实施策略尤为重要。可以通过将重构项目分解为多个子项目，逐步推进，降低风险。例如，先进行一些低风险、见效快的重构任务，积累成功经验和信心，然后再逐步推进更复杂的重构任务。
这是一项至关重要的工作，所以要认真学习。首先，要学会换位思考，站在对方的角度理解问题，看看重构对他们有什么好处，能解决什么问题。其次，要强调合作双赢，说明重构不仅对整体有利，也会带来他们的收益。最后，要关注长期发展，强调重构是为了解决现有问题，为未来的发展打下良好基础。通过这些方式，你可以更好地与其他团队合作推动重构项目。
此外，建立透明的沟通机制和反馈渠道也很重要。定期的项目会议、阶段性汇报和公开的进展跟踪可以让所有利益相关方保持同步，及时解决问题和调整计划，确保项目的顺利推进和最终成功。