自身架构分享，大公司架构师应该具有什么样

1. 自身架构分享，大公司架构师应该具有什么样

#1 专业技能
@首先当然基础知识要扎实，一些经典的专业书籍一定要看。比如，设计模式，算法，数据结构，所在领域的编程语言的专业书籍等.关于不同的能力阶段，需要读取什么类型的书籍，请参考ThoughtWorks(中国)程序员读书雷达,每年都有更新。
@作为架构师，review别人的代码并给出合理的建议是基本功，所以代码大全，重构，改善既有代码的设计，Clean code 等等肯定需要看。
@ 对于某一个技术领域或者业务领域，一定要有一门技术是精通的，因为这样你才能体会到以后遇到自己不懂的技术的时候，如何能够快速成为这一方面的行家。
@ 平常有时间一定要多多进行代码的训练，也就是Martin Flower常说的Kata练习，这个比喻来自于跆拳道，跆拳道选手一般每天都会找一些基本的招式，进行反复的练习，从而训练肌肉的条件发射，那么对于我们程序员来说，一定也要进行持续的编程训练，比如上面提到的那位同事，给的建议是，虽然把大部分时间花在了沟通和协调上面，没有机会写代码，但是自己一定要利用业余时间，自己找一些例子来联系，比如，参与开源项目，或者到网上去搜索一些大师的经典Kata联系的例子；或者看工作里面是否有一些小工具，是否能够提升自己的沟通效率，当然已经天天写代码的童鞋们除外。
@ 最好能够在精通一门语言的基础之上，学习其他的语言，从而站在一个更高的角度，对于程序语言有一个更高层次的抽象认识，比如，学了Java之后，可以学学Ruby，Groovy，C#等等，其实语言之间都是相互借鉴的，比如Lamba表达式，连java也慢慢的向函数式编程方向靠拢。
@ 如果有时间，一定要自己维护一个博客,既然选择了架构师，就决定了自己以后不仅仅是一个技术专家，同时也要成为一个布道师，为企业组织或者社会上的其他IT同行们贡献自己的一些微薄之力。
@ 多参加一些社会上举办的软件专业会议或者活动，了解当前比较流行的技术和框架。
@ 这条不提倡，我以前有一个同事，几乎每年都要更新简历1~2次，目的不是真正的换工作，而是通过面试得到当前市场上大部分公司正在使用什么技术和框架。对于这条，请慎用！！！！
@如果有结对编程的机会一定要好好珍惜，特别是和高手大拿一起结对的时候。
@如果大家上面都已经做的非常的好了，这个时候可以看看架构设计方面的书籍，比如企业应用架构模式，架构之美等等。
@ 去51Job上搜索架构师这个职位标签，看看不同行业的企业对于架构师的技术要求和标准，然后结合自己当前所处的行业和你自己的技术特点，比如擅长前段或者后端，有选择性的学习一些自己感兴趣的技术或者方法。

@大家如果时间和精炼允许，最好能在Github开源和分享自己平常写的代码。这样一方面可以熟悉git用法，另外一方面也可以把自己平常练手的代码免费保存，何乐而不为呢？

@如果大家平常遇到什么问题，可以到StackOverFlow上面去寻找da an；当然，如果你能自己注册一个StackOverFlow账号那是最好不过的，这样不但可以提问，还可以帮助别人，同时上面还有很多工作签证的工作机会。

#2 软技能（现代社会，一个合格科学家不仅仅是某一个行业的技术专家同时也是一名专业的社会活动家）
@遇到问题，一定要多想，遇到一个问题，如果解决了，就要反思为什么能够解决，如果以后遇到类似的问题，
如何更快速的解决。
@英语的重要性，不言而喻，因为现在很多新技术的框架的中文文档非常的少，即使翻译成中文，也是二手的了（国内自己的开发的一些开源框架除外）
@ 有时间的话，看一些沟通方面的书籍，如果有参与沟通的机会的时候，一定要想如何把沟通做的更好更舒畅。
@ 如果有机会的话，可以参加PMP的考试，但是如果不想参加的话，也没有关系，至少要涉猎到项目管理方面的书籍，否则以后如果成为架构师之后，客户或者管理者给你说一些项目管理上一些专业术语时，到时候就会一头雾水。
@架构师其实从某种意义上就是一种角色，而不是一种职位。一定要时时刻刻保持空杯心态。@一定要有一颗保持饥渴学习和耐得住寂寞的赤子之心。
@当前的技术节凑是非常快的，特别是结婚以后又有小孩了。一定要好好的利用自己碎片时间，对于一些技术，当时读不懂不要紧，但是一定要记住和了解其关键词，这个主要是为了拓宽自己的视野。比如，当前你想自己开发一个系统，结果已经有一个开源框架实现了，而且还很稳定，这个时候，自己就没有必要重复发明轮子了。
@与不同的技术、编程语言、设计模式和结构等（甚至是它并没有在日常中给予你直接的帮助）打交道。你永远都不知道这些知识是否会在未来派上用场，但是对你绝对是有益无害。
@在工作中，能够帮助到别人解决技术难题，一定要尽量全力以赴，因为这不但可以赢得同事的好感和口碑，同时也能增长你解决问题的经验和提高你的技术思维能力
@ 一定要掌控好自己的时间，对工作没有帮助的会议，能不参加尽量不要参加，当然，企业安全，公司规章制度如果是强制性的，该参加还得参加，但是如果没有工作效率和扯皮的会议，尽量避免参加。
@程序员要耐得住寂寞，要在自己的领域深挖，不能看啥火，就学啥，一定要有自己的想法和判定，如果决定不了，可以向资深的同事或者朋友沟通。
@尽量参与到项目中的编码，因为架构师不能与项目脱离。
@ 如果有机会可以锻炼一下自己在大众环境下的演讲和PTT的能力。
@有机会多做知识分享，因为你一旦分享了知识，你就会对这门技术有深刻的印象，同时也能树立在同事中的良好的技术形象，从而赢得更多的专家影响力而不是职位影响力。
在这里给大家提供一个java进阶学习交流的地方：694549689
具有1-5工作经验的，面对目前流行的技术不知从何下手，需要突破技术瓶颈的可以加群。
在公司待久了，过得很安逸，但跳槽时面试碰壁。需要在短时间内进修、跳槽拿高薪的可以加群。
如果没有工作经验，但基础非常扎实，对java工作机制，常用设计思想，常用java开发框架掌握熟练的可以加群。

上面只是我当前能想到的，知易行难，知道了上面的一些经验，并不代表年轻程序员们就能马上成功，毕竟这需要一个凤凰涅槃和实践的过程，但是肯定能帮助有志于于此的年轻程序员们少走一些弯路，以后如果有其他的想法，或者读者有其他的好的建议。

2. 最好的架构、需求和设计出于自组织团队

自组织团队 
  
  
 自组织团队是敏捷软件开发的基本观念 。敏捷宣言的原则中提到 :“最好的架构、需求和设计出于自组织团队 ”。自组织团队也叫做自管理团队、或者被授权的团队。团队被授权自己管理他们的工作过程和进度、并且团队决定如何完成工作。
  
 
  
                                          
 自组织团队和经理领导的团队的区别
  
 对于经理领导的团队来说，团队成员被分配任务，团队成员只有执行任务的权利。管理者除了要确定目标、方向，团队的组织结构、团队的组成，还需要监督和管理团队的过程和进度，分配任务即确定谁要做什么。这种团队的管理方式，更多的是命令与控制，以及微观管理。
  
 对于自组织的团队他们拥有这些权利：
  
 团队决定谁做什么，即任务的分配
  
 团队决定如何做，如何实现，即团队来做技术决策
  
 团队需要再确保目标的前提下制定团队内的行为准则
  
 团队有义务保持过程的透明性
  
 团队监督和管理他们的过程和进度
  
 在自组织团队的环境下，管理层关注如下方面：
  
 确定团队目标和愿景
  
 确定团队组织结构、团队结构、团队组成
  
 提供环境和支持（安全感、良好的团队空间、氛围，技能辅导等）
  
 授权团队
  
 训练协作
                                          
  对自组织团队的普遍误解 
  
 误解1：团队自己决定目标是什么；
  
 ——>纠正：管理层决定团队目标
  
 误解2：团队自己决定谁进入团队；
  
 ——>纠正：管理层决定团队
  
 误解3：团队自己设计团队结构；
  
 ——>就怎：管理层决定
  
 误解4：自组织团队不需要管理者；
  
 ——>纠正：管理者从微观管理专项目标驱动、授权团队的管理方式
  
 误解5：自组织团队需要员工更加主动；
  
 ——>纠正：自组织让团队更加主动，每个人都不喜欢被命令和控制，每个人期望有成就感、期望被认可
  
 误解6：自组织团队想干什么干什么；
  
 ——>纠正：管理层决定团队目标，团队决定如何实现目标

3. 一个优秀的系统构架师应该具备的能力

一个优秀的系统构架师应该具备的能力
                   
 作为软件开发的设计架构师，那么必须拥有一定的编程技能，同时有高超的学习新的架构设计、程序设计技能。另外，我觉得作为软件架构师，还必须了解一定的硬件、网络、服务器的基本知识。要不然，你都不知道有些什么材料可以用，你怎么去根据实际情况去规划你的软件架构呢?忽视程序设计能力的持续跟新，是永远不能够成为一个成功的系统架构师。
   　　一般来讲，系统架构师应该拥有以下几方面的能力：
   　　1：具备 8 年以上软件行业工作经验;
   　　2：具备 4 年以上 C/S 或 B/S 体系结构软件产品开发及架构和设计经验;
   　　3：具备 3 年以上的代码编写工作经验;
   　　4：具备丰富的大中型开发项目的总体规划、方案设计及技术队伍管理经验;
   　　5：对相关的`技术标准有深刻的认识，对软件工程标准规范有良好的把握;
   　　6：对 .Net/Java 技术及整个解决方案有深刻的理解及熟练的应用，并且精通WebService/J2EE 架构和设计模式，并在此基础上设计产品框架;
   　　7：具有面向对象分析、设计、开发能力(OOA、OOD、OOP)，精通 UML 和 ROSE，熟练使用 Rational Rose、PowerDesigner 等工具进行设计开发;
   　　8：精通大型数据库如 Oracle、Sql Server 等的开发;
   　　9：对计算机系统、网络和安全、应用系统架构等有全面的认识，熟悉项目管理理论，并有实践基础;
   　　10：在应用系统开发平台和项目管理上有深厚的基础，有大中型应用系统开发和实施的成功案例;
   　　11：良好的团队意识和协作精神，有较强的内外沟通能力。  ;

4. 架构师成长之路：到底什么是架构设计？该如何理解架构设计？

 架构设计是一个大家耳熟能详的词，基本都烂大街了。
   可是，到底什么是架构设计呢？估计很多人就回答不上来了。
   下面就来详细聊聊什么是架构设计，以及对架构设计的一些基本认识。
   软件架构设计指的是：对一个软件系统进行的架构定义、文档编写、维护和改进、并验证实现的一系列活动，架构设计的产物就是一个系统的架构。
   架构设计实际上是一个过程，围绕着软件系统，对它的架构，进行定义、文档编写、维护和改进、并验证实现等，把这一系列活动组合起来，就是我们所说的架构设计。
   架构设计的产物，也就是结果，就是架构，这也是架构和架构设计的关系。
                                           架构设计是一门科学，这个已经是业界共识。但是作为一门科学来讲，它一定要有它自己的基础理论，基础方法，也会有一些实现的方法论。
   架构设计作为一门科学来说，还很不成熟。目前架构设计的基础理论还不是很完善，方法论上，更是百花齐放，大家都还处于一个探索的阶段。
   从科学上来讲，架构设计主要关注架构设计过程当中的：技术、流程、资源、方法；以及如何去完善并改进架构。
   刚讲到架构设计这门科学还很不成熟，再加上技术领域更新很快，新技术、新思想、新方法 层出不穷。
   我们总会面对很多新兴的、没有先例的系统，可能会应用新的框架、新的技术、新的解决方案来实现系统。
   因此，做架构设计的时候，是需要一定的创造力的。当然，艺术细胞缺乏的人员也不用太担心，架构设计上还是有很多是有章可循的，多半是在已有的架构体系上去做一些微调，微创新，并不是完全从零开始。
   架构设计不是一蹴而就的，通常也是由粗到精，刚开始，可能只有一个粗略的架构设计，然后不断迭代和演化，逐步推进，去完善和细化，这样的过程。
   这个可能有些人不太理解，认为说，软功过程里面，不是有专门的概要设计、详细设计的时间吗？架构设计不就是在这些设计阶段去完成的吗？做完设计了，把文档发下去，不就没事了吗？
   有些公司也是这么干的，实际上这是有问题的。
   架构设计会跨越软工的完整流程，对于一些大型的或者是重要的项目，可能立项期间，架构师就要参与，做一些粗略的架构规划，有两个基本的原因：
    1：能不能做得了这件事     2：按照粗略的架构规划做下去，大致的成本会有多大 
   立项的时候，就要去考虑你的成本，风险和投资收益。
   也就是说，立项的时候，架构师可能就需要参与，那就更不用说需求阶段、设计阶段了，架构师是肯定要参与的，前面讲需求分析的时候已经讲过了，这里就不多啰嗦。
   到了编码阶段，有些人可能认为架构师是不参与的，这是不对的。架构师需要参与，只是参与的少一些，主要是一些重点、难点的地方，或者是公共基础功能，由架构师来实现。
   另外在编码阶段，架构师还有一个重要的任务，就是确保开发人员按照架构设计去实现，不要乱做。这就需要两个基本的方式，一个是架构师要把架构设计的成果，跟开发人员讲解清楚，并不断沟通；另外一个就是要不断检查，Review，以确保架构设计的落地实现不出大的偏差。
   后面的测试、部署、运维等阶段，架构师要做一些技术咨询，或者是技术指导的工作。架构设计里面，本来就包含部署架构的设计，因此，架构师也会参与这些阶段，只是参与的少一些。
   总之，架构设计需要关注所有利益相关者的要求，参与系统设计实现的所有人员，也都是系统的利益相关者，自然而然的，架构设计就需要贯穿软工的整个流程了。
                                           一个系统，要关注的方方面面是很多的，利益相关者也很多，大家关注点各有不同。
   这就意味着，在做架构设计的时候，需要不断去做决策，在众多关注点中去寻求平衡，所以有人说，做架构设计，就是一种玩平衡的艺术。
   比如：从技术上讲，A+B的方式是性能最高的；但是从成本上来看，A+C是最合适的。可能最后综合权衡后，B+C是各方都能接受的方案。
   这种需要考虑的平衡很多，比如：技术和成本的平衡；方案适用性年限的平衡，是满足1-3年就够了，还是要考虑8-10年；技术方案和当前开发人员技能的平衡；性能和成本的平衡等等，非常多。
   架构设计是一个过程，需要在这个过程中，不断去考虑各利益相关者的要求，并不断折中平衡，因此架构设计的产物，也就是架构，自然就是各方利益相关者的共识了。
   要做出好的架构设计，经验是不可或缺的，不会每次都是从零开始。
   比如以前做过类似的系统；或者是学习到的一些好的架构模式，设计模式，一些现成的组件；或者是一些开源的框架等等的，这些我们都可以看成是可重用的资源。
   我们做架构设计的时候，需要不断去积累这样子的可重用资源，形成自己的工具箱。这样当我们在做一个系统的架构设计的时候，就有了很多备用的工具或手段。
   有了这些经验和资源的积累，会使得新系统的架构设计变得更容易。