架构师

Android 还可以走多久？ 最近，有人问我这么一个问题： 「萧哥，我做 Android 开发两年多时间了，但是最近总是很焦虑，看着人工智能越来越火，很担心 Android 要不行了，想问下，我现在要转行么？Android 还可以走多久？」 这个问题我觉得还蛮有代表性的，今天就姑且给大家谈谈这个话题。 毫无疑问，人工智能是下个十年要进入的时代，而且现在已经有蓄势待发的意思，但是人工智能跟 Android 开发完全不冲突，人工智能它是一门技术与科学，它可以应用于各行各业，方方面面，同样，它也可以应用于手机端，这两年也有不少手机厂商推出了 AI 芯片，以后人工智能在手机上的应用会有很大潜力。 那有人可能会担心， 未来 Android 会不会如当初的塞班一样很快就被取代呢？ 这个担心是多余的，正是由于有了诺基亚的前车之鉴，现在各大互联网公司危机意识都很强，想再出现一例诺基亚这样的事情是很难了，再说了，Android 和 iPhone 的背后要知道那可是 Google 和 Apple 啊，这两家富可敌国的科技公司，想要被颠覆那基本就是做梦，现在想要出现第三个操作系统那得经过 Google 和 Apple 的允许才行，所以，未来五到十年，甚至更长，手机将永远会是 Android 和 iPhone 的天下，而随着科技的发展，未来取代手机的绝对不是另外一种手机，而可能会是新的载体，如眼镜

8月号的《日经SYSTEMS》(日本)上面刊登了一篇文章，内容是日本的一线技术人员推荐访问的101个网页的地址。 被推荐的网页大多为日文，不过，一个叫榊原彰的架构师推荐的10个网页全部为英文。文中介绍说："榊原彰是日本IBM中成为最高级别的工程师的时候年纪最轻的一个。到他这个级别的IBM工程师全世界大约有610个左右。是日本架构师的杰出代表" 下面是这位架构师推荐的十个网站: TheServerSide.COM CBDI BP Trends Software Engineering Institute StickyMinds.com RedHerring The Wall Street Journal Cutter Consortium DSM Forum Eclipse.org 下面其他人推荐的几个英文网站: Handbook of Software Architecture TechCrunch freshmeat.net CPAN Blackhat.com Enterprise Integration Pattern 来源： https://www.cnblogs.com/Ronin/archive/2006/08/03/466543.html

本 系列 前序文章索引： 程序员 为什么必须要懂架构？ 架构到底是什么，你知道吗？ 架构都有哪些，我该怎么选？ 架构师都干什么，你知道吗？ 架构师， 我们程序员打怪升级的主要方向，它不像某些技能报个培训班就能获得。胜任架构工作需要具备许多技能，既有硬技能还有软技能。俗话说：一口吃不成胖子。从程序员到架构师也无法一蹴而就，它是一个循序渐进、稳步提升的进阶过程，每个阶段都有每个阶段要掌握的技能，多项技能之间还存在先后顺序。如果想尽快转型升级至架构师，那你必须在日常工作中有意识地储备这些技能，接下来老兵哥结合亲身经历来给小伙伴们分享一下： 1. 硬技能 不像产品、管理等条线更加倚重通用技能，从技术条线转产品或管理，入门相对容易一些。但从产品或管理很难转型至架构，架构师必须从开发测试岗做起，在工作中不断提升专业技能和积累实践经验，从一个模块开始，到一个子系统，再到整个系统，最后到多个系统，这是一个循序渐进提升硬技能的过程，也可以看成构建架构师硬技能“点线面”。 1.1 点 老兵哥我刚入行时的岗位就是开发工程师，跟其他几个毕业生一起被安排在自动化测试平台项目组，整个系统由部门资深同事设计的，我们分别负责开发其中某个子系统的几个模块。这个阶段我主要关注函数、类和模块这个粒度，为了做好工作我要钻研编程语言 C/C++，以及熟悉 Visual C++ MFC、Socket 等代码库的使用

最近三个月，我非常荣幸的做为TeamLeader带领几个小组成员做了一个国外项目，这里想为大家分享一些小经验,尽管我佣有六年多的项目经验，但我一直的方向是架构师。大家知道架构师一般情况是偏向技术方向，我也不例外，前三年，主要精力都花在技术架构上，挖空心思在通用平台上做出自己的东西，体现个人价值。但最近一年也想在项目管理上有所突破，有人可能认为方向走偏了，但我不这样认为，在中国的软件环境下，在很大程度上，公司更希望全才，或者说有些公司并不仅仅希望架构师只懂技术。而架构师如果一味的只走技术路线，在某些方面会存在缺陷： 1：与人沟通 这个很容易理解，技术人员一般情况下不会和太多的人沟通，大部分情况也就局限于自己所属的Team，但是做为一个PM，你有可能会和产品经理，客户经理等人合作，这是普通程序员不太方便接触的人群。而往往人与人之间的沟通非常重要，沟通的顺畅可以让大家做事都比较顺利，反之，累死但结果并不太好。 所以我认为，如果做为一个沟通能力非常强的架构师，那么会让他非常容易的被大家接受。 2：每个公司对架构师的理解不一样 有些公司比较注意架构师的技术水平，所以这类架构师会负责技术部的所有技术难题(比如一些B2C网站，他们也许注重的是架构师能够解决可扩展，性能，平台通用的问题)，但有一部分公司对技术要求并不太强烈，他们也许会要求架构师更多的懂业务，或者能够带领团队完成代表公司标志性的项目

最近三个月，我非常荣幸的做为TeamLeader带领几个小组成员做了一个国外项目，这里想为大家分享一些小经验,尽管我佣有六年多的项目经验，但我一直的方向是架构师。大家知道架构师一般情况是偏向技术方向，我也不例外，前三年，主要精力都花在技术架构上，挖空心思在通用平台上做出自己的东西，体现个人价值。但最近一年也想在项目管理上有所突破，有人可能认为方向走偏了，但我不这样认为，在中国的软件环境下，在很大程度上，公司更希望全才，或者说有些公司并不仅仅希望架构师只懂技术。而架构师如果一味的只走技术路线，在某些方面会存在缺陷： 1：与人沟通 这个很容易理解，技术人员一般情况下不会和太多的人沟通，大部分情况也就局限于自己所属的Team，但是做为一个PM，你有可能会和产品经理，客户经理等人合作，这是普通程序员不太方便接触的人群。而往往人与人之间的沟通非常重要，沟通的顺畅可以让大家做事都比较顺利，反之，累死但结果并不太好。 所以我认为，如果做为一个沟通能力非常强的架构师，那么会让他非常容易的被大家接受。 2：每个公司对架构师的理解不一样 有些公司比较注意架构师的技术水平，所以这类架构师会负责技术部的所有技术难题(比如一些B2C网站，他们也许注重的是架构师能够解决可扩展，性能，平台通用的问题)，但有一部分公司对技术要求并不太强烈，他们也许会要求架构师更多的懂业务，或者能够带领团队完成代表公司标志性的项目

　　架构师的作用是 核心部分可控 ，一个完全被架构师控制的项目貌似严谨滴水不漏，但是其实首先这样做 成本很高 ，架构师本来有时间可以做更加有价值的事情，另外封闭的项目本身也 是缺乏活力 的项目，制约了下面人的热情和创造力。 　　所以架构师，包括项目经理等管理层的角色，要控制住自己的管理欲望，管理该管的，必须管的，其他的该放手就放手。 　　做管理的，就是有权利，有权利就容易迷失自我，所以权利用好的艺术就是平衡，平衡的就是管理的内容，明确职责范围，记住，权利的使用时零和，因为权利使用是需要精力的，你在某些地方使用权利，通常意味着另外一些地方就没有精力设计。 来源： https://www.cnblogs.com/xiashiwendao/p/8724582.html

DBA职业发展之路：去“IOE”等挑战之下，DBA将何去何从？ 摘要：随着近些年来，开源、自动化、云化的兴起，DBA职业也正悄然发生一些变化。面对一系列新的挑战，DBA将如何进行职业发展？本文将给出一些建议。 开篇 随着近些年来，开源、自动化、云化的兴起，DBA职业也正悄然发生一些变化。经常有朋友咨询我，职业发展规划；特别是近期Oracle的大幅裁员之后，针对DBA这一职业未来该如何发展？本文是个人对此问题的一些看法，仅供各位参考！ 数据是核心 将DBA单词分解一下。其对应的 操作对象：数据 操作介质：库 操作角色：管理员 这里的核心是数据，也是DBA这一角色最大的价值所在。他们最了解数据、最懂得数据的价值；因此DBA后续可发展的一些方向，也基本是与数据有关。 此外，对于数据要有更加宏观的认识，无论是企业的自有数据，还是外部获得；无论是关系数据，还是其他模式数据；无论是保存在数据库中，还是其他诸如日志等介质中，数据对企业都非常有价值，要将数据作为一种"资产"来管理。只有上升到这样的高度，数据相关岗位的价值也就凸显出来。 阶段不同，侧重不同 企业对数据应用水平不同，因而造成工作重心及岗位需求也有所不同。下面简单描述下各个层次： 层次一，是以数据库维护为主，常见表现是"救火队员"型。很多初创企业，都经历过这一过程。数据库维护基本靠人，随着运维体量的增加，需要线性增加人员

《The Architecture Journal》 是由微软主办的有关软件架构方面的季刊杂志，该杂志关注的是如何通过好的架构帮助开发人员创建更好的代码实现。 在该杂志中，来自微软架构师社区的权威架构师们讨论如何更好地实现解决方案， 《The Architecture Journal》 提供了一个交流企业、基础结构和应用架构相关主题的平台。(英文原文：In the Microsoft Architecture Journal, authoritative software architects from all corners of Microsoft's architect community discuss the connection between opportunities once out of reach and the solutions that now make them possible. The Journal is a platform for thought leadership on a wide range of subjects related to enterprise, infrastructure, and application architecture. MSDN中文网站的 翻译

上周考了亚马逊的解决方案架构师-助理级别的认证考试并顺利通过。这也算是对自己AWS服务熟悉程度的一种检验。在准备考试的过程中，把自己学习到的AWS知识都梳理了一遍，也算是收获颇丰。这次特意分享了该认证考经。 什么是AWS认证？ AWS 认证是对其在 AWS 平台上设计、部署和管理应用程序所需的技能和技术知识的一种认可。获得证书有助于证明您使用 AWS 的丰富经验和可信度，同时还能提升您所在的组织熟练使用基于 AWS 云服务应用的整体水平。 目前亚马逊推出了Solutions Architect,Developer和SysOps Administrator三个方向的认证。每个方向又分为Associate Level(助理级)，Professional Level（专家级）和Master Level（大师级）。当然目前只有Solutions Architect开放了Professional Level,其他层级会逐步开放中。 我的AWS使用经验 本人于2013年注册了AWS账号，开始只是做些小实验玩，后来把自己的整个博客都迁移到了AWS上，使用了Route53，S3，CloudFront等服务。 在办公室做过Chef，CloudFormation，AWS云服务Overview等session。 2014年参加过亚马逊在成都举办的AWSome day活动

博客转处：http://blog.csdn.net/china_video_expert/article/details/38335613 软件系统分析师与架构师在职责与技能方面没有明显的界线，你中有我我中有你，同时也有各自自己的世界，很值得拿来比比。 系统分析师职责:告诉我们系统应该做什么。 l 管理到技术的桥梁 各领域业务到信息化技术的通知翻译者。 l 对软件项目进行整体规划。 l 业务分析，理清业务的各个环节，并形成分析报告，形成业务模型。 l 需求分析，抽象出软件所要实现的目标，功能，形成软件规格说明。 l 描述软件的核心思想，设计最顶层的架构。 l 指导和领导项目开发小组进行软件开发和软件实现， l 对整个项目需求的实现进行全面管控。 l 项目成本、工作量、经济分析 系统架构师职责：告诉我们系统应该怎么做。 l 领导与协调整个项目中的技术活动（分析、设计和实施等）； l 推动主要的技术决策，并最终表达为软件构架； l 确定和文档化系统的相对构架而言意义重大的方面，包括系统的需求、设计、实施和部署等“视图”。 l 确定设计元素的分组以及这些主要分组之间的接口； l 为技术决策提供规则，平衡各类涉众的不同关注点，化解技术风险，并保证相关决定被有效的传达和贯彻； l 理解、评价并接收系统需求； l 评价和确认软件架构的实现； l