如何成为架构师

发布网友 发布时间：2022-03-28 07:00

我来回答

共2个回答

懂视网 时间：2022-03-28 11:21

　　架构师是一个充满挑战的职业，需要关注很多维度和技术。只专注于单一领域的架构师并不是优秀的架构师。那么如何成为一个技术全面的架构师呢？　

　

　　一、作为技术领导者

　　

　　一名好的软件架构师需要明白，作为领导者并不一定要告诉开发人员做什么。相反，好的架构师就像一个导师，带领开发团队向同一个技术愿景前进。好的架构师会借助于讲故事、影响力、引导冲突、构建信任等领导技能，将他们的架构愿景变成现实。一个好的领导者，同时也是一个好的架构师。他/她会仔细听取每个参与者的意见，通过与团队的反馈互动调整他们的愿景。

　　

　　二、作为开发人员

　　

　　一个架构师同时又是一个好的开发人员。通常，做出一个良好的架构选择需要权衡理想的架构状态与软件系统的当前状态。例如，如果一个问题更适合采用关系型数据库来解决，那么将文档数据库引入到系统中的做法是毫无道理的。一个架构师如果不考虑技术选型与问题域之间的匹配度，那么会很容易受到各种技术的诱惑——这也就是常见的“象牙塔式架构师”行为模式。

　　

　　缓解这种情况的最佳方式是架构师多与开发人员待在一起，花一些时间在代码上。了解系统的构建方式及系统的约束将帮助架构师在当下环境做出正确的选择。

　　

　　三、聚焦系统

　　

　　经验丰富的开发人员明白代码只是软件的一个方面。为了让代码可运行，他们还需要了解代码在生产环境中运行良好所需的其他重要质量属性。他们需要考虑部署过程、自动化测试、性能、安全和可支持性等方面。开发人员可能以临时的方式来实现这些质量属性，而架构师不仅需要专注于了解代码，还要了解并满足不同利益相关者（如支持、安全和运营人员）的需求。一个好的架构师需要专注于寻找那些能够满足不同利益相关者需求的解决方案，而不是选择针对某一个参与者的偏好或风格进行优化的工具或方法。

　　

　　四、企业家思维

　　

　　所有的技术选型都有相关的成本和收益，一个好的架构师需要从这两个角度考虑新的技术选型。成功的企业家愿意承担风险，不过也会寻求快速学习和快速失败的方法。架构师也可以用类似的方式做出技术选型，收集真实世界中有关短期和长期成本的信息，以及他们可能意识到的好处。

　　

　　这方面一个很好的例子是，架构师避免承诺立即使用一个在阅读新文章时看到的工具或某一会议上听过的工具。相反，他们试图通过架构调研来了解工具在其环境中的相关性，以收集更多信息。他们对于工具的选择不是基于销售量，而是考虑他们需要什么以及这个工具所提供的价值。他们还会寻找这些工具背后的隐性成本，例如工具的支持情况（如文档化程度、社区使用情况），工具可能带来的约束或长期来看可能引入的额外风险。

　　

　　五、权衡策略思维与战术思维

　　

　　许多团队由一些独立的开发人员一起构建软件，而每个人都倾向于选择自己最舒适或最有经验的工具和技术。好的架构师持续关注可能有用的新技术、工具或方法，但不一定立即采用它们。技术采用往往需要长期的考量。架构师将在团队和组织层面寻求敏捷度（允许团队快速采取行动）和对齐（保持足够的一致性）之间的良好平衡。建立自己的技术雷达这样的练习是用战略思维探索技术的一个有用工具。

　　

　　六、良好的沟通

　　

　　架构师需要知道，有效沟通是建立信任和影响团队以外成员的关键技能。他们知道不同群体使用不同的词汇，而使用技术术语和描述与业务人员沟通将会变得比较困难。与其谈论模式、工具和编程概念，架构师需要使用听众熟悉的词汇与之交流，诸如风险回报、成本和收益等。这比单纯使用技术词汇进行沟通来得更好。架构师还需要认识到团队内部沟通与外部沟通同样重要，可以使用图表和小组讨论的方式来建立和完善技术愿景，并书面记录之。

　　

　　

热心网友 时间：2022-03-28 08:29

架构师首先必须具有丰富的开发经验，是个技术主管。因为他必须清楚什么是可以实现的，实现的方式有哪些，相应的难度怎么样，实现出来的系统面对需求变化的适应性等一系列指标。另外，需要对面向过程、面向对象、面向服务等设计理念有深刻的理解，可以快速的察觉出实现中的问题并提出相应的改进（重构）方案（也就是通常说的反模式）。这些都需要长期的开发实践才能真正的体会到，单从书本上很难领会到，就算当时理解了也不一定能融会到实践中去。在技术能力上，软件架构师最重要也是最需要掌握的知识是构件通信机制方面的知识，包括进程内通信（对象访问、函数调用、数据交换、线程同步等）以及进程外（包括跨计算机）的通信（如RMI、DCOM、Web Service）。在WEB应用大行其道的今天，开发者往往对服务器间的通信关注的比较多，而对进程内的通信较少关注。进程外跨机器通信是构建分布式应用的基石，它是架构设计中的鸟瞰视图；而进程内的通信是模块实现的骨架，它是基石的基石。如果具体到一个基于.Net企业级架构设计，首先需要的是语言级别的认识，包括.NET的CLR、继承特性、委托和事件处理等。然后是常用解决方案的认识，包括ASP.NET Web Service、.NET Remoting、企业服务组件等。总之，丰富的开发实践经验有助于避免架构师纸上谈兵式的高来高去，给代码编写人员带来实实在在的可行性。其次，具有足够的行业业务知识和商业头脑也是很重要的。行业业务知识的足够把握可以给架构师更多的拥抱变化的能力，可以在系统设计的时候留出一些扩展的余地来适应可能来临的需求变化。有经验的设计人员可能都碰到过这样的事，一厢情愿的保留接口在需求变化中的命中率非常低。也就是说，在系统设计之初为扩展性留下来的系统接口没能在需求变化的洪流中发挥真正的作用，因为需求的变化并没有按照预想的方向进行，到最后还是不得不为变化的业务重新设计系统。这就是因为对业务知识的理解和对市场或者商业的判断没有达到一个实用的、可以为架构扩展性服务的水平。再次，架构设计师对人的关注必须提升到架构设计之初来纳入考虑的范围，包括沟通以及对人员素质的判断。软件过程是团队协作共同构建系统的过程，沟通能力是将整个过程中多条开发线粘合在一起的胶水。大家都应该碰到过事后说“原来是这样啊，我不知道啊”或者某个开发人员突然高声呼喊“为什么这里的数据没有了”之类的。沟通的目的就是尽量避免多条开发线的混乱，让系统构建过程可以有条理的高效进行。另外，对人的关注还表现在对团队成员的素质判断上，比如哪些开发人员对哪些技术更熟悉，或者哪些开发人员容易拖进度等。只有合理的使用人力资源，让合适的人做合适的事情才能让整个软件过程更加高效。架构师应时刻注意新软件设计和开发方面的发展情况，并不断探索更有效的新方法、开发语言、设计模式和开发平台不断很快地升级，软件架构师需要吸收这些新技术新知识，并将它们用于软件系统开发工作中。但对新技术的探索应该在一个理性的范围内进行，不能盲目的跟风。解决方案提供商永远都希望你能使用它提供的最新技术，而且它们在推广自己的解决方案的时候往往是以自己的产品为中心，容易给人错觉。比如数据库，往往让人觉得它什么都能做，只要有了它其它什么都不重要了。但事实上并不是如此，对于小型应用可以将许多业务逻辑用script的方式放入数据库中，但很少看到大型应用采用这样的做法。对于新东西需要以一种比较的观点来判断，包括横向的比较和纵向的比较，最后得出一些性能、可移植性以及可升级等指标。另外，新入行的开发人员往往关心新技术动向而忽略了技术的历史，而从DOS时代一路杀过来的开发者就对现在的技术体系有较全面的把握。