架构师

项目经理和架构师的岗位职责

假装没事ソ 提交于 2020-03-16 01:46:30
项目经理和架构师这两个职位虽然在工作内容和职责上不同,但是在国内的企业中这两个职位的职责经常会放在一个人身上,在中小型公司中更是如此,一个人既是项目经理又是系统结构的设计者。在比较正式的企业中,也会存在同一个在这两个职位间相互转化的情况,例如从架构师转为项目经理。自己对这两块比较感兴趣,希望能够在这两个职位间自如切换。因而在“猎聘网”找了对这两个职位的说明,摘录如下,作为自己学习和提高的目标。 项目经理 1. 负责项目进度管理、质量控制、人员管理、风险管理,领导项目团队准时、优质实现项目目标; 2. 负责协调用户业务需求,制定具体的项目功能细节,负责软件系统需求的调研和分析,即时反馈阶段性成果;与客户保持联系,并按照客户的合理需求改进; 3. 按照项目要求对业务进行整理和流程设计,按照软件功能要求进行详细设计; 4. 制定项目开发计划文档,量化并分配任务;跟踪项目进度,协调组员合作; 5. 监督项目进展各阶段的文档,如《项目章程》、《项目立项报告》、《需求确认》、《实施计划》、《验收报告》等项目文档的编写,确保文档完整规范; 6. 判断客户需求变更的合理性,同时与组员及客户沟通协调;确认变更时,产生需求变更文档,更改开发计划; 7. 向上级汇报项目的进展情况、需求变更等项目信息; 8. 总结已完成项目,产生项目总结文档; 9. 传递知识,提升团队能力。 架构师 1. 熟悉分布式

如何建立架构师所需的立体化思维?【1】

醉酒当歌 提交于 2020-03-13 05:11:27
从程序员往架构师转型的路上,蔡学镛老师总结的“四维架构设计方法论”对我颇有帮助,让我对架构设计有了更立体化、系统化的认知,现将学习心得分享出来供需要的小伙伴参考。 这套方法论通过空间( X 、 Y 、 Z )三个维度及时间 T 维度将问题域解构成可以轻松应对的小方块,分而治之。同时,空间( X 、 Y 、 Z )三个维度联动,专门为单个维度解决不了的问题提供解决方案。时间 T 维度将问题分解到一个时间范围内,分步骤按节奏逐一解决。多维度、立体化、分层次、动态演进,这是我对这套方法论特点的总结。 接下来,让我们进入这个四维的架构时空一探究竟! 图 1 四维座标系统 前后端维度( X1 … X7 ) 前后端维度被分解为交互、业务、领域、资源四大层,其中业务可以细分为应用 X2 、框架 X3 ,领域可以细分为服务 X4 、核心 X5 ,资源也可以细分为代理 X6 、数据 X7 ,共分为七个层次。服务 X4 可以实现 API ,如果公开,就是开放接口,调用服务层的接口,通常需要授权。代理 X6 可以实现 SPI ,隔离耦合,避免核心 X5 依赖特定的外部系统或数据库。每个层次做到高内聚,层与层之间做到低耦合。 图 2 X 轴分层结构 在系统实现过程中,可以综合考虑现状, X2 应用和 X3 框架可以不分拆, X4 服务和 X5 核心可以不分拆,待后续时机成熟可以再重构分层

大数据领域就业和发展指南

假装没事ソ 提交于 2020-03-12 00:23:56
随着秋季校招落下帷幕,网上的各类招聘数据也已分布,大数据行业工程师以平均月薪11,600元领跑全国,成为“超高薪、高大上”的代名词。如果你学的是大数据相关专业,那么恭喜你,你的发展良机来了,如果你想要转行大数据也为时不晚。本文将利用从前程无忧招聘网站收集的7万多条大数据岗位招聘信息,分析当下大数据热门的就业和发展方向和技能需求,帮助相关专业在校生和想转行大数据的职场小白们找到适合自己的职业目标和发展方向,成为大数据时代的就业“新宠”,实现高薪梦想,走向人生巅峰! 数据说明: 一、前景光明的大数据行业 数据源:百度指数 《纽约时报》在2012年的一篇专栏中就曾称,“大数据”时代已经降临,在商业、经济及其他领域中,决策将日益基于数据和分析而作出,而并非基于经验和直觉。随着近年来互联网和信息行业的发展,数据量正在加速增长膨胀,人们越来越多的意识到数据对企业的重要性。从上图所示的“大数据”百度搜索频次可以看出,从2012年开始其搜索热度在全国范围内迅速增长,经历了2017年一个爆发年之后,至今仍不断受到广泛关注。 数据来源:中商产业研究院 随着国家大数据战略的实施和人工智能、云服务、物联网等产业的高速发展,我国大数据产业规模正呈现逐年增长趋势,预计到2021年将达到8000亿元。同时,从数据类型份额的角度看,物联网等极具活力大数据类型将出现大幅增长,为大数据企业带来了新的发展良机。

架构师目标

限于喜欢 提交于 2020-03-10 17:32:51
1、卓越的程序员   有些架构师的设计与实现会出现断层的问题,如果架构师不去实践,只是想当然的认为“没问题,这个想法能实现”,那么对于项目的落实而言是个很大的隐患。 2、抽象思维   很多优秀的架构师们都一致的表示,逻辑思维和抽象思维能力是一个架构师最重要的素质。 3、技术前瞻性   架构师不光要着眼于现在,不仅仅局限于开发细节。而是跳出三界外,考虑面向未来问题和潜在风险的应对之道。 4、问题解决大师   架构师因为具有多领域知识和经验的积淀,所以在面对庞大系统之时,仍然能够敏锐的发现其底层之真实。 5、多领域知识   架构师身为一名技术领袖,需要通过发散知识的光芒来统御开发团队。 6、沟通能力 7、内力   很多人理解的内力就是开发技术,包括语言的掌握、对框架的掌握、数据库管理能力、安全管理能力等等。但是我们看到,架构更多的内力体现在对技术的综合运用上,光会编程的程序员,最多就能做到高级程序员,也就是技术实现上的高手。 8、权衡取舍 9、管控能力   架构师在管理和控制的能力上,需要有自己独到的见解,而不是简单的认为这是项目经理或者财务部门的事情。在这里架构师所需要的管理与控制,其实是从技术的角度,对一些问题的控制,特别是开发过程中的监控,而不是普通意义上的纯粹管理。 10、艺术气质   一个优美的系统则是可以像有机的生命一样成长的,这是因为从系统开始架构的那一刻起

软件架构怎样进行架构

风格不统一 提交于 2020-03-05 04:30:41
软件架构师一般都是具备计算机科学或软件工程的知识,由程序员做起,然后再慢慢发展为架构师的。在国内,很多大学目前还没有设立软件架构的学位课程,虽然IT业界对设计和架构的兴趣日渐高涨,但各学校还是无法在课程中增加相应的内容来体现这一趋势。从这个方面来说,学校教育已经远远落后于产业发展。因此,促进和发展软件架构学课程的任务将落在现在的软件架构师身上。目前的软件架构师应该帮助各大院校建立相关课程体系,一旦教育课程建立起来,知识体将不仅通过新毕业生的工作成果来得到扩展,同时也会从适合软件架构的教育研究和出版物中得到扩展。 虽然大学要加强软件架构学课程的建设,但是,软件架构师的成长应该有一个实践的教育过程,并不是简单的学校的理论学习或者通过大型软件公司的认证就能成为合格的软件架构师。除了信息系统综合知识在学校学习外,软件架构师的大部分知识和经验将来自实际开发工作。根据软件架构师的任职条件,一名合格的软件架构师的成长应该经历8年以上的软件项目开发实际工作经验。一般需要经历软件设计员等阶段,然后再发展成为软件架构师。 当然,并不是每一位程序员经过8年后都可以成长为软件架构师的。一个软件工程师在充分掌握了软件架构师工作所必需的基本理论和技能后,如何得到和利用机会、如何利用所掌握的技能进行应用系统的合理架构、如何不断的抽象和总结自己的架构模式、如何深入行业成为能够胜任分析、架构为一体的精英人才

架构师成长系列 | 从 2019 到 2020,Apache Dubbo 年度回顾与总结

本秂侑毒 提交于 2020-03-03 17:05:40
作者 | 刘军(陆龟)Apache Dubbo PMC 本文整理自架构师成长系列 2 月 18 日直播课程。 关注“阿里巴巴云原生”公众号,回复 “218” ,即可获取对应直播回放链接及 PPT 下载链接。 导读 :Apache Dubbo 是一款开源的 RPC 框架,其提供了简单易用、高性能的 RPC 能力、灵活可控的扩展、强大的服务治理,目前已有 Java、Go、JS、Python 等多个语言支持;并且已经悄然衍进为 Cloud Native 基础设施。这一切成就都离不开 Dubbo 社区的建设,本文将由 Apache Dubbo PMC 刘军来介绍 Dubbo 社区在过去的一年取得的成绩及未来 Dubbo 社区的发展新规划。 非常感谢大家对 Dubbo 社区的关注,通过这篇文章我们将: 总结过去一年 Dubbo 社区取得的成绩,包括社区和框架演进两个方面; 展望未来 Dubbo 社区和框架的新的规划(roadmap)。 社区建设是推动 Dubbo 健康持续发展的一个非常重要的环节,我们需要与社区保持良性的互动、有活跃的贡献者、有积极的富有建设性的讨论,而整个 Dubbo 社区过去一年在这方面都做的不错;在框架演进上,我们主要发布了 2.7.0 - 2.7.5 共 6 个特性版本,功能层面涵盖编程模型、协议、服务治理、性能优化等多个方面;除了已经发布的功能外,我们在 Dubbo

架构师成长系列 | 从 2019 到 2020,Apache Dubbo 年度回顾与总结

我们两清 提交于 2020-03-03 15:27:49
导读 :Apache Dubbo 是一款开源的 RPC 框架,其提供了简单易用、高性能的 RPC 能力、灵活可控的扩展、强大的服务治理,目前已有 Java、Go、JS、Python 等多个语言支持;并且已经悄然衍进为 Cloud Native 基础设施。这一切成就都离不开 Dubbo 社区的建设,本文将由 Apache Dubbo PMC 刘军来介绍 Dubbo 社区在过去的一年取得的成绩及未来 Dubbo 社区的发展新规划。 非常感谢大家对 Dubbo 社区的关注,通过这篇文章我们将: 总结过去一年 Dubbo 社区取得的成绩,包括社区和框架演进两个方面; 展望未来 Dubbo 社区和框架的新的规划(roadmap)。 社区建设是推动 Dubbo 健康持续发展的一个非常重要的环节,我们需要与社区保持良性的互动、有活跃的贡献者、有积极的富有建设性的讨论,而整个 Dubbo 社区过去一年在这方面都做的不错;在框架演进上,我们主要发布了 2.7.0 - 2.7.5 共 6 个特性版本,功能层面涵盖编程模型、协议、服务治理、性能优化等多个方面;除了已经发布的功能外,我们在 Dubbo 3.0 协议、服务自省和云原生等方向上也做了深入的探索,对这些方向的支持将是 Dubbo 接下来的重要工作方向,希望能通过这篇文章将其中更详细的思考和计划同步给大家。 社区回顾 回顾 Dubbo

架构漫谈(七):不要空设架构师这个职位,给他实权

六月ゝ 毕业季﹏ 提交于 2020-03-02 14:28:28
上篇: 架构漫谈(六):软件架构到底是要解决什么问题?    什么是架构师   在之前的几篇文章中,经常会提到架构师这个词。我们已经定义了什么叫架构,那怎么定义架构师呢,是不是做架构的就叫架构师了? 没有这么简单,本篇尝试讨论一下这个问题。    架构师的前提条件   如果一个人在工作中,只是致力于完成自己的工作,以做好自己的工作为主要目标,那么最多只能成为一个工匠,无法成为一个架构师。因为这个过程解决的还是自己的问题,并没有时间的压力,可以随意什么时候做完都可以。   当我们所做的工作是处于社会的分工的一环,需要帮助别人解决问题,并且按时解决别人的问题成为我们自己的问题的时候,我们就有了时间压力,潜意识里会自然而然的有一种对时间的恐惧。这个恐惧在潜意识里面会想方设法推动我们采用各种手段,以便及时的完成工作,换取报酬。甚至会加班加点,不择手段。   如果我们还生活在这个恐惧下面,是不可能成为架构师的。要成为架构师,必须要超越这个恐惧才能够看清楚,我们要解决的是别人的问题,不是自己完成工作的问题。因为仅仅是完成了自己的工作,也并不一定就解决了别人的问题。如果别人的问题没有解决——即使我们认为自己的工作完成了——我们的工作实际也没完成,因为我们工作是否完成,是别人说了算的,不是我们自己。   为什么会有这个对时间的恐惧和压力呢?这是因为我们把完成自己的工作当成了我们的最大利益

架构漫谈(三):如何做好架构之识别问题

谁说我不能喝 提交于 2020-03-02 08:21:04
架构漫谈(三):如何做好架构之识别问题 作者: 王概凯 来源: InfoQ 发布时间: 2016-04-17 10:47 阅读: 14714 次 推荐: 10 原文链接 [收藏]    上篇: 架构漫谈(二):认识概念是理解架构的基础   按照之前架构的定义,做好架构首先需要做的就是识别出需要解决的问题。一般来说,如果把真正的问题找到,那么问题就已经解决80%了。这个能力基本上就决定了架构师的水平。    那么面对问题有哪些困难呢?   我们先看一则笑话。女主人公:老公,把袋子里的土豆切一半下锅。结果老公是把袋子里的每个土豆都削了一半,然后下锅。   当然很多人会说,这个是沟通问题,然后一笑了之。其实,出现这个现象是由于我们大部分时候过于关注解决问题,急于完成自己的工作,而不关心“真正的问题是什么”而造成的。当我们去解决一个问题的时候,一定要先把问题搞清楚。这也是我为什么要单独写一篇文章讲这个的原因。去看看软件开发工作者的时间分配也可以看出,大家大部分时间花在讨论解决方案和实现的细节上,基本都不会花时间去想“问题是什么”。或者即使想了一点点,也是一闪而过,凭自己的直觉下判断。只有真正投入思考问题是什么的工程师,才可能会真正的成长为架构师   以这个笑话为例,看看在我们处理问题的时候,都会犯什么样的错误: 被告知要处理一个问题,但是交过来的实际上是一个解决方案,不是问题本身。

如何做好架构之识别问题

血红的双手。 提交于 2020-03-02 07:43:51
按照之前架构的定义,做好架构首先需要做的就是识别出需要解决的问题。一般来说,如果把真正的问题找到,那么问题就已经解决了80%了。这个能力基本上就决定了架构师的水平。 那么面对问题有哪些困难呢? 我们先看一则笑话。女主人公:老公,把袋子里的土豆切一半下锅。结果老公是把袋子里的每个土豆都削了一半,然后下锅。 当然很多人会说,这个是沟通问题,然后一笑了之。其实,出现这个现象是由于我们大部分时候过于关注解决问题,急于完成自己的工作,而不关心“真正的问题是什么”而造成的。当我们去解决一个问题的时候,一定要先把问题搞清楚。这也是我为什么要单独写一篇文章讲这个的原因。去看看软件开发工作者的时间分配也可以看出,大家大部分时间花在讨论解决方案和实现的细节上,基本都不会花时间去想“问题是什么”。或者即使想了一点点,也是一闪而过,凭自己的直觉下判断。只有真正投入思考问题是什么的工程师,才可能会真正的成长为架构师 以这个笑话为例,看看在我们处理问题的时候,都会犯什么样的错误: 被告知要处理一个问题,但是交过来的实际上是一个解决方案,不是问题本身 被告知要处理一个问题,直接通过直觉就有了一个解决方案,马上考虑解决方案如何落地,或者有几种解决方案,选哪个合适 那么如何识别问题呢? 所有的概念基本都有一个很大的问题,就是缺乏主语。而我们大家都心照不宣的忽略这个主语,沟通的时候也都以为大家都懂得对方说的主语是谁