认识达内从这里开始

认真做教育专心促就业

架构师详解PHP抓取程序逻辑代码，创造编程逻辑思维

发布：达内
来源：互联网
时间：2017-12-11 10:07

    在今天的技术圈,可能随便遇到一个人递给你一张名片,title 就是某某架构师.架构师多如过江之鲫,也正是眼下业内一个有趣的现象.对于架构师,你有什么看法?

    什么是架构师?达内给你答案:

    随便打开某招聘网站:系统架构师、搜索架构师、前端架构师、iOS/Android 架构师、平台架构师、(大)数据架构师、JAVA/PHP/.NET 架构师、高级架构师、资深架构师、BI 架构师,这些是大家常见的,君不见还有后台架构师、MIS/ERP/OA 系统架构师、金融系统架构师、搜索架构师、总线架构师、运维架构师,安全架构师...... 林林总总,不一而足.

    仅仅是上面这些岗位名称,就能看到架构师岗位的差异之大,方向不同、技术栈不同、行业不同,即便同一个岗位,水平差距也是天壤之别,如果仅以架构师一个称谓来描述,显然是不合适的,所以我觉得今天在行业内这个称谓还有点"虚".

    李维先生曾经有过一次演讲,讲到了一个架构师应该具备的特性:

    1. 核心软件技术.要攻克数据库设计问题,必须深入了解数据库的工作原理,而不是会写复杂的SQL会管理个备份会设计个表结构就算精通数据库.有人甚至把会用hibernatestructsspring当作自己会核心软件技术.

    2. 产品特性.你学了那么多核心技术,到底要干吗?我一直在商业软件公司工作,没有在研究所工作过.我各种技术要做到的就是帮助企业软件生产,如何更快更省力气质量更好市场竞争力更强.

    3. 软件趋势.在企业管理软件开发领域,往往会见到这样的现象:不少开发人员精通客户业务需求,深入第一线做客户实施.他们学习技术也是为了解决现有手头的问题.尤其企业管理软件开发领域,技术要求并不高,而如果不了解客户需求,开发的软件实用性就不强,即使你的功能开发的又性能好又安全性好也没实用意义.

    架构切分,本质上是利益的调整

    在识别出是谁的问题之后,大部分情况下问题都迎刃而解.但总还有一部分确实是有问题的,需要做调整.

    这个调整就是架构的切分.简单来说:

    架构的切分的导火索是人的负载太重.

    架构的切分实际就是对 stakeholder 的利益进行切分或合并,使得每个 stakeholder 的权责是对等的,每个 stakeholder 可以为自己的利益负责.

    架构切分的最终结果都会体现在组织架构上,只有这样才能够让架构落地并推进.

    架构切分的结果一定是一个树状,这也是为什么会产生分层.层数越多沟通越多,效率越低,分层要越少越好.尽可能变成一颗平衡树,才能让整个系统的效率最大化.

    如何才能把握好这两个问题?怎样才能快速的层层剖析,找到问题的主题?又如何才能合理有效的进行切分?这些问题,是制约是否成为出色架构师的关键.

    良好的沟通

    架构师需要知道,有效沟通是建立信任和影响团队以外成员的关键技能.他们知道不同群体使用不同的词汇,而使用技术术语和描述与业务人员沟通将会变得比较困难.与其谈论模式、工具和编程概念,架构师需要使用听众熟悉的词汇与之交流,诸如风险回报、成本和收益等.这比单纯使用技术词汇进行沟通来得更好.架构师还需要认识到团队内部沟通与外部沟通同样重要,可以使用图表和小组讨论的方式来建立和完善技术愿景,并书面记录之(如架构决策日志或Wiki等),从而为将来留下可追溯的历史.

    结语

    架构之路任重而道远.程序设计和架构设计是互通的,每个人都可以从设计好一个程序往设计好一个系统架构前进.

    想成为架构师不是懂了一大堆技术就可以了,这些是解决问题的基础、是工具,不懂这些怎么去提解决方案呢?这是成为架构师的必要条件.

    架构师还要针对业务特点、系统的性能要求提出能解决问题成本最低的设计方案才合格,人家一个几百人用户的系统,访问量不大,数据量小,你给人家上集群、上分布式存储、上高端服务器,为了架构而架构,这是最扯的,架构师的作用就是第一满足业务需求,第二最低的硬件网络成本和技术维护成本.本篇文章是由达内为您呈现,希望给您带来更多更好的文章,喜欢的朋友们可以加微信公众号.

更多达内相关咨询,请扫描下方二维码