2、业务理解和抽象能力:驾驭概念的技能是最高潜力
总结:抽象能力是善于把实物概念化并归类。
业务理解:
架构师需要理解业务,并转换为可被研发理解的实现方案,因此业务理解能力是架构师的必备技能。
通常来说一个资深的业务架构师,对业务有足够的敏感度和深入的认知和积累,能够清楚地知道自己的设计能给公司带来多大的业务影响,应该能大概预判业务未来的发展趋势,以便在系统的可扩展性上留好一定的空间,所以也会很自然的出现有些业务架构师做着做着就干脆转为PD类型的角色。
抽象能力:
是通过对业务的理解转换为系统实现的模型,这显然也是重要的能力,抽象很多时候也承担了分解清楚多个团队的职责,分工清晰化。
“逻辑思维,抽象思维”比“编码的时间”对架构师而言更为重要,如果你不能让某个非IT人员明白某个概念在说什么,这个架构师注定也是失败的
逻辑思维不用展开多说,程序员的代码都是逻辑,如果XXX就YYY,如果AAA就BBB,缺乏良好的逻辑思维能力基本不可能成为好的架构师,甚至好的程序员。
抽象思维又分两点,一个是将实在的事物概念化,一个是将模糊的感觉数量化。一个苹果,抽象为质量、大小、颜色、形状、味道等,这是概念化,是架构师的必备思维。至于质量、大小、颜色、形状、味道如何转变成数字来描述,这也是架构师必备的思维。
比如面对一个大型的B2C网站,能够迅速抽象为采购->运营->前台搜索->下单->履单这几大块,对系统分而治之,庖丁解牛,早已目无全牛。
有了上述两点,架构师能将一个“虚”的架构概念描述清楚。
3、设计能力:前瞻性的设计眼光,站在技术的山顶向前眺望
1、掌握最新技术:
铁打的程序员,流水的技术。程序员的开发生涯可能长达几十年,但一门技术的平均寿命却不长。因此作为程序员们的技术领袖,架构师必须有 很好的技术前瞻性,要先于大家了解到最新的技术。
2、分析整合能力
架构是过程,并非结果: 架构是架构师洞察内在结构、原则、规律与逻辑的过程,架构师要做到清晰理解系统,以及简洁描述,这是分析整合的能力。
一个架构师必须具备极强的分析能力,要做到根据产品宗旨和目标,分析清楚产品定位以及产品业务,再整合利用现有的技术领域,找出最佳方案,实现产品概念。
3、前瞻性地设计
架构师与技术高手的区别在于,架构师不仅局限于如何调用、如何并发等架构细节(技术高手对这些也非常熟练),还跳出三界,考虑未来问题和潜在风险的应对之道。
一名合格的架构师设计出来的架构是要有前瞻性的,要为了将来的组织能力更上一个台阶而设计, 满足当下需求并能够适当扩展,是遵循架构设计的系统实现要关注的事情,系统是多样的,架构不是,系统是演化出来,架构不是。
要培养自己的技术前瞻性,首要是学好英语(不多届时了,希望未来最先进的技术都首先从国内诞生),看懂外文技术文章,能与业界专家沟通交流,学习别人的实践方案。
反面的例子是,成天将技术前言的名词挂在嘴边,大谈“云计算,SaaS”这些东西,天天吹水,而落不了地(有可能他自己也搞不清概念如何落地)。
技术前瞻性还体现在对新技术的选型上,哪些东西适合自己团队,哪些不适合。学习成本、维护成本、硬件成本、潜在风险等等都是架构师需要考 虑的。
架构师在自己所处的领域肯定了解颇深,未来本领域技术该如何发展,应该有自己的理解。也会对未来技术的发展有所期盼,有自己的见解。当然这属于比较发散的想法,个人有个人的目标。
4、技术深度:透过问题看本质,解决问题和绕开问题
总结:透过问题看本质则是由虚到实,往深层次地挖掘
看到问题的本质,是架构师必须具备的素质。
1、举例:
例子1:菜鸟程序员的如此写php:
echo $_GET[‘username’];
大部分人知道这个出现安全隐患。一般人使用htmlspecialchars解决问题就可以了。但问题的本质是什么?可以从更深的层次去理解:
比如echo是如何执行的?在什么时候执行的?哪些字符可能导致安全问题?htmlspecialchars为什么能解决这个问题?它真的解决这个问题了么?
那么他将会一点一点的进步,逐渐成为一个合格的程序员。
再比如看到一段java代
码,知道它在JVM如何执行;一个跨网络调用,知道数据是如何通过各种介质到达目标(操作系统内核/网卡端口/电磁介质等)。透过问题看本质使架构师能够敏锐地发现底层之真实,系统性端到端地思考问题,识别木桶的短板并解决之。
2、什么是本质?
将世界万物理解为原子,将整个互联网理解成0和1,这倒的确是非常本质了,不过并不能解答任何问题。从问题看本质,实质上是一个从表层逐步深入的过程。在架构师面对一个用户需求时,这个“用户需求”是非常表层的——比如说,一个自动远程备份数据库的功能。而架构师的主要工作,就是把这样的“业务需求”翻译成“技术需求”。这个过程一方面需要通过抽象思维将用户需求提炼为启动、读取、存储、中断处理等模块,而另一方面则需要看到更深层次的网络、操作系统、硬件等方面,以及其可靠性、稳定性、适用性、安全性等问题。
在《技术的本质》这本书中,著名的经济学家布莱恩阐明了技术的本质及其进化机制,其主要表达了以下三个核心观点:
1.几乎所有技术都来自于此前已经存在的技术,就好比C、Java语言就是调动了多个功能最终实现一个功能。
2.技术都是由技术形成的,这句话可能有点难以理解。举例来说,火车的发明其实包含了多种技术,比如蒸汽技术,但蒸汽技术又可以被分解为燃料技术、动力技术等等。
3.技术和生物一样都会进化,但是生物的进化多来自变异,而技术的进化则来自不同技术组合所发生的变化。
布兰恩强调,技术并不会凭空发生。关于计算机技术,无论从前端还是后端,无论是过时还是被炒得很热,无论是云计算还是SAAS等,其本质技术都来自于此前已经存在的技术,都要求具备良好的算法和数据结构,在此基础上不断衍生出许多新技术。
3、挖掘本质
架构师要有将“业务需求”转化为“技术需求”的能力,这是一个本质的挖掘。例如,业务层面看到的是一个“电子商务网站系统”,架构师看到的是一个多人在线,并发交易,需要保证数据一致性的站点、服务、数据系统,功能、性能、扩展性、维护性、安全性、可用性这些字眼会惯性的蹦到架构师的脑子里。
架构师之所以是架构师,他在庞大系统的面前,仍然能够敏锐发现其底层之真实,这就需要,他有多年多领域知识和经验的沉淀。
5、技术广度:要成为百科全书式的智者
总结:1、全面了解各个层面的知识。2、了解主流公司的系统设计,碰到实际问题,很快有多种方案可供评估。
1、全面了解各个层面的知识
首先,作为一名卓越的程序员,架构师肯定不欠缺开发方面的知识。从架构到方法论,从数据处理到安全监控。可以说IT开发层面上,架构师可以做到炉火纯青的地步。但是这仅仅是一名卓越程序员的能力级别,离架构师那还有很大的一段距离。
架构师作为一名技术领袖,需要通过散发知识的光芒来温暖开发团队,如果只一个领域内的知识烂熟于胸,那也仅仅是一名技术高手。要想更进一步,需要对APP层面、服务层面、数据层面均要了解(系统分层),要对研发、测试、运维、安全也要有所了解(职能),上要对接口,下要对原理(接口与实现)都有所了解,甚至,要在多个业务领域都有所涉猎。
有的程序员也会说,如果多学习跨领域、跨学科的东西,会不会成为什么都懂,但什么都不精的人?其实在这里的跨领域,并不是要求大家都成为每个领域的专家。最重要的是有一门敲门砖,学习的引子。如果开发一套金融系统,对于财务结算以及处理方法都不了解,那别说是胜任架构师的任务,连普通程序员的工作也不可能做好。假设大家工作一段时间后,对某领域很了解,但由于工作变动的缘故,到其他公司后,开发的领域完全不会。这里就要用到跨领域知识学习的能力了,需要大家样样都要知晓。
谈到跨领域学习,知识面广似乎是最好实现的目标,只要博览群书,加上高中之前各学科扎实的基础,相信大多数程序员本身就具备一定的跨领域学习的能力。但想成为真正的百科全书式的智者,恐怕不光是简单觉得眼熟就行。在条件允许的情况下,程序员其实可以去参加一些其他领域的专业考试。比如参加会计资格证的考试,抑或其他专业中较初级的考试。这样的经历,主要还是在于“以学促考”,通过一定的压力让自己能钻进去学习。
2、了解主流公司的系统设计
碰到实际问题,很快有多种方案可供评估。
初级架构师所害怕的,是跳出自己的“独门绝技”,在一定程度上说,在一定深度之内成为一个“杂家”也没什么不好。
6、沟通能力:善于沟通的技术领袖
总结:沟通能力确保各方对架构达成共识,愿意采取行动
1、开发过程沟通
架构师必须参与项目开发全过程,包括确认需求、系统分解、架构设计、技术选型、制定技术规格说明、系统实现、集成测试和部署各阶段,在这一系列过程中,架构师会与各部门沟通交流。
一个产品会有多部门合作,架构师在其中的沟通极为重要,直接影响产品进度与质量。架构师不仅要与开发人员沟通,也要和项目经理、分析人员甚至用户沟通,来实现产品的各种可能性。
架构师和项目经理,对沟通能力的要求都很高,很多互联网公司甚至直接由架构师担任项目经理的角色。这两个角色其实还是有所偏重的,项目经理更倾向于与客户的交流,跨团队的协作与交流,架构师主要偏向技术团队内部的沟通与交流,纯技术上的沟通。
2、如何善于沟通:
如何成为一名“善于沟通”的架构师呢?在目标清晰的前提下:
1、首先做到平和:
不能将自己所在象牙塔上,颐指气使的发号施令,这样的态度必然遭恨,大家都是技术人员,只是分工不同,为何要受你的气呢?
2、架构师要有一定的绘图能力。
人对图形的理解远大于对文字的理解,一个层次图,一块小白板,几只笔,真的这么容易把问题描述清楚么?
做到人性化的沟通,需要我们在平时就进行培养。写出大部头的架构书,有的时候并没有用VISIO画出的简单架构图好理解。人对图形理解远远大于对文字的理解,直观简单的UML图可以极大的方便程序员理解架构师的意图。
3、召开小范围的技术人员会议,大家一起来讨论
其次,可以召开小范围的技术人员会议,大家一起来讨论,一起理解架构师真正的意图。甚至就是一块小白板,几支笔就能把问题摆清楚,讲明白,统一意见后的团队必然干劲十足,再不会出现互相推诿的情况。
架构师就相当于一支球队的主教练,如何将自己布置的战术交到执行的球员,也就是开发人员的脑袋里,是关乎胜利的关键。那么怎样才能成为一名能说会道的程序员呢?
在一般人的印象里,程序员都是一群略显呆滞,沟通能力不强的技术狂人。逻辑思维非同常人,但就是倒不出来。有些人通过找女朋友作为旁证,连经济适用男中的定义原型都是IT人士,月薪4000以上,不善言谈,最后娶一剩女为妻。看来我等程序员,真的只能被人如此定义了。虽说架构师技术层面上的东西与前例不可同日而语,但是也看到沟通能力上,程序员还有很大的发展空间。
7、系统性的思考:权衡利弊,只有合适没有喜欢
总结:系统性地思考:平衡取舍能力确保架构在现有资源约束下是最合理的,理想最终照进现实。
一名能说会道的程序员呢?
在一般人的印象里,程序员都是一群略显呆滞,沟通能力不强的技术狂人。逻辑思维非同常人,但就是倒不出来。有些人通过找女朋友作为旁证,连经济适用男中的定义原型都是IT人士,月薪4000以上,不善言谈,最后娶一剩女为妻。看来我等程序员,真的只能被人如此定义了。虽说架构师技术层面上的东西与前例不可同日而语,但是也看到沟通能力上,程序员还有很大的发展空间。
7、系统性的思考:权衡利弊,只有合适没有喜欢
总结:系统性地思考:平衡取舍能力确保架构在现有资源约束下是最合理的,理想最终照进现实。