成为一名优秀的Java架构师应该具备哪些条件?

时光退回到七八年以前,那个时候“java架构师“还是一个很“高大上“的title。可是在今天的互联网圈,随便一个工作了三、五年的开发人员,都可以称之为架构师。 随便多翻几个招聘网站,你可以看到:...

    时光退回到七八年以前,那个时候“java架构师“还是一个很“高大上“的title。可是在今天的互联网圈,随便一个工作了三、五年的开发人员,都可以称之为架构师。

    随便多翻几个招聘网站,你可以看到:前端架构师、后端架构师、Android架构师、iOS架构师、php架构师、运维架构师、DB架构师、搜索架构师、中间件架构师、大数据架构师。。。五花八门,不一而足。

attachments-2020-08-GWteitEE5f3b62f986e14.jpg

    从这些岗位需求可以看出,“架构师“这个词其实是一个很“虚“的词,不同技术领域、不同行业,所要求的技能点、所侧重的能力模型是差别很大的,不是一个简单的“架构师“就可以概括的。

    而本文也将谈谈我个人对“架构师“这个职位的理解:虽然不同领域要求的能力模型不一样,但个人认为,作为一个“架构师“,还是有一些共同的东西需要掌握的。

    格局

    “格局“这个词听起来比较虚,但我举个通俗的例子:你去一个陌生的城市旅游,我想你首先需要的就是一张“地图“。这张地图定义了这个城市的“边界“,也定义了这个城市的所有地方,通过这张地图,你会对这个城市有一个“全局的了解“。

    而这种“全局的视野“,不是说架构师才需要,换做其他职位、其他行业,同样的道理。做产品经理,需要对产品有“全局视野“;做运营,做市场,需要运营、市场相对应的全局视野;做技术,需要技术相关的全局视野。

    说了这么多,可能还是比较“虚“,我就举个例子来说明到底什么叫“全局视野“,比如你现在负责开发一个新系统,你可能需要去理解下面这些关系到“大局的问题“:

    这个系统的定位是什么?它能创造什么核心价值?

    做这个系统的背景是什么?--为什么以前不做,现在要上?是因为业务发展到了一定规模?还是开发资源现在有多余,没事可干?

    这个系统在整个组织架构中,处于什么位置?跟这个系统关联的其它系统目前什么状况?

    产品经理如何看待这个系统?技术老大如何看?

    这个系统的需求,是处于比较确定、比较清晰状态?还是有很大灰度空间?很多核心点,大家还没想清楚?

    这个系统所用的技术体系,是比较老?还是最新的?

    业界类似的系统,人家是如何做的?

    。。。

    关键点:上面随便举的这个例子,并没有标准答案,我想表达的是,一个有“大局观“,一个有“格局“的人,在做一件事情之前,要对所做的事情有一个“全局把握“,风险在哪?挑战在哪?提前要有心理准备!

    最后再多说一句:“格局“是有层次的,国家总理在“国家“这个层次思考,CEO在行业、“公司“这个层次思考,业务线负责人在他所负责的那个“业务“层面思考,技术老大可能主要在“技术层面“思考,产品老大在“产品层面“,到了最下面,写代码的,在“代码“这个层面思考。

    不同层次的人,聚焦的范围大小不一样。可如果你能把你的“范围“往外扩一圈,这对你做自己的“本职工作“会很有好处。

    而这,在我看来就是“格局“。

    历史观-技术血脉

    如果说“格局“是从空间的角度去看待问题,那么“历史观“就是从时间的角度去看。

    任何一种技术,都不是谁吃饱了没事干凭空想象出来的,它一定是要解决某个特定问题。而这个特定问题,一定有它的历史背景:是因为之前的技术,在解决这个特定问题上,解决的不够好、或者有其它副作用,所以才发明了这个新技术。

    所以,看待一个技术,一个方法论,需要把它放到“历史长河“中,去看它在历史中,处于什么位置。

    推而广之,何止是技术,任何其他学问,何尝不需要“历史观“?说个更专业点的哲学名词,就这是所谓的“历史唯物主义“吧!

    抽象能力

    同“格局“一样,“抽象能力“又是一个很“虚“的词。可作为架构师,就是需要这种“务虚思维“。

    抽象也是一个“层次“结构,从最底层到最上层,不同工作阶段,你需要在不同抽象层级进行思考。

    很多写代码的人,都比较习惯“自底向上“的思维方式。当你跟他讨论需求的时候,他首先想的是这个需求如何实现,而不是这个需求本身是否合理?这个需求跟其它需求有什么关联关系?

    这种过早考虑“实现细节“的思考方式,会让你“只见树木,不见森林“,最终淹没在茫茫的各种细节之中,层次混乱,把握不住重点。

    同样拿上面的例子举例,假如让你做一个新的系统,那么从“抽象“到“细节“,你可能需要考虑:

    每个需求的合理性?

    这个系统的领域模型是什么样的?

    这个系统是应该在旧的上面改造?还是应该另起炉灶?

    这个系统可以分成几期,分期实施?

    这个系统要拆分成几个子系统?

    每个子系统又拆分出多少个模块?

    系统的表设计?api接口设计?job的设计?系统之间的消息传输?

    。。。

    从上到下,是一个逐级细化的过程,并且进入到下1级之后,上1级可能又会退回去修改。

    深入思考的能力

    深入思考能力,这里主要指“技术“的深度。关于“广度“,在上面的“格局“这个层面已经包含。

    “深度“不是说,你要在所有领域都很深。人一生的精力是有限的,你不可能对所有技术领域都很深,但你需要1个比较深的领域。

    这种深度,并不代表你当前的工作就需要这个技术领域,而是说这种“深入思考的方式“,会让你在思考其他问题时,也会带着这个“习惯“。

    这个东西很重要,因为技术一直在更新换代,当你面对一个新技术的时候,如果你有深入思考的能力和习惯,那你对新技术的理解往往也就很透彻。

    同时,“深度“会让你对“技术风险“有更加清醒的认知,你做一个项目的时候,这里面潜在的“坑“,你可能会提前发现,而不是等做到那了,发现问题了,被迫思考。

    架构的落地

    任何的架构必须可以落地,可以实现。不能落地,只能停留在ppt上面的架构,那只能忽悠人。这种架构,对实际不仅没有指导作用,还会有反作用,对实际开发产生误导。

    而一个架构师,应该跟踪从架构设计到架构落地到完整过程,“理论“到“实际“必然是有间隙的,跟踪这个过程,实时修正,才可能真的做到“理论“与“实际“的统一。

    业务架构vs.技术架构vs.基础架构

    基础架构:这个很容易理解,IDC、云平台、网络、分布式存储、数据库、消息中间件、SOA中间件、缓存、监控系统、大数据计算平台。。。

    技术架构:为了支撑某类业务,强调系统的“高性能“,“高并发“,“高可靠“、强一致性等。

    业务架构:同样是为了支撑某类业务,但和技术架构的侧重点不同。业务架构强调的是对“领域“的深刻理解,这通常和“领域专家“密切相关,这里可能会强调系统的“可扩展性“,“可复用性“,对需求的弹性应对。

    自底往上,基础架构、技术架构、业务架构并不是相互独立的,一般都是“业务驱动技术“,2者在互相促进中,同时往深度、广度上发展。

    组织架构与领导力

    再复杂的系统,都是“人“开发出来的。而人多了之后,“人“相关的问题都会自然产生:沟通不充分、组织混乱、职责不清。。。

    作为一个架构师,一般很难“独善其身“,说我只管“技术“,不管“人“。因为你的工作,是一个“团队“完成的,而不是一个“千里走单骑“的英雄。

    所以熟悉整个组织架构,沥青职责,把各种混乱的流程、协作理顺,也是应该考虑在内的。

    另一方面,组织架构和技术架构有着非常强的关联:

    合理的团队,组织架构应该是根据业务的架构来拆分的,业务一直在发展,业务的架构也会一直迭代,组织架构也跟着迭代;

    但现实中,往往遇到的情况是组织架构僵化,因为这涉及到利益分配,结果是组织架构约束了业务架构,也约束了技术架构的发展。而这就是看公司高层的领导力了。

    总结

    说到现在,你会发现,我可能说的并不是一个“纯粹的架构师“。的确如此,上面这些是我认为作为一个“技术人“,应该去不断修炼的东西,而不是光“架构师“需要。

推荐阅读:java架构师指南之什么是架构和架构本质


  • 发表于 2020-07-01 20:13
  • 阅读 ( 117 )
  • 分类:技术干货

0 条评论

请先 登录 后评论
江南
江南

1 篇文章

作家榜 »

  1. JAVA Q&A 171 文章
  2. 江南 1 文章
  3. 伯乐 0 文章
  4. 孤存 0 文章
  5. q21164340 0 文章
  6. 赫敏12 0 文章
  7. 子牙 0 文章
  8. 赫敏 0 文章