zoukankan      html  css  js  c++  java
  • 架构师的职责与思考

    在当下的互联网时代,架构师是互联网行业的热点关键词,人云亦云者居多,那互联网架构师 到底是做什么的,如何来评价互联网架构师的优劣呢?

    架构师产生的历史渊源

    互联网应用脱胎于传统软件应用,伴随着要求更为快捷与面向未知需求的互联网应用的兴起,对技术团队的要求也陡然升高,不再是按部就班的开发,而是需要快速迭代、快速响应来自市场和用户的需求和反馈,互联网应用的反应和迭代快慢决定了生死的微妙差别。

    互联网时代的变更也带来了技术团队中组织结构和技术栈的快速升级与变化,所有的这些都来自于行业的快速演进和进化。于是乎之前的项目经理带领一帮高级程序员、中级/初级程序猿的组织结构显然已经不太适应时代的需求,产品经理、技术经理、系统架构师、数据架构师、运维架构师、前端开发与架构师等等诸多的细分职位与之伴生而为大家所接受和理解。

    在这里,我们重点需要讨论的是互联网项目中的软件系统架构师的这个职位。

    众人眼中的"架构师"

    在技术团队中,除了众多开发工程师、项目经理、技术经理和产品经理之外,还有一个架构师,通常大家都是把这个职位当作高级工程师中的资深工程师,经验和阅历都很丰富,有问题找他来解决就是了。

    整个技术团队的主要管理内容包括: 人员管理、资源协调、进度管理、技术管理等等内容,分别分配到项目经理、技术经理和架构师等类似的职位上,一般架构师这个职位不承担技术之外的管理职能,主要专注于项目所使用的技术栈的评估与选取,关键的技术问题的分析与解决、核心代码和系统的设计与实现等任务;但是在实际的工作中,架构师和技术经理的角色在技术选型和关键部分的把控方面是由冲突和重叠的;另外,在技术团队中,人员和技术方面的工作实际上是无法分开的,重要的原因是人员大部分都是技术人员,其主要的工作是技术工作,很多时候都是需要听取来自专业技术方面的意见和反馈之后,才可以制定相应的排期以及计划,包括风险管理、工作量评估等内容。

    在项目经理以及诸多的领导眼里,架构师就是做技术的,技术大牛,整个项目的技术架构以及技术问题都由其来承担和负责,出了问题就是架构师的问题。其实在实际情况中,一个项目出现了问题,固然有技术方面的因素,但是绝大多数情况下,技术都是次要的因素,技术之外的因素往往扮演了各种复杂的角色;产品的成败由业务线(比如产品经理)来负责,产品本身的质量由技术团队来负责,当然这个只是理想的状况下的自然推理。实际的情况,往往南辕北辙,彼此都是纠缠在一起的,业务方面深刻影响了技术架构的选择与设计,快速的业务变化带给技术架构以及技术团队的混乱与损耗都是非常巨大的。

    架构师的职责

    架构师的职责应该是立足于技术和业务之间的中间角色或者平衡点, 在针对业务深刻理解的基础上,针对业务中存在诸多变数,挑选适合的技术架构和技术方案;结合现有的技术团队的水平与特点,选择合适的技术栈进行落地和实现。

    架构师在做每一个决定之时都会受到诸多的因素的限制,比如高效的技术栈需要很高的学习曲线,在工期与人员素质之间需要权衡。精妙的技术架构并不能解决业务的快速迭代和变化,技术架构都是后知后觉的,无法准确的预知业务层面的变更与方向,故只能是跟随的角色,这样就必然会面临技术架构迭代和升级的需求,技术架构从来都不是建立了之后,就无需修改,可以承载各方的多重期望;事实上恰恰相反,技术架构是需要与时俱进的,是不断迭代和升级出来,根据不断变化的业务需求和团队情况来动态调整的。

    架构师的应变与坚持

    架构师这个职位的优势所在是将技术方面重要的决定由专门的角色来进行负责和跟踪。当然这个职位的出现是基于现有团队功能的重新划分,将原来从属于技术经理的技术职能剥离出来独立成为架构师,必然带来了彼此之间的职能灰色地带;这也就带来一个巨大的隐患冲突: 技术经理和架构师之间的职责边界以及合作沟通。

    技术架构的保持、重构与升级都与架构师的沟通技巧、坚持以及妥协技能息息相关,在技术团队之外,其余的角色和上层领导对于技术都是理解肤浅或者不甚了解的;除了自身的关注点之外,对于技术团队所为的技术架构以及业务的变更对于系统的冲击影响不甚关心;一般都是结果导向,在没有如期实现业务功能和目标之前,所谓的“技术架构”的稳定、重构与保持都是没有任何意义的。 所以,架构师需要与业务不停的沟通妥协,在面对对技术架构深远和错误的影响之时,需要有所坚持和信仰,对于对的方向和原则有所坚持;帮助技术团队规避一些人为或者外界带给系统和项目的各种冲击。

    所有的这些都是建立在各个层面可以沟通和愿意承担的基础上,如果各个层面不满足这个基本原则,架构师所有的坚持与妥协都会让自身陷入不利的境地,过程中承担各种抱怨,来自技术团队、业务方和公司高层。建议此时,妥协第一,不必坚持,满足业务需求,尽力做好预防性设计,不做错误解决,已是万幸。

    总结

    在其位,谋其政,站在架构师的职位上,架构师要本着对团队支持、对系统负责,对领导和业务相关方充分沟通与建议的基本准备,充分利用自身的经验与阅历,帮助团队规避各类或深或浅的系统之坑陷,保证业务线的正常运转,同时保持系统具备一定的灵活性、稳定性和可持续开发性。 尽人事,知天命,有所为,有所不为,架构师其实是技术、业务、管理和资源等各类因素之间进行妥协、沟通和协调的角色,混很容易,做好很难。

  • 相关阅读:
    Linux内核设计与实现 总结笔记(第五章)系统调用
    Linux内核设计与实现 总结笔记(第四章)进程调度
    Linux内核设计与实现 总结笔记(第三章)进程
    Linux内核设计与实现 总结笔记(第二章)
    4412 移植x264并且YUV422转x264
    4412 使用usb摄像头拍照YUYV格式
    LDD3 第15章 内存映射和DMA
    LDD3 第13章 USB驱动程序
    ldd3 第12章 PCI驱动程序
    4412 移植mpu9250尝试
  • 原文地址:https://www.cnblogs.com/xiang--liu/p/9710158.html
Copyright © 2011-2022 走看看