系统架构设计师要写程序么
一般不需要，但一定要理解。
理想情况下，架构师需要创建技术愿景，通过这个愿景可以获得可维护、可靠的产品。架构师需要协调不同的团队，共同构建相互依赖的软件生态系统。此外，为了传递应用程序和组件之间的协作，高级管理层必须共享全面决策。您还必须根据常见的软件问题审查和确定工具和框架，并将最终产品的目标和愿景传达给利益相关者和领导者。
所以架构师的工作听起来很棒。你可能想知道为什嚒我把这嚒多工作推给忙碌的架构师。为了理解这一点，让我们看看我刚才描述的情况与现实生活的对比。
现实似乎因公司而异。事实上，一些公司要求架构师在完成所有其他角色的同时负责编程。但这些公司不是本文的探讨对象。我想重点讨论没有参与编程的架构师在公司做了什么。
在某些特定领域，如java，熟悉各种开源框架，在开源框架上提供系统安全性、异构通信协议、各种高速缓存、群集和存储、群集、我们需要开发各种系统功能，比如分布式。体系结构是一个能够从微观上解决各种系统异常的人，需要为企业的发展提供宏观的体系结构支持（可扩展的体系结构级别）
所以架构必须是技术上有一定权威的人，必须是团队的技术核心人物，才能根据最佳实践制定技术规范，并要求技术人员按照规范实施。如果是开发人员，尤其是新员工，无法理解如何使用架构进行开发，架构应该训练、开发合适的架构dEMO，并将其交付给使用者，必要时应弄清楚架构为何如此设计的原因。你可以想象一下。如果没有人做出重要的技术决策，你真的有架构师的能力吗？
3.组织大家完成技术研究，对核心技术的选择有自己的看法，识别系统的风险点和优化点
如果需要解决关键技术难点，体系结构必须站在前面。经验丰富的体系结构应在系统设计开始时预测可能的技术问题，并事先进行技术研究。
因此，架构必须具有广泛的知识，才能对不同的技术选择有自己的判断，权衡不同的技术组合，识别各种技术选择和组合的风险，应该运行系统，继续优化具有自己的经验可以识别系统优化点，还擅长使用各种工具，定量分析系统的性能瓶颈，组织技术合作伙伴一起解决。
以上3点，只要是决心成为架构师的伙伴谁都能理解吧。但是，技术上追求的架构师天生就有排斥感，两者都需要与人交往，所以对架构师来说效率很差（其实很多架构师都是内向的，也不喜欢与人交往），所以还是打代码比较好。
因此，直觉认为，坚持成为架构师不需要上述两种能力。体系结构和技术做到极致就足够了。事实上，技术是为商业服务的。你的用户只有2000人。如果你建立一个能应对2000万人的架构，你只会浪费资源。了解业务有助于从更高的层次了解体系结构，更好地应用体系结构，并在后期了解体系结构以适应业务。
5.此外，在工作过程中，体系结构始终是技术人员的专业知识人员的体系结构（或技术经理），能够将适当的技术任务分配给适当的人，因此积极或被动地参与开发或管理工作，例如任务分配或项目进度估计。或者，项目经理通常会征求架构师的意见，即使不是架构师分配任务。
例如，开发新体系结构需要培训。例如，系统需要与其他部门进行系统通信和集成，需要部门间的合作。各种场景使建构者参与一些项目管理，参与一定的职业规范、学习或一定的项目管理，不仅是技术问题，更能从更宏观的层面看到项目的发展。
