- 主题:项目都是C++的，结果新来的架构师不懂C++
那得先定义怎样算“懂C++”了……
【 在 anotherstone (初级K线分析员) 的大作中提到: 】
: java构架师不懂c++，那java学的好吗？
: 构架师，需要处理分布，性能，并发等多重场景，
: 只懂java这种层面的东西，做构架师合格吗？
: ...................
--
FROM 116.233.186.*
具体语言确实挺浮云的（前提是不深入细节）
到架构这个层次
更多还是语言的专有特质（比如java有vm，nodejs的eventloop等等）
以及附带的基础库、功能库，乃至生态系统，不熟悉的话会比较挠头
偏偏这玩意规模宏大，还不是几天就能把握住的
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 如果要求架构师一定要精通所有语言，那些复杂的系统岂不是都很难找到架构师？
: 是不是系统里面有几行 python，下次换一个精通 perl 的过来就不行了？
: 我觉得这是不对的。架构师只要理解各种技术的应用场景和优劣，最终做出来的效果好，问题就不大。
: ...................
--
FROM 116.233.186.*
架构干的就是拼凑啊
把各种组件扬长避短的拼在一起，协调各自的分工
【 在 wallyz (沃) 的大作中提到: 】
: 那不就沦为从所谓high level拼凑各种组件的了吗？
: 那还不如只会粘胶水的工程师，起码工程师还能把一堆东西粘到一起
--
FROM 116.233.186.*
其实吧，相较熟练掌握一门语言/生态
”了解坑在何处“的要求还是低很多的
毕竟到整体架构这个层面其实不太需要具体细节
合格架构师，眼中应该只有”内存“，”存储“，”数据流“，”同步”,“异步”而已
【 在 wallyz (沃) 的大作中提到: 】
: 如果连C++都不懂，而项目中C++却举足轻重，
: 而这个架构师做的只是拼凑各种组件，不懂里面的各种坑，
: 那其实不用招个全职架构师，
: ...................
--
修改:oldwatch FROM 116.233.186.*
FROM 116.233.186.*
我不知道“拼组件“是怎么导出”脱离产品“的
拼组件最终目的都是实现功能要求
选方案的人要对方案最终实现效果担责的
【 在 wallyz (沃) 的大作中提到: 】
: 而且很明显，问题出在整个方案设计本身
: 让相关组件的同学负责出报告和优化方案，这说句不客气的话，就是所谓架构师无法下沉到产品，然后只好虚张声势，甩锅的行为
: 这话不是架构师应该说的，甚至优化方案本身就是架构师应该出的，因为这个问题恰恰就是架构设计注定的
: ...................
--
FROM 116.233.186.*
仔细想想，外部咨询和内部人员出方案核心区别在哪儿
无非就是外部人员出完ppt就闪身走人，内部人员得持续跟进
所以重点不是方案，是方案的后续实施时的持续跟进
【 在 wallyz (哦) 的大作中提到: 】
: 我是回复leaf918的帖子
: 我举的例子，方案出了问题，确实是架构师应该负责的寻找方案问题，并提出改进方案的
: 我回帖的原因是，leaf918说，让相关组件同学出方案，一个周搞定，对此我不认可，所以回帖
: ...................
--
FROM 116.233.186.*
那显然是甩锅行为
很不幸的是，架构师队伍中确实混进了不少类似人物……
【 在 wallyz (哦) 的大作中提到: 】
: 所以，出了问题，让相关组件的同学出方案，这种做法，和外部闪人的有本质区别没？
--
修改:oldwatch FROM 116.233.186.*
FROM 116.233.186.*
毕竟软件基础设施的技术突破远比ppt改关键词难
【 在 wallyz (哦) 的大作中提到: 】
: 那倒也不是
: 其实云原生的理念是对的，
: 应用程序只管自己逻辑，不需要操心流量路由，分发，负载均衡，统计数据报告等
: ...................
--
FROM 116.233.186.*
前端的技术更像是一个扇面
同一个东西有无数种解决方案……
【 在 ilovecpp (cpp) 的大作中提到: 】
: 前端这些技术是不是也差不多啊，90%的项目不需要这些东东？
--
FROM 116.233.186.*