架构：架构师只是个角色，不是个岗位

🤔☕️🤔☕️🤔 【R】需求翻译成技术方案，架构师上场的时候，同时他得参与写核心框架代码。架构师最重要的事情，就是要表达清楚自己的想法，工具和理论在其次。 【.I.】架构，这个词自带高级感，架构师，这个词自带权威感，这两个词放在一起，产生巨大的压迫感。当我是工程师的时候，这种压迫感席面而来，真担心自己的设计顶撞架构，真担心自己的实现弄歪架构，更担心架构师劈头盖脸评审我的设计和实现。当我架构师的时候，这种压迫感依然席面而来，这时候更担心架构容不下设计，更更担心实现一开始就游离架构之外，更更更担心架构图到头来废纸一堆而已。这样的双向压迫感，逼得我问出，没架构师就不行吗？为此还建立个“1-2-3”模型，当独自开发、当两人合作、当多人协作时，当单次交付、当未来迭代、当持续维护时，哪些方面的问题，需要架构师这样的角色来思考和筹划，忽然间清晰很多。 【.I.】架构师在架构过程里的一个重要任务，就是让参与各方就目标本身达成共识，以及就达成目标的方法和路径达成共识。自己实践中发现，目标本身的共识，其实更多是点头之交，仅仅是共识了目标的字面；而目标所需的方法和路径的共识，极难在短期达成，而这却会极大损坏最终目标的抵达。后来受架构师必须写框架代码的启发，项目开始时架构师自己下田干活，把最累最苦的事情先做掉，做出个模板和样式，尤其每个关键步骤，都能形成提交记录，作为后续实践参考，极大会在目标达成所需的方法和路径方面形成共识。说白了就是，我说的都不算，但是我做好的，尤其做出来实际有效的话，大家还是会认可。 【Q】架构师在相对全局的视角，看到的问题跟局部视角看到的问题有差别，这时候他的解决思路，会跟局部的思路有偏差，甚至有冲突。而在局部视角的人，在技术自负之下，会非常坚持自己的思路和方案。老师有遇到过类似情景嘛？如果有的话，怎么能拿捏准火候，如何能让共识逐步达成？ —— by 术子米德@2022.11.04

哦，文末拓展阅读里有公众号，我经常看完正文就切下一篇了，这习惯得改

文中的设计原则指的什么呢

一个下午把整个超级访谈快速的过了一遍，讲了很多我遇到过的问题，还有很多我没有碰到过的问题。最大的感悟是：我们没办法确保解决问题的方法一定正确，但我们要确保解决问题的过程一定是真诚的。

“自己做系统设计的套路：系统设计的目的 -> 系统设计的目标 -> 围绕目标的核心设计 -> 围绕核心设计形成的设计原则 -> 各子系统、模块的详细设计。”跟我邦的方法论高度一致，“先问目的、再做推演，亲自打样、及时复盘”。

特别认同架构师是一个角色而不是岗位

架构师有时需要很多tradeoff，要根据公司的规模，技术栈，现有系统状况，团队人才厚度，行业及公司发展，IT投入预算，找出一个相对合理、渐进的演进路径，支撑业务发展的同时，控制投入产出，同时向上向下管理，把想法落地，克服不可预期的困难…

从作者职业生涯复盘访谈，收益良多，感谢！不怕选择，迎接挑战

运营的老大也是这样。

恐怕大多数团队的 leader 都是纯管理，不懂技术的