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

精选留言(21)

• 

  李奋斗

  1 需求相对明确，周期明确，项目经理去沟通比较合适；架构重构，可深可浅，能宽能窄，亦长亦短，有很多不确定的东西，在沟通中又有很多技术专业性、细节性的东西，架构师去合适
  2 按时交付项目是项目经理的主要诉求，架构合理演进是架构师的主要诉求
  3 架构重构，有时候项目经理也在被游说的范围内

  作者回复: 非常正确，架构重构的很多事情技术性太强，只有架构师能够讲清楚

  2018-08-11

  

   29
• 

  海滨

  首先项目经理是对项目整体进度负责的，从职责上来看项目经理大多是反对系统重构的，因为重构或多或少会影响项目进度；其次就算有少部分项目经理有较高的思想觉悟，由于对当前系统重构的必要性和痛点认知的不够深刻，也很难大力的去推进系统重构。对于系统重构感受最深，需求最强烈的是谁？是架构师，架构不合理开发痛苦，架构师就会被责难，因此架构师最有动力也最适合去推进系统重构。

  作者回复: 理解深刻，你是有故事的人吧😄

  2018-08-13

  

   9
• 

  Adun Ton

  李老师这两期讲重构方面的内功心法，非常经常和有收获。
  讲一下自己遇到的几个案例：
  1. 有一个健康的外部环境很重要，之前一家公司销售跟客户过度承诺，同时展开软件项目的客户又多，所有的研发资源都消耗在这些项目上，应付时间点和需求变更都很吃力，完全没有精力做重构，造成恶性循环，代码质量越来越差，随着人员流动产品里面谁都不知道干嘛的代码越来越多；
  2. 有一个懂技术的老大很幸运，之前另一家公司，产品做到一定规模需要安排时间做重构，跟老板和销售负责人沟通如果不做重构，后面新功能开发和架构改造容易产生问题，得到的答复是你们研发团队的工作就是做好开发工作，优化的这些事情要在周期内完成，完不成就加班做，让大家积极性受打击；
  3. 跟非技术部门沟通有时可能简单粗暴一些效果反而比较好。跟非技术部门沟通有时不容易，比如工程、销售团队。你问预期的访问量多少，答曰系统能支持的越高越好，你问希望交付的时间，答曰越快越好。后来索性做个表格，关键功能和性能参数后面直接关联对应的时间，你自己选，自动加出来一个包含一定缓冲的人日，低于这个时间实现不了，这样还能更简单的在这些方面达成一致。

  作者回复: 第2是关键，有了2，其它都好说，我们也遇到你说的情况，原话：技术优化是你们自己考虑的事情，我只管业务实现😂😂

  2018-08-12

  

   6
• 

  刘畅

  感觉这章写的很好，现在也在慢慢体会到这个道理了，要以数据为导向，要给出明显的收益，不然做了也是瞎做。。。
  
  现在做方案设计的时候，都会阐述业务背景，分析现状的不足之处，给出多种方案选择，成本效率的折中，定下方案，给出预期收益～

  作者回复: 沟通就是要让人看得懂嘛😄

  2018-08-12

  

   5
• 

  文竹

  之前有看到老师评论说架构师需要具有5项技能, 一下子找不到了，请问这5项是？
  
  由于架构重构是与纯技术相关的，项目经理很难理解技术，并将技术转换为通俗易懂的话。如果架构师负责转换技术为易懂话语，项目经理进行游说和推动，中间会有更大的沟通成本和信息不同步问题，交由架构师闭环处理为佳。

  作者回复: 应该是：沟通，判断，技术，管理，决策这几个吧😀

  2018-08-26

  

   3
• 

  krugle

  soa还有必要学习吗

  作者回复: 不建议，传统企业的技术也向互联网靠拢了

  2018-08-13

  

   3
• 

  孙振超

  架构师是技术岗位，但想把新架构设想落地就需要工程师去实施，如果自己同时带团队并且只需要自己团队的工程师去参与就比较容易；如果自己只有建议权、还需要其他团队配合的情况下，就要发挥各种软实力了，合纵连横、见缝插针、各种布道游说，才能把架构落地，要不然空有一肚子才华无法开花结果。

  作者回复: 架构师要求高啊😄

  2018-10-08

  

   2
• 

  小胖狗

  架构师的软技能篇。😁😁😁

  作者回复: 这只是架构重构用到的，软技能很多，有的读者建议我写另外一个专栏，但我不太会写这类软技能😀

  2018-08-13

  

   2
• 

  JasonZ

  李老师，最近遇到一个架构问题。我们是微服务架构。有一个配置中心A系统。现在所有的上层系统都是依赖这个A系统。导致A系统的压力加大，一旦A系统被某一个sql拖垮了，导致上游系统接口超时。影响全局。那应不应该把读DB的请求让上游的系统自己去捅库？还有应该全部调用A系统接口？

  作者回复: 配置中心可以做成读写分离的，因为配置不会经常边

  2019-01-13

  

   1
• 

  拉欧

  项目经理只能站在项目的角度思考问题，许多技术难点他们既不懂也讲不明白，在对程序员说话时也会出现鸡同鸭讲的情况（我就遇到过）；架构师的职责或者说牛逼在于一个问题，可以从技术角度搞定研发，也可以从业务角度搞定产品

  作者回复: 所以架构师工资高，哈哈😄

  2018-09-18

  

   1
• 

  寒星

  看这情况，我这种既做过项目管理，又做架构设计的是不是更有优势了啊😄

  作者回复: 肯定的，做过项目管理的程序员才是好的架构师😄👍👍

  2018-08-13

  

   1
• 

  godtrue

  课后思考及问题
  
  架构师不是技术岗位吗，为何还要做这些事情，沟通和推动的事情让项目经理做就可以了！你怎么看这个观点？
  我所见的事实和华仔讲的恰恰相反，这可能和小组结构和角色定位相关。我们架构师，主要工作据我了解如下：
  第一代码评审，除页面外基本都让他看看写的是否OK
  第二疑难问题解决，各种奇怪问题可以找他一起看
  第三技术选型支持，提供方案供领导选择
  第四大促或者平时基础架构部推动的事情，他分配到各组执行
  第五人员面试，一面是高工，他主要负责二面
  第六对外撕技术方案提供，比如：部门间合作有些事让我们做，他需要判断具体方案是否可行
  第七技术探索，如果要用新技术他会先实验实验，调研一下，宣讲一下，然后交给具体人员实施
  
  我的观点是视情况而定，技术相关的事情架构可以推动沟通，不过其他的事情比如：啥时候联调，啥时候上线，需要项目经理来推动沟通了。
  合纵连横的合作技巧是通用的，不过具体是谁负责，是事环组过来决定的。
  
  1：本文核心观点
  老师你太逗啦！列举的场景能让我笑一个早上😊
  1-1：合纵——我的理解是，统一战线，将朋友搞得多多的，敌人弄得少少的，越多人支持一件事越容易搞定。
  沟通技巧——在沟通协调时，将技术语言转换为通俗语言，以事实说话，以数据说话，是沟通的关键！
  
  1-2：连横——我的理解，其实和合纵本质一样，区别在于结盟的对象不同。
  拉人技巧——换位思考、合作双赢、关注长期。

  作者回复: 项目经理搞不定技术判断和取舍

  2019-09-05

  

  
• 

  微风

  我能说架构师就是个适配器吗？呃，其实一直认为架构师是个很神圣的岗位：军师。

  作者回复: 架构师就是系统的军师😂

  2018-09-29

  

  
• 

  petit_kayak

  同时作为架构师、设计师和项目经理（不同的项目），我很理解沟通中的对方，而且就像老师说的，架构师常常要做一些类似于项目经理或者产品经理的工作，因为架构其实就是一个组织内部“销售”的产品。

  2018-09-13

  

  
• 

  波波安

  我感觉问题就在于，都想自己改动调整最少。

  作者回复: 确实如此😀😀这就需要架构师的推动能力了

  2018-09-05

  

  
• 

  忠厚

  再牛逼的架构也得落地才能体现出架构师的价值，用嘴做架构只能是纸上谈兵，架构师自己不去推动，那架构就不能落地或者不能按自己的想法落地，那架构的价值何在，架构的价值也会大打折扣

  作者回复: 架构师应该是最明白价值的

  2018-08-24

  

  
• 

  W_T

  我对这篇文章的总结就是：站在对方的角度思考问题，挠他的痛点！

  2018-08-16

  

  
• 

  云学

  技术驾驭到一定程度就开始驾驭人了，哈哈

  作者回复: 必须的，有人的地方就有江湖😄

  2018-08-13

  

  
• 

  feifei

  架构师关注的是整体的系统把控，沟通和推动在重构这件事情上需要架构师来协调，项目整体性重构项目经理未必能讲清楚，需要架构师来协调相关方，这些工作本身就是架构师的工作的一部分

  2018-08-13

  

  
• 

  zengjian

  快到尾声了，除了学到很多技术点，还学会了如何拍照选图，比如这期的小姐姐

  作者回复: 感谢编辑选图😄😄

  2018-08-11

  

  