精华内容
下载资源
问答
  • 摘要:本文主要探讨架构师的能力要求是什么?架构师价值体现在哪里?架构师的价值体现有几个层次?

    摘要:本文主要探讨架构师的能力要求是什么?架构师价值体现在哪里?架构师的价值体现有几个层次?


    一. 什么是架构师?

    百度百科:

    架构师是一个技术性角色:确认和评估系统需求,给出开发规范,搭建系统实现的核心构架,并澄清技术细节、扫清主要难点。真正的系统架构师,是软件架构的设计者,是企业软件产品、新技术体系的构建者。


    二. 架构师的分类?

    架构无处不在,有大有小,有很多种分类方法,可以根据网络分层分,也可以根据业务领域分,这里仅仅列举几个案例:

    系统架构师、子系统架构师、组件架构师、中间件架构师、运维基础设施架构师、前端架构师、后端架构师、安全架构师、无线网架构师、企业IT架构师


    三. 架构师的关注点?

    主要着眼于系统需求的“技术实现的架构”,不是人力资源的分配或项目管理,也不是具体的编码实现,包括:

    (1)技术实现的可行性。

    (2)技术实现的架构


    四. 什么是架构?

    软件架构(software architecture)是有关软件整体结构与组件抽象描述,用于指导大型软件系统各个方面的设计。

    软件架构是一个系统的草图

    组件切分:系统中各个组件的抽象切分和构成。

    组件关系:明确的各个组件之间的连接关系。

    组件通信:明确的各个组件之间的通讯方式。

    在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象。在面向对象领域中,组件之间的连接通常用接口(计算机科学)来实现。 软件体系结构是构建计算机软件实践的基础。


    五. 架构师的能力要求?

    1. 技术能力(业务相关)

    技术能力,这是最重要的能力。

    科学与技术常常放在一起,科学解决理论问题,技术解决实际问题。

    所谓技术能力,是指

     

    (1)熟悉主流技术基本原理的能力:销售需要熟悉人性、管理者需要熟悉管理的软技能、架构师需要熟悉各种主流技术的原理,这是架构师的立身之本。

    (2)熟悉各种业务应用场景的能力:所有的项目都有它特定的业务场景,用于帮助他们的客户解决问题。不同的业务场景本质就是客户的需求。所有的技术方案,都必须是为客户的业务需求服务的,再好的技术方案,如果脱离了客户的需求,也是空中楼阁,南辕北辙,容易犯纸上谈兵的错误。

    (3)自身快速解决问题的能力:架构师需要有能力采用系统的、结构化的方法以及利用自身丰富的经验,从各种纷繁复杂的问题的表面现象中,进行系统、有序的梳理,逐渐排除干扰因素,快速的进行问题的收敛和定位。架构师的优势在于在现象之外,看到问题背后的本质,架构师的优势在于"系统性”和“全局性”。

    (4)预见技术难点和技术风险的能力:架构师要能够预见技术方案未来的可能会遇到的各种难点风险,包括技术的和因技术导致的非技术的风险,并提出预见性的预防措施。这是一个容易被忽略的能力,但这个能力对于推动项目的顺利进展,避免项目遇到各种幺蛾子事件起到了至关重要的作用。未来的不确定性是任何领域都面临的共同难题,架构师此处的价值在于,把技术带来的不确定性展现出来,协作管理者把不确定性的影响控制在可接受的范围以内。

    一个优秀的架构师:

    广度上,不断拓展自己的知识面。

    深度上,深耕和深挖关键的、核心的技术领域。

    架构师不能长期性的陷入到项目中重复性的琐碎事情之中,它将会使架构师逐渐失去对技术系统全局性的把控能力,对技术的长期演进的预见能力。


    2. 架构能力(计算机相关)

    架构能力主要表现为:

    (1)熟悉主流的架构的能力:

    主流的架构是经过行业内各方力量总结、汇总、甚至验证过的成功的经验总结。

    熟悉各种主流架构的特点、缺点、优点、应用场景,可以避免架构师闭门造车,利用或选型好主流的架构,可以避免项目承担不必要的风险、可以极大的加速项目的进展。


    (2)抽象的能力

    架构师对系统组件的分解大都在抽象层面,可以适用于不同编程语言的具体实现。

    只有高度的抽象,才能抓住现象背后的本质,才能具备广泛的适应性和扩展性。这是架构师与程序员一个重要的区别。

    程序员重在通过具体的编程语言实现具体的目标,是可工作的软件,重在实现,因此有时候看起来是“有形”和“实在”。

    架构师重在组件的抽象性和适应性,是纸面上的设计,重在“质”和“核”,因此有时候看起来是“无形”或“虚”。


    (3)设计的能力

    架构师拿到的是需要和目标,架构师需要有能力把需求和目标,转换成内部的设计。

    设计相对于实现而言的,设计本质上是一种技术的规划。设计是把一种设想,通过合理和周密的技术规划,通过各种方式表达出来的过程。这个规划能力与项目管理的计划是类似的,项目管理规划的对象是:人、时间、金钱等现实资源;架构师规划的对象是:CPU的计算、内存、软件的组件等计算机资源。


    (4)整体规划的能力:

    架构师是站在系统的视角审视整个系统内的组件以及之间的关系,甚至要跳出系统,站在系统外,审视系统整体表现出来的外部行为。

    这是与程序员另一个重要的区别。

    程序员是“局部优先”为基本原则,确保负责的模块,功能和性能都达到最优。

    架构师是“整体最优”为基本原则,确保系统在整体性能和效率最优,有时候会牺牲一部分”局部最优”来换取“整体最优”。

    比如: Y=A*B,

    方案1:A=9,A是最优的,但B=1;整体效果Y=9*1=9; 

    方案2:A=5,  A不是最优的,B=5,也不是最优的; 整体效果Y=5*5=25,方案2性能远远大于方案1;


    (5) 拆分和还原的能力

    一般情况下,大型的目标软硬件系统都是比较复杂的,是经过无数前人的劳动,才造就了当下的目标系统。

    架构师需要在此基础上,添砖加瓦。但如果不熟悉现有系统,架构师很可能添错了砖,加错了瓦,使得系统漏洞百出。

    因此架构师需要首先熟悉现有系统的架构。架构师要有能力把现有的系统进行拆解,拆解成简单的组件、理解组件的关系、组件之间的工作流程和工作原理,最后,再还原成整体架构,从系统外看系统的整体行为。

    客户的新的需求或目标是糊的,复杂的,架构师需要对客户的需求和目标,进行拆分/解,把复杂变成简单、把模糊变成具体,然后再把这些拆解后的、具体的功能需求,按放到现有系统的各个组件上。


    (6) 拆分与重构的能力

    这是容易被忽略的能力,相当多的架构师,是在现有系统上做一些添砖加瓦增补的工作,因此这方面的能力大多情况下无法体现。

    一个架构师,如果有幸参到一个从无到有,有小变大,由简单到复杂演进的系统中,那他是幸运的,这时候拆分与重构的能力就尤为重要。

    一个复杂系统的形成,中间会经历很多次的演进和重构,重构的能力是上述多种能力的综合:需要熟悉业务系统,需要熟悉现有系统的架构,还需要熟悉重构后的系统架构等等。

    如果说“拆分与还原”的能力是“改良”的话,“拆分与重构”就是“革新”,甚至是“革命”。在一个旧系统之上,重构一个具有旺盛生命力的新系统,对于重构者的能力的要求是相当高的。除了技术上的难度外,还会受到原先系统内力量的阻力、抗拒、质疑,也会受到新系统架构不确定性带来系统外阻力、抗拒、质疑。


    3. 沟通能力

    最终的技术实现,都是要靠人完成的,沟通能力,虽然不是技术能力,但也非常重要。

    作为一个优秀的架构师,你需要清楚的知道客户的需求,需要不断和需求人员进行沟通,以达到客户真正的目的。

    作为一个优秀的架构师,你需要与项目中的不同团队、不同人进行各种沟通,以推行你的架构设计和架构的主张。

    作为一个优秀的架构师,你需要在不同团队之间存在技术争议模棱两可的时候,进行技术实现上的平衡和仲裁。

    作为一个优秀的架构师,你需要有能力与组织的决策者沟通,给决策者提供技术的演进和发展方向的信息,有时候甚至说服决策者采用和推进某种技术方案。

    其实,不仅仅是架构师,只要需要与人打交道,都需要提高自己的沟通和表达能力。

    有一个普遍而有意思的现象,做领导的大多不是技术特别牛的,但沟通能力肯定是最好的,这体现出沟通能力及其重要的作用。


    六、架构师的价值与价值等级

    在这里,把架构师的价值分为4个等级:

    L1: 一知半解型:

    了解或熟悉系统的局部架构,能够在现有系统之上进行添砖加瓦增补工作,以及常规的维护工作。

    L1等级的架构师的价值,主要体现比其他人多了解一点业务系统全局性的知识,能够有助于在不同的组件之间进行适当的协调,辅助其他成员共同完成添砖加瓦增补任务。

    L1等级的任务,很难体现架构师真正的价值,架构师的价值只能通过其他渠道得以体现。

    L1等级的价值,只能体现在当前系统,很难迁移到其他系统之上。


    L2: 拆解还原型

    熟悉现有系统的架构,能够对现有的系统进行拆解与还原,熟悉系统的各个组件静态的结构关系以及动态的交互关系。

    L2等级的架构师的价值,主要体现对系统有一个全面的认识,能够做出全面的判断和决策,能够领导不同的团队进行技术协作,并在不同团队的“局部优先”发生冲突的时候,做出“全局优先”的仲裁。

    L2等级的任务,能够体现架构师的表面价值

    但L2等级的价值,能否迁移到该系统之外,取决于该系统本身的性质。

    如果当前的系统是公司内业务专有系统时,就很难迁移到其他系统之上,更难迁移到行业外的系统之上。


    L3: 革新型

    能够对现有系统架构进行拆解还原型,并能够在现有的系统架构基础上选用新的方式进行优化。

    L3等级的架构师的价值,除了体现在对现有系统设计的增减功能实现的决策权,还体现在对现有系统未来优化演进方向选择上以及如何优化技术决策上,能够带领技术团队走向进一步的完善

    L3等级的任务,能够体现架构师的核心价值

    L3等级的价值,能够迁移到其他系统之上,可以迁移到现有系统之外。


    L4: 革命型:

    能够推翻现有的系统架构,建立一套全新的、超越现有系统架构的架构,并能够给组织带来意想不到的收益、甚至开辟新的技术领域和业务领域。

    L4等级的架构师的价值,主要体现在,当组织现有技术架构遇到困境,通过改进无法得到效果时,能够代领组织突破现有技术架构的局限,重构一套新的技术架构,使得自组织效率、效益的得到极大提升,为组织创造新的价值,为开辟一片新天地。

    L4等级的任务,能够体现架构师的超核心价值

    L4等级的价值,不但可以迁移到现有系统之外,还可以创造新的系统。


    七、职业发展路径:

    系统级架构师通常由系统开发工程师SE或程序员或组件架构师发展而来,可以向研发总监,高级技术总监、或技术专家、首席架构师、CTO等高层次的方向发展。


    结束语:

    上述的表述纯属个人的理解,有些表述,特别是对架构师的能力与价值部分,纯属自己个人的新定义,有不当之处敬请一起探讨。

     

    展开全文
  • 架构师成长之路(3)--如何成为架构师(方法)

    万次阅读 多人点赞 2015-10-26 17:18:00
    如果我们要成为架构师,我们自己要面临的三大问题: 找准自己定位:我是谁?在哪里? 怎样做好架构师:我要做什么? 如何搭建架构师知识体系:我该怎么做? 这里面就是做事方法论:目标(我要做什么),方法(计划)...

    前言:

    哲学家常思考的问题:" 我是谁?"" 我从哪里来?"" 要到哪里去?不只是哲学家,我想每个人都有自己对这三个问题的认知。
    如果我们要成为架构师,我们自己要面临的三大问题:
    找准自己定位:我是谁?在哪里?
    怎样做好架构师:我要做什么?
    如何搭建架构师知识体系:我该怎么做?
    这里面就是做事方法论:目标(我要做什么),方法(计划)(我该怎么做),  执行/行动
    
    

    0.能力等级定义


    心理学家德雷福斯经过了大量的调查研究,将人分成了五个等级,构建了“德雷福斯等级模型”。五个等级分别为:新手、进阶新手、胜任者、精熟者以及专家。简单列举一下每个等级的特点,方便我们定位自己在哪个等级。参考《卓越密码:如何成为专家》。

    1、新手:新手一般是初入职场1~3年的员工。他们的特点是严格遵照规定,不会有太多自己的想法,因此不会出大的错误也不会有太大的成绩。

    2、进阶新手:工作几年后,新手开始学会细分任务,慢慢地对工作有了自己的想法。这个时候,已经能达到进阶新手的阶段。

    3、胜任者:第三个阶段是胜任者。胜任者顾名思义,在工作岗位上能够保质保量地完成任务,而且能够制定计划和按情况处理任务。

    4、精熟者:与胜任者相比,精熟者开始能发现工作中出现的问题,并对问题有着自己的思考。此时,精熟者开始建立了自己工作的大局观和整体观,处理问题的时候也更加灵活。

    5、专家:最后一个阶段就是专家,专家的过人之处在于其“无招胜有招”。因为专家工作已经不需要具体的方法和规则,他们的工作就是从现在已有的工作方式中去探寻更个性化、有创造力的解决问题的方法。

     

    我们研发人员发展的技术路径(仅供参考):

     

    一、初级工程师

       具备技能:学习的知识是语言基础、计算机基础理论、网络基础,操作系统等相关基础知识等,应该在大学完成。 依靠指令清单,必须按部就班。

       知识能力:入门了解。知道概念。对全局性、体系性的东西没兴趣。需要有人指导才能干活。但可以靠着百度解决具体的小问题。

    二、中级工程师

       成长阶段:一般工作一年后。

       具备能力:能够独立解决各种各样的领域内问题。

       知识能力:熟练掌握语言工具,技术过硬。

    三、高级/资深工程师(管理自己):

        成长阶段:工作3-5年后,熟悉分布式系统、高性能系统搭建。精通某种开发语言,掌握架构设计能力和业务理解能力。熟练掌握各种设计模式以及具备一定运维能力。
        技术能力:
              1、负责核心复杂功能的实现方案设计、编码实现  。
              2、负责疑难BUG分析诊断、攻关解决

        知识能力:精通语言工具。技术精湛,技术高超、博学多识, 精益求精。

    、资深工程师:

          高级工程师是在技术深度上精通,资深需要在广度上扩大知识面,熟悉多种开发语言。同时具备团队管理经验。
          具备独立设计一个业务模块的能力,并且能够独立设计数据库表以及UML画图,利用部分设计模式以及懂得算法和效率的高质量代码。

    五、技术经理/研发Leader(管理一个团队)

         成长阶段:技术经理本身就是从资深工程师发展而来,很多公司的技术经理根本没有从一线研发做起,大部分就是一个项目经理,带带项目为主,根本无法胜任真正意义上的“技术经理”的工作。
         具备能力:
          1、技术能力:
           1)首先需要具备核心模块代码编程的能力,从设计方案到核心编码,再到后期的代码review,这方面是要能完全胜任的,能识别开发风险。
           2)代码模板研发与推广、最佳实践规范总结与推广、自动化研发生产工具研发与推广
         2、团队管理能力:
           任务管理:开发工作量评估、开发任务分配,
           团队效率:能够帮助团队人员提升能力,以及推动更加合理的考核机制。
           团队专业力:招聘面试、新人指导、领导复盘总结改进
         3、综合能力(沟通协调)能力:此外,还需要具备协调的能力,以及与人打交道的能力。与平级部门、产品、设计、测试、运营打交道的能力。

    五、架构师(专注某个平台的技术架构规划)

    成长阶段:
    能称得上“架构师”的,工作年限至少也要在5至8年以上,具体还要看个人的学习能力、领悟能力和成长速度。
    之所以有架构师这个称谓,主要是由于公司发展壮大之后,需要专注于技术的人才做专业的事;所以,架构师也可以理解为技术专家,以攻克公司技术难题为主。
    需要分离管理族和专业族。整个研发团队可能已经超过100来人了,需要有人专注来做架构规划、设计、日常维护。不能让研发总监和研发Leader又做管理又做技术一股脑都扔给他们。
    具备能力:
    1、架构分析:从功能性需求中识别出需要增加的非功能性需求,好满足性能、可扩展、解耦/集成、安全、可运维、高可用、易部署、易更新。并且识别完非功能型需求,还要做技术选型、技术架构风险识别、技术实现工作量评估
    2、架构设计与实现:非功能性模块的架构设计、接口设计、代码实现。所以需要的是有代码实现能力还要有架构思维的工程师,不需要画PPT的工程师
    3、业务架构设计与实现:需要对跨系统的接口进行识别、实现、维护,需要对能写成公共代码类库的进行分析、识别、接口设计、实现、变更维护。
    4、重构:架构师需要经常做Bug分析、非模板性和公共类库代码检查,以发现代码腐烂程度,以发现还有哪些代码没有做很好的架构与精心的代码设计。所以重构是经常性维护发生的,不是攒到某一刻动大手术,甚至推翻重做,那就不叫重构了。

     

    五、技术总监(管理多个团队leader):

         成长阶段:一般需要工作8至10年以上,首先,技术经理的工作能够做的非常好,再加上公司的发展需要,需要能够同时带领多条业务线或者多个团队共同协作的时候,基本就是技术总监了。
    从管理的层级,技术总监同时管理多个技术经理,管理从业务线划分的团队。
    从技术的层级,能胜任架构师这个级别,也就是技术专家。
         具备能力:
        1、从业务线和团队的角度,需要具备组建研发部、搭建公共技术平台、方便上面各条产品线开发。
        2、通过技术平台、通过高一层的职权,管理和协调各个产品线组。现在每个产品线都应该有合格的研发Leader和高级程序员了。

    五、CTO (软件产品和技术是统一管理的.是商业、产品、技术、管理、团队相平衡的综合统管)。

    成长阶段:CTO的要求是最高的,不是每一个人都胜任CTO,好的CTO在国内非常少,非常稀有。
    可能不少同学会认为CTO只是专注于技术,或者进入一些小公司,挂职某某CTO就认为达到了这个级别,其实这是错误的。
    CTO是一个系统的成长轨迹,不是一朝一夕可以练成的,需要后天的巨大“自我改进”能力。
    CTO,是集软件、产品、技术、管理等诸多能力为一体的,CTO做的事情,是商业、产品、技术、管理、团队相平衡的综合统管。

    具备能力:
    1、业绩达成:洞察客户需求,捕捉商业机会,规划技术产品,通过技术产品领导业务增长,有清晰的战略规划、主攻方向,带领团队实现组织目标
    2、前沿与平台:到这个研发规模规模级别了,一定要有专门的团队做技术应用创新探索和前沿技术预研。而且要和技术平台团队、应用研发团队形成很好的联动作用,让创新原型试点能够很平滑的融入商业平台再让应用研发线规模化的使用起来。大量的前沿探索都死在了内部,做完试点就停滞了,这就需要CTO做好整体的衔接推动工作。
    3、研发过程管理:站在全局立场来端到端改进业务流程,为业务增长提供方便
    4、组织与人才建设:公司文化和价值观的传承;研发专业族团队梯队建制建设、研发管理族团队梯队建制建设;创建创新激发机制,激发研发人创新向前发展,激发黑马人脱颖而出

     

           软件架构师的正式成型在于机遇、个人努力和天赋 软件构架师其实是一种职位,但一个 程序员在充分掌握软构架师所需的基本技能后,如何得到这样的机会、如何利用所掌握的技能进行应用的合理构架、如何不断的抽象和归纳自己的构架模式、如何深入行业成为能够胜任分析、构架为

    一体的精英人才这可不是每个人都能够遇上的馅饼。

    我们找好路径以后,看看我们如何做?  《卓越密码:如何成为专家》这本书里面,介绍的方法是:
    学习能力:确定方向目标,选择高质量学习内容、学习元认知,持续精进学习。
    不断实践:实践检验理论,解决问题,总结提炼。
    思维能力:擅长思考、深度思考:学会归纳、概括,概念,推理。掌握结构化、抽象、系统性、框架等思维。

     

     

    1、走正确的路:高效地学习


      如果想成为一个架构师,就必须走正确的路,否则离目标越来越远,正在辛苦工作的程序员们,你们有没有下面几种感觉?

         一、我的工作就是按时完成领导交给我的任务,至于代码写的怎样,知道有改进空间,但没时间去改进,关键是领导也不给时间啊。

         二、我发现我的水平总是跟不上技术的进步,有太多想学的东西要学,Jquery用的人最近比较多啊,听说最近MVC比较火,还有LINQ,听说微软又有Silverlight了……

         三、  我发现虽然我工作几年了,除了不停的coding,Ctrl+c和Ctrl+V更熟练了,但编码水平并没有提高,还是一个普通程序员,但有人已经做到架构师了。

         四、工作好几年了,想跳槽换个工作,结果面试的考官都问了一些什么数据结构,什么垃圾回收,什么设计模式之类的东西,虽然看过,但是平时用不着,看了也忘记了,回答不上来,结果考官说我基础太差。。。

    有没有,如果没有,接下来就不用看了,你一定是大拿了,或者已经明白其中之道了,呵呵。

    如果有,恭喜你,你进入学习误区了,如果想在技术上前进的话,就不能一直的coding,为了完成需求而工作,必须在coding的同时,让我们的思维,水平也在不停的提高。

     

    写代码要经历下面几个阶段:

    一 、你必须学习面向对象的基础知识,如果连这个都忘了,那你的编程之路注定是在做原始初级的重复!

        很多程序员都知道类、方法、抽象类、接口等概念,但是为什么要面向对象,好处在哪里,要解决什么问题?只是明白概念,就是表达不清楚,然后在实际工作中也用不上,过了一段时间,面向对象的东西又模糊了,结果是大多数程序员用着面向对象的语言做着面向过程的工作,因此要学习面向对象,首先应该明白面向对象的目的是什么?

    面向对象的目的是什么?

         开发语言在不断发展,从机器语言,到汇编,到高级语言,再到第四代语言;软件开发方法在不断发展,从面向过程,面向对象,到面向方面等。虽然这些都在不断发展,但其所追求的目标却一直没变,这些目标就是:
       1.降低软件开发的复杂度
       2.提高软件开发的效率
       3.提高软件质量:可维护性,可扩展性,可重用性等。

         其中语言的发展,开发方法的发展在1,2两条上面取得了极大的进步,但对于第3条,我们不能光指望开发方法本身来解决。

    提高软件质量:可维护性,可扩展性,可重用性等,再具体点,就是高内聚、低耦合,面向对象就是为了解决第3条的问题。因此要成为一个好的程序员,最绕不开的就是面向对象了。

     

    二、 要想学好面向对象,就必须学习设计模式。

         假定我们了解了面向对象的目的,概念了,但是我们coding过程中却发现,我们的面向对象的知识似乎一直派不上用场,其实道理很简单,是因为我们不知道怎么去用,就像游泳一样,我们已经明白了游泳的好处,以及游泳的几种姿势,狗刨、仰泳、蛙泳、自由泳,但是我们依然不会游泳。。。。

    因此有了这些基本原则是不行的,我们必须有一些更细的原则去知道我们的设计,这就有了更基础的面向对象的五大原则,而把这几种原则更详细的应用到实际中来,解决实际的问题,这就是设计模式,因此要学好OO,必须要学习设计模式,学习设计模式,按大师的话说,就是在人类努力解决的许多领域的成功方案都来源于各种模式,教育的一个重要目标就是把知识的模式一代一代传下去。

         因此学习设计模式,就像我们在看世界顶级的游泳比赛,我们为之疯狂,为之着迷。

     

    三 学习设计模式

         正像我们并不想只是看别人表演,我们要自己学会游泳,这才是我们的目的所在。

    当我们看完几篇设计模式后,我们为之精神振奋,在新的coding的时候,我们总是想努力的用上学到的设计模式,但是经常在误用模式,折腾半天发现是在脱裤子抓痒。。。

    当学完设计模式之后,我们又很困惑,感觉这些模式简直太像了,很多时候我们分不清这些模式之间到底有什么区别,而且明白了设计过程中的一个致命的东西--过度设计,因为设计模式要求我们高扩展性,高重用性,但是在需求提出之初,我们都不是神,除了依靠过去的经验来判断外,我们不知道哪些地方要扩展,哪些地方要重用,而且过去的经验就一定是正确的吗?所以我们甚至不敢再轻易用设计模式,而是还一直在用面向过程的方法在实现需求。

     

    四 学习重构

     

         精彩的代码是怎么想出来的,比看到精彩的代码更加令人期待,于是我们开始思考,这些大师们莫非不用工作,需求来了没有领导规定完成时间,只以设计精彩的代码为标准来开展工作?这样的工作太爽了,也不可能,老板不愿意啊。就算这些理想的条件他都有,他就一开始就设计出完美的代码来了?也不可能啊,除非他是神,一开始就预料到未来的所有需求,那既然这些条件都没有,他们如何写出的精彩代码?

        Joshua Kerievsky在那篇著名的《模式与XP》〔收录于《极限编程研究》一书)中明白地指出:在设计前期使用模式常常导致过度工程(over-engineering)。这是一个残酷的现实,单凭对完美的追求无法写出实用的代码,而「实用」是软件压倒一切的要素。

         在《重构-改善既有的代码的设计》一书中提到,通过重构(refactoring),你可以找出改变的平衡点。你会发现所谓设计不再是一切动作的前提,而是在整个开发过程中逐渐浮现出来。在系统构筑过程中,你可以学习如何强化设计;其间带来的互动可以让一个程序在开发过程中持续保有良好的设计。

        总结起来就是说,我们在设计前期就使用设计模式,往往导致设计过度,因此应该在整个开发过程,整个需求变更过程中不断的重构现在的代码,才能让程序一直保持良好的设计,由此可见,开发过程中需要一直重构,否则无论当初设计多么的好,随着需求的改变,都会变成一堆烂代码,难以维护,难以扩展。所谓重构是这样一个过程:「在不改变代码外在行为的前提下,对代码做出修改,以改进程序的内部结构」。重构的目标,就是设计模式,更本质的讲就是使程序的架构更趋合理,从而提高软件的可维护性,可扩展性,可重用性。

    《重构-改善既有的代码的设计》一书也是Martin Fowler等大师的作品,软件工程领域的超级经典巨著,与另一巨著《设计模式》并称"软工双雄",不可不读啊。

     

    五 开始通往优秀软件设计师的路上

    通过设计模式和重构,我们的所学和我们工作的coding终于结合上了,我们可以在工作中用面向对象的思维去考虑问题,并开始学习重构了,这就像游泳一样,我们看完了各种顶级的游泳比赛,明白各种规则,名人使用的方法和技巧,现在是时候回家去村旁边的小河里练练了,练习也是需要有教练的,推荐另一本经典书叫《重构与模式》,引用他开篇的介绍,本书开创性地深入揭示了重构与模式这两种软件开发关键技术之间的联系,说明了通过重构实现模式改善既有的设计,往往优于在新的设计早期使用模式。本书不仅展示了一种应用模式和重构的创新方法,而且有助于读者结合实战深入理解重构和模式。

    这本书正是我们需要的教练,值得一读。

     

    六 没有终点,只有坚持不懈的专研和努力。

          经过了几年的坚持,终于学会了灵活的运用各种模式,我们不需要去刻意的想用什么模式,怎么重构。程序的目标,就是可维护性,可扩展性,可重用性,都已经成了一种编程习惯,一种思维习惯,就像我们联系了几年游泳之后,我们不用再刻意的去考虑,如何让自己能在水上漂起来,仰泳和蛙泳的区别..... 而是跳进水里,就自然的游了起来,朝对岸游去。但是要和大师比起来,嘿嘿,我们还有很长的路要走,最终也可能成不了大师,但无论能不能成为大师,我们已经走在了成为大师的正确的路上,我们和别的程序员已经开始不一样,因为他们无论再过多少年,他们的水平不会变,只是在重复造轮子,唯一比你快的,就是ctrl+c和ctrl+v。

    正确的路上,只要坚持,就离目标越来越近,未来就一定会是一个优秀的架构师,和优秀架构师的区别,可能只是时间问题。

     

     

     

    2、大牛的法宝:不断实践总结


         原文:http://www.cnblogs.com/seesea125/archive/2012/03/30/2425281.html

         接下来我们就要往这个方向努力。然而如唐僧去西天取经一样,要历经种种磨难,一路上打败各种妖魔鬼怪才能继续前行,所以唐僧取经,第一件事,就是招徒弟,遇见妖魔鬼怪就让技术高超的徒弟打败它,徒弟不听话就念紧箍咒,徒弟也搞不定的妖怪,就请观音菩萨搞定,这就是唐僧成功的法宝,没法宝上路,看来我们会死的比较惨啊,哈哈。

        我们在通往架构师的路上,同样会遇到各种各样的问题,但不幸的是,没有菩萨在暗中相助,要是有牛人相助你,那老兄你太幸运了,成功几率大大增加。但我们没有牛人帮助,更没有技术高超的徒弟一路保驾护航,关键招徒弟得开工资啊,我们还穷的自己还养不活呢,怎么办呢?干脆自己动手,找几件护身法宝,留着路上除妖之用。

        问题是从哪找呢?百思不得其解,俗话说思索不如搜索,干脆百度一把,看看牛人都是怎么炼成的,找来找去,还真总结出几个牛人身上的通用法宝,当然独门绝技之类的就不拿了,太多那不动,呵呵。拿着这些法宝上路,嘿嘿,那我们就不是骑着白龙马去西天了,我们骑着摩托去西天,那速度可要快多了。

     

    法宝一:牛人爱惜自己的时间。

        时间就是金钱,时间就是生命,时间如同健康一样,如果时间都没有,那成功也就是浮云了。所以牛人总是很爱惜自己的时间,总是在想办法提高自己的做事效率。我突然想了起来,我QQ里有几个牛人,问问他们点经验,结果大大出乎意料,个个不在线,好不容易发现个牛人在线,当然关系还不错的,至少不会不给面子吧?于是就QQ说一句客气话,“老兄,好久不见啊,最近在忙什么呢?”,消息发出去石沉大海,到第二天上QQ才收到一句回复,“不好意思,昨忙,有事直接打电话”,言简意赅,效率奇高,再想想我们这些普通人的时间真多,一聊天就是半天,搞不好还有N个QQ群在不停的弹窗……

        偶然看到一本书,《时间管理:小强升职记》,顺便打开看下,第一句话这么说的,“前一种人用20%的时间完成了后一种人用80%的时间才能完成的事情,因此前一种人忙着考虑如何打发闲暇时间,后一种人则忙着煮方便面和熬夜。

        假设上面说的真的,我初略算了算,如果一天工作时间8个小时,则牛人的效率,可能就1,2个小时就干完了,这么一算,牛人忙和一年,则等于普通人忙和了4,5年啊!法宝,这绝对是牛人致胜的第一大法宝,俗话说,唯有以快制慢,方能笑傲江湖,没错,东方不败牛就牛在,速度快,快到你还没出招就搞定你了。强大啊,这个法宝一定要随身携带,哈哈。

        所以看了这本书后,我做的第一件事就是QQ关了,动不动就一闪一闪的,思路一直被打断,这不是在浪费自己最大的资本--时间吗?关了几天,发现效率果然出奇的高多了,QQ真是害人不浅啊,当然爱惜时间,还有很多经验,建议有空看看相关的书,受益不浅啊,嘿嘿。 

     

    法宝二:牛人善于总结

         算了算我记得的牛人,包括古代的,孔子,老子,孙子,曹雪芹,鲁迅。。。我想了一下,为什么能记住他们呢,几千年前来,轰动一时的人物应该年年有,代代有,但我们为什么只记住了这些人?很容易想明白了,他们有个共同的特征,就是总结自己的思想,写成了书,并把这种思想传承了下来,而那些身怀绝技但是秘而不传,或者只传近亲的绝技,都在历史的长河中慢慢消失了。

        再看看IT界的,苏杰,写了本《人人都是产品经理》,程杰,写了本《大话设计模式》......,除了写之外,他们还经常出没于各大论坛,讲座,想躲也躲不开啊......。

        看来牛人之所以牛,自己懂的多是一个因素之外,更重要的是把自己的知识总结下来,并努力推广了。

        所以日常总结,随身笔记一定是要做的,总结就是理解它,并且理解了还不要忘记它,时不时还翻回来看看,否则很多知识学习了又忘记了。总结这个法宝,一定要随身携带。 

     

    法宝三:牛人懂得专注

        有句古语是这么说的:能够到达金字塔顶端的动物只有两种,一种是苍鹰,一种是蜗牛。苍鹰之所以能够到达是因为它们拥有傲人的翅膀;而慢吞吞的蜗牛能够爬上去就是认准了自己的方向,并且一直沿着这个方向努力。对人类而言,能够于众生中脱颖而出者实属少数,这些人也可以看到:一种是资质优越、天生异禀,本就是成就大事的种子,这样的人是少之又少,而且有些这样的人还因不知学习而沦落了;另外一种人就是蜗牛一样的人物了,早早就知道自己是常人,却仍然立下鸿鹄之志,凭借后天的坚忍和努力,同样做出常人难以想象的成就。它是一种素质,更是一种能力。

        IT领域需要懂的太多了,运维、DBA,各种操作系统,各种语言......如果什么都想学好,结果必然是什么都略懂,但什么都拿不出手,所以注定无所建树,成不了牛人,而牛人是深刻明白这个道理,所以他们会选择某一点最感兴趣的地方,然后持之以恒的深专下去,最后达到了别人从未达到的高度,我们做IT编程的大部分人都是这也学那也学,简历上写的什么都是精通,其实这样的人,却不敢深问,深问了什么都不懂,因此专注某一个技术领域,是走向成功的铁定法则。

     

    法宝四:牛人注重动手能力

        “纸上得来终觉浅,绝知此事要躬行”。

        看来牛人并不是坐在屋子里成牛人的,而是在不断的动手,在实战中造就了牛人,也充分的说明了学习的终极目的--学以致用。所以我们学习时,一定要动手做,只学习不动手,是成不了牛人的啊。

         拿着这四件法宝去取经,就为成功增加了强有力的保障,并能达到事半功倍的效果。当然在路上多捡几件随身携带,那功力就会更强了,像007一样,口袋里总是需要什么有什么。法宝之重要,犹如练武的找到了降龙十八掌,乾坤大挪移之类的秘籍一样,拿到手了就会成为武林至尊!

     

     

    3、架构师都要懂哪些知识


    Web架构师究竟都要学些什么?具备哪些能力呢?先网上查查架构师的大概的定义,参见架构师修炼之道这篇文章,写的还不错,再查查公司招聘Web架构师的要求。 总结起来大概有下面几点技能要求:

    一、 架构师有优秀的编码能力,解决开发人员无法解决的难题。

    二、 架构师对系统的大数据容量高性能高并发高容错的网站有架构设计和开发经验。

    三、 架构师对操作系统、数据库、服务器各种软件使用的配置比较了解,比如Linux、Web负载均衡、反向代理、数据库集群、容灾等比较了解。

    四、 架构师对软件开发过程有清晰明确的认识,也就是对软件工程有有明确的认识,并能把需求进行分析、建模。

    五、 架构师学习能力很强、接触知识面要很宽广、喜欢关注和接触各种新的技术。

    六、 架构师沟通能力很强。

    七、 架构师对从事的行业的业务要有深刻的了解。

     

    换个角度看看这些要求把:

    第一条要求你是个优秀的程序员。

    第二、第三条要求你要懂DBA,运维都需要懂的知识。

    第四条要求你是个项目经理。

    第五条要求你是个技术全才,不仅学的要深,还要学的广。

    第六条、第七条要求你熟悉公司业务人员、产品人员要懂的知识。

    这个要求太高了,架构师就相当于战争中的司令员的位置,是整个团队的核心和灵魂,这种技术要求甚至技术总监和CEO都不具备,唯一要求少点的就是管理能力,如果再具备管理能力,那就甚至能超过技术总监和CTO了,而中国不乏管理人才,怪不得有人总结说,中国没有合格的架构师呢,也难怪,大概算一算,这种要求相当于一个人学6个人的知识,并且都能达到专业的水平,这就意味着你的领悟能力和学习能力,要高于常人几倍!所以说,成为架构师确实需要天分啊。

     

    成为优秀程序员,需要学好的知识:

    1、 面向对象编程、UML画图、设计模式、代码重构

    2、 常用ORM工具

    3、  MVC,WCF,XMl, JQuery ,SQL以及性能优化

    4、 FrameWork一些深入的知识

    5、 高性能代码,比如静态化,MemCached等手段。

    6、 最好也了解一些其他语言,比如Java,PHP等。

     

    成为DBA,需要学好的知识:

    1、 常用数据库,MSSQL、MySQL、Oracle,性能调优熟练,备份、负载均衡、集群、容灾熟练

    2、 大数据量处理熟练

    3、 各种数据库监控软件

     

    成为运维,需要学好的知识:

    1、 各种Web负载均衡的硬件,比如F5,软件,比如Nginx等原理和配置

    2、 反向代理加速,比如SquID等

    3、 操作系统,Linux是必须懂的,各种好的工具都在Linux下。

    4、 各种性能监控软件。

     

    成为产品和业务以及项目经理,需要学好的知识:

    1、 沟通和理解能力。

    2、 该行业和本公司的业务逻辑。

    3、 软件工程的知识。

    4、 质量控制、进度控制、人员组织等。

     

    看来想成为合格的Web架构师,需要学太多东西了,只有一条路可走--持续不断的修炼和学习。

    另外学习中,采用先深后广的策略是明智的选择,一门学深了,其他知识可能都会融会贯通,那样比较的学起来会很快。否则可能陷入知识的海洋里,没准淹死了。

    总体的看来,Web架构,分为服务器架构和程序架构两个方面的架构,一般的Web架构师还是偏向程序架构,因此学好语言,程序架构是基础,学好了这些,做一个合格的架构师没大问题,毕竟DBA,运维的东西在公司都有专业的人在干。

    所以深度还是要深入学习编程的知识、软件架构知识,有了这个基础后,Web架构师应该在大数据量、高并发、高负载、以及高容错方向再有所了解和涉及,再返过来促进我们对软件架构的思考,这种深-广-深-广的模式是我们学习的方法,只要坚持不懈努力几年,做真正合格的Web架构师是没大问题的。

    另外由于学东西太多,在学习中也要和其他架构师多交流、共同进步,多参考其他架构师的杰作,是很明智的选择。

     

    原文地址:http://www.cnblogs.com/seesea125/archive/2012/03/30/2425281.html

    对原文一些内容做一些修改,感谢作者,尊重原著。

     

     

     

     

     

    展开全文
  • 系统架构师论文

    2014-05-08 15:45:19
    系统架构师 软件等级考试 计算机等级考试 历届考试论文题目范文
  • 从这些等级中,我们可以知道成为一名合格的java架构师,不是懂了一大堆技术就可以了的。那么成为java架构师的标准都有哪些呢? 标准一:熟悉java技术 熟悉各种框架并了解其实施原则。jvm虚拟机的原理和调优,了解jvm...

    在java软件开发领域,有着等级分明的界定。从最基础的java程序员,再到初级java软件工程师,再然后就是中级、高级java软件工程师,最后是java系统架构师、技术总监和CTO。从这些等级中,我们可以知道成为一名合格的java架构师,不是懂了一大堆技术就可以了的。那么成为java架构师的标准都有哪些呢?

    java架构师培训

    标准一:熟悉java技术

    熟悉各种框架并了解其实施原则。jvm虚拟机的原理和调优,了解jvm可以使您编写性能更好的代码;池技术,什么对象池,连接池,线程池,java反射技术,编写框架所需的技术;熟练使用各种数据结构和算法,数组,哈希,链表,排序树;熟练使用Linux操作系统;熟悉tcp协议和http协议。

    标准二:熟悉业务

    Java架构师还必须针对业务特征和系统性能要求提出最低成本的设计解决方案,然后再进行资格鉴定。Java架构师的作用是首先满足业务需求,其次是最低的硬件网络成本和技术维护成本。此外,Java架构师还需要根据业务发展阶段预先预见系统架构下一阶段的解决方案,并在设计当前架构时考虑架构的升级和扩展,以便于轻松实现。升级。

    最后就是java架构师培训内容只是整个环节中的部分内容,只是让你简单了解一下整个业务的流程,要想成为一名合格的java架构师,你还需要更加的努力,在技术上做到熟悉并精通,在业务上做到精通并创新,只要这样你才能更进一步,拿到令你满意的薪资。

    推荐阅读:java架构师培训:java最佳测试框架JBehave的基本介绍
    如果你想了解更多关于java架构师的专业知识,可以加入JAVA架构师交流群:1160405674,里面都是同行,有资源分享包括但不限于(分布式架构、高可扩展、高性能、高并 发、Jvm性能调优、Spring,MyBatis,Nginx源码分析,Redis,ActiveMQ、Mycat、Netty、Kafka、Mysql 、Zookeeper、Tomcat、Docker、Dubbo、Nginx)。欢迎一到五年的工程师加入,合理利用自己每一分每一秒的时间来学习提升自己,不要再用"没有时间“来掩饰自己思想上的懒惰!趁年轻,使劲拼,给未来的自己一个交代!

    展开全文
  • 全国计算机等级考试 MVVM
    展开全文
  • 架构师 资料

    2018-04-19 15:31:00
    开发者的4个等级 程序员跨越式成长指南 优秀 顶级前端 抄代码熟悉任何公司系统 高手 直面问题成为资深前端 发展 eader 移动端架构 项目管理 amp性能 招最好的人 鼓励创新减少加班 多...
  • 架构师文集100本.rar

    2019-06-03 10:42:23
    架构师100本精选,因为等级限制,不足100本,有其他需要的同学可以私聊我
  • 系统架构等级

    2019-09-24 11:29:09
    入门级:《系统架构设计教程(第2版)》《软件体系结构原理、方法与实践》 实践级:企业应用架构模式 《Software Architecture in Practice,2nd Edition--软件构架实践(第2版)》《Documenting Software ...
  • 在软件行业的职业划分中存在三个不同的等级,软件工程师、软件设计师、软件架构师。软件架构师处在最高层次。以前只是听说过软件架构师很牛,对于软件架构师是做什么的,软件架构究竟有什么用并没有概念。时至今日,...
  • 软考_系统架构师

    2016-09-20 14:35:00
    系统架构师和系统分析师,一般一个在上半年考试,一个在下半年考试 系统架构师的主要职责 1.需求分析 包括技术难点和技术细节 可以输出Feature list,复杂逻辑的时序图,模块间的交互图等 2.系统分解 将系统...
  • CSA课程:A段架构师的职责

    千人学习 2015-09-22 14:37:18
    传授CSA等级的架构设计思想、方法与技术。让想深度领会架构设计幕后的思想者,和盼望早日成为CSA者,都能孰悉A段架构师的角色。
  • 计算机软件等级考试高级;系统架构设计;大纲;复习参考。
  • 说明讲师:首席架构师 李智慧 1. 如何成为专家? 1.1 技术等级体系 金字塔每一层都是根据2、8定律分开。假如全球有2000万开发者,在最下面的无名者是1600万。 团队影响者为400万人; 公司影响者为80万人; 全国...
  • 人人都是架构师:非功能性需求

    千次阅读 2015-05-23 16:53:55
    架构首先来自需求,需求驱动架构,然后非功能性需求反映服务等级,面对客观环境的约束,自行引入的架构实现原则,是在高层次以上对需求、约束、和原则的理解和把握。 非功能性需求也可以称为质量属性,我所了解的非...
  • 本周三TechHR全国群有位小伙伴提出一个非常有趣的问题,引发了一系列的新话题。   首席架构师在互联网企业...首席架构师、CTO、技术总监的等级之分     不是平级,属于不同体系的。   架构师偏技术...
  • 高级工程师->架构师

    2017-09-26 14:54:00
    1. 分解等级 技术人员典型的发展路径基本上都是下面的这个模式: 1) 0 ~1年:菜鸟,需要别人手把手来教 2)1 ~ 3年:初级,需要别人带你做 3)3 ~ 5年:高级,能独当一面,可以带初级技术人员了 4)5 ~ 8年:...
  • 3、关于“项目对团队成员能力的需求”以下说法正确的是:在某个项目给定范围内,能够保证工作有效进行所需要的知识、技能和绩效等级 4、使用测试的目的是确保解决方案在它所需要的环境下正常工作,其重点是从用户和...
  • 测试架构师:5 测试策略实战攻略

    千次阅读 2018-08-14 15:38:59
     2.2 确定项目中各个特性的质量等级  2.3 对项目整体进行风险分析  2.4 确定测试策略的结构  2.5 初步确定测试分层  2.6 回顾 3 制定总体测试策略  3.1 分解产品质量目标  1. 根据质量等级来分解产品...
  • 技术架构师的启航

    2007-03-12 11:54:00
    99年读大学时选计算机专业,一个很简单的借口,不需要在毕业前考计算机等级证书。随后发现计算机等级证书太虚了,骗人钱财,误人子弟,现在类似的有北大青鸟等货色。大二时对成绩突然失去兴趣,投入竞赛,希望运气好...
  • 传授CSA等级的架构设计思想、方法与技术。让想深度领会架构设计幕后的思想者,和盼望早日成为CSA者,都能孰悉A段架构师的角色。
  • 服务降级SLA服务质量等级兜底数据限流降级超时降级降级开关数据组装降级读写降级前端降级与JS降级接入层和应用层降级片段降级静态化处理提前预埋 SLA服务质量等级 兜底数据 限流降级 超时降级 降级开关 数据组装降级...
  • 优秀和卓越差的不是一个等级,当你感觉自己优秀后,还能保持空瓶的心态开始,才能逐步的像卓越迈进,并漫漫长! 是不小时候更容易学会更多的知识,但越大越笨了!人可能很容易被自己的年纪大了,当成长者。却很少能...
  • 初级工程师(架构师、项目经理)ABC,各1名,共3名。以下是公司的技术等级说明书。有兴趣的可以看看。我的邮箱:zhonghua.li@qq.com,请注明岗位,邮件标题格式:[技术等级]-[姓名]-[博客园]开发人员技术等级说明书 ...
  • 本篇就软件等级考试相关的数据库系统知识从整体上进行总结,方便大家复习。 1. 数据库管理系统的类型 数据库系统有不同的分类方法(见下图),现代的数据库系统大多具有多用户、分布式的特点,因此最重要的区别就...
  • 文章目录商品评价统计实现... * 根据商品id查询商品的评价等级数量 * @param itemId */ public CommentLevelCountsVO queryCommentCounts(String itemId); serviceImpl @Transactional(propagation =
  • 介绍一下,这是中科大2020年春季信息学院《计算机安全》课程的课程知识点总结。授课教师:程绍银。部分图片来源于ppt。 掌握要求:掌握>知道>...等级保护、风险评估和安全评测的相互关系 风险...
  • 受到疫情影响我从过完年一直呆在家里,索性学点知识方便以后跳槽涨薪,于是从二月份开始学习阿里P8架构师纯手打的一份Java面经手册,没想到5月初我成功从我们三线的一个小公司跳槽进了腾讯,虽然等级不高,但是涨薪...
  • 0x01、设计模式概述 0x02、设计模式六大原则 单一职责原则 里氏代换原则 依赖倒置原则 ...难以支持新的产品等级结构,支持新的产品等级结构就要扩展抽象工厂接口 适用场景: 系统独立于产品的创建

空空如也

空空如也

1 2 3 4 5 ... 9
收藏数 166
精华内容 66
关键字:

架构师等级