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