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