这种问题统计下平均耗时，哪里占比大，原因是什么，写相关组件的同学负责出报告和优化方案，
一周内就可以搞定了，  
  
【 在 wallyz (沃) 的大作中提到: 】
:  举个例子，产品上云原生
:  
:  组件间通信，赶时髦，用了grpc
:  
--
FROM 119.61.27.*

而且很明显，问题出在整个方案设计本身

让相关组件的同学负责出报告和优化方案，这说句不客气的话，就是所谓架构师无法下沉到产品，然后只好虚张声势，甩锅的行为

这话不是架构师应该说的，甚至优化方案本身就是架构师应该出的，因为这个问题恰恰就是架构设计注定的

我不知道这里的同学说，架构师只需要拼组件，这样脱离产品，是否经过现实的锤炼

至少在我经历的实际过程中，架构师对产品的内在实现的把握需要非常高，即使不是产品逻辑层的问题，甚至是操作系统kernel的问题，只要一旦在现场出了问题，架构师一定是最后被寄予厚望，来搞定问题的人


【 在 leaf918 的大作中提到: 】
: 这种问题统计下平均耗时，哪里占比大，原因是什么，写相关组件的同学负责出报告和优化方案，
: 一周内就可以搞定了，  
--
FROM 123.168.95.*

我不觉得有什么难易的不同。
就是人家给不给你机会


- 来自 水木社区APP v3.4.2
【 在 hgoldfish 的大作中提到: 】
: 有什么不同吗？
:
: 我最近写了一段时间的前端，发现自己把数据给加载到前端来做数据统计，干了后端的活。
:
: 都忘了这不是我这个前端该做的。
:
--
FROM 116.88.151.*

我是回复leaf918的帖子

我举的例子，方案出了问题，确实是架构师应该负责的寻找方案问题，并提出改进方案的

我回帖的原因是，leaf918说，让相关组件同学出方案，一个周搞定，对此我不认可，所以回帖

架构师的职责，远远没有站在高处出个方案这么轻松，
还是那句话，如果仅仅是如此，找麦肯锡安永等对应的咨询部门来出个方案就好了，何必请个专职的架构师





【 在 oldwatch 的大作中提到: 】
: 我不知道“拼组件“是怎么导出”脱离产品“的
: 拼组件最终目的都是实现功能要求
:
: ...................
--
FROM 223.104.194.*

所以，出了问题，让相关组件的同学出方案，这种做法，和外部闪人的有本质区别没？


【 在 oldwatch 的大作中提到: 】
: 仔细想想，外部咨询和内部人员出方案核心区别在哪儿
: 无非就是外部人员出完ppt就闪身走人，内部人员得持续跟进
:
: ...................
--
FROM 223.104.194.*