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

    作者回复: 这样的现象非常正常,我觉得最重要的是开诚布公的和大家交流,说清楚自己为什么在架构设计上做到是这个选择,考虑的因素是什么,说清楚的情况下,我觉得就算有不同,也没有问题。 我们常说的就是在探讨的时候大家可以吵翻天,但在做了决定后,即使自己有保留意见,大家也应该行动一致。

    
    1
  • 柯烂
    2022-11-18 来自北京
    哦,文末拓展阅读里有公众号,我经常看完正文就切下一篇了,这习惯得改

    编辑回复: 😁

    
    
  • Geek_474406
    2022-11-10 来自浙江
    文中的设计原则指的什么呢

    作者回复: 我自己理解的设计原则是在当前的架构设计中要遵守的底线,例如在异地多活里流量分配的原则,怎么保护数据不错乱的原则,当然可能还会有些很通用的,例如高可用什么的。

    
    
  • 刘超
    2022-09-29 来自上海
    一个下午把整个超级访谈快速的过了一遍,讲了很多我遇到过的问题,还有很多我没有碰到过的问题。最大的感悟是:我们没办法确保解决问题的方法一定正确,但我们要确保解决问题的过程一定是真诚的。
    
    25
  • 赵新龙
    2022-09-29 来自北京
    “自己做系统设计的套路:系统设计的目的 -> 系统设计的目标 -> 围绕目标的核心设计 -> 围绕核心设计形成的设计原则 -> 各子系统、模块的详细设计。”跟我邦的方法论高度一致,“先问目的、再做推演,亲自打样、及时复盘”。
    
    10
  • 张申傲
    2022-10-25 来自北京
    特别认同架构师是一个角色而不是岗位
    
    3
  • Vincent
    2022-10-09 来自北京
    架构师有时需要很多tradeoff,要根据公司的规模,技术栈,现有系统状况,团队人才厚度,行业及公司发展,IT投入预算,找出一个相对合理、渐进的演进路径,支撑业务发展的同时,控制投入产出,同时向上向下管理,把想法落地,克服不可预期的困难…
    共 1 条评论
    3
  • G小调
    2022-09-30 来自云南
    从作者职业生涯复盘访谈,收益良多,感谢!不怕选择,迎接挑战
    
    2
  • huhu小仙女
    2022-09-28 来自北京
    运营的老大也是这样。
    
    1
  • 01Running
    2023-02-08 来自北京
    恐怕大多数团队的 leader 都是纯管理,不懂技术的
    
    