【摘要】 2017年12月27日20:00，在千聊直播平台华为云开发者联盟话题中，有众多IT行业的朋友，华为云软件开发云高级产品经理作为讲师，进行了一次直播，以《架构师的基本功——管理篇》为主题，分享了管理能力作为架构师的基本功的原因、该管理些什么以及怎样去管理。
华为云大咖说-庄表伟：架构师的基本功——管理篇
主讲人：庄表伟，开源社理事，知名GitHub程序员，
著有《开源思索集》 多年来一直在编程的第一线，
并以Coding为最大的乐趣。 曾任华为内源社区
平台架构师，现任华为云软件开发云高级产品经理。
架构师是做什么的？
架构师关心的是全局，或者说他关注的并不是实现当前的那个任务，更重要的是整个系统，作为整个架构，它是不是合理的，所以有可能架构师可能不了解某些具体的细节，让他一定会掌握全局。
技术选型
架构师是做什么的？，按照一般的常见的情况来说，首先他要做技术的选型，在什么地方选择什么技术，比如说，用PHP语言、JAVA语言还是Ruby语言来编程。数据库选NoSQL数据库、市面上听说过很先进的数据库还是别的什么，或者是什么样的消息队列。能不能选这些技术，选了之后有什么风险，这都是架构师需要考虑的问题。很多时候技术选型的合理，不是了解细节，而是了解大概，尤其是了解一些业界比较权威的评测，如果认识很多厉害的朋友，虽然自己不是很清楚那个东西到底好不好用，但是去找朋友问一问，有些很牛的朋友在一起很牛的公司，他们已经用过了，找他们问一问，他们就能告诉自己是不是靠谱，从这个角度来说，多认识一些靠谱的，很牛的架构师也是一项很重要的技能。
架构设计
在架构选型之后，肯定是要做架构设计的，这个架构设计成什么样子，有前端和后端，业务层、逻辑层、数据层等一些分层，还要考虑怎么样去部署，除了逻辑架构，还有部署架构之外，还要考虑运维怎么样方便，这些都是架构涉及需要考虑的问题。
实现非功能性需求
做软件除了需要满足各种各样的需求，还有一些非功能性的需求，举个例子，做一个直播的平台，那么要能够满足讲师能说话打字，能够上传图片，这些都是功能性的需求，而非功能性的需求有什么，比如说，能录一个三十秒的录音，还是能录一个一百八十秒的录音，然后录完了上传以后，有多少延迟才能听到，现在听直播的人如果是五十人、一百人、一千人或者是一万人，时间延迟会发生什么样的变化，人数到了多少，时间延迟将会不可接受，这些都是非功能性的需求。
解决技术难题
除了实现各种各样的非功能的需求之外，如果老板要求支持万人直播，这个时候平台的架构师该怎么办，这是在设计阶段就要考虑的问题，本来已经有一万人能够满足了，但是现在直播平台太火爆了，必须要能撑两万人，然后运行整个平台能够同时开一千堂课，每堂课两百人，怎么才能做到？这些问题可能是在一开始设计的时候就考虑到了，但是还有可能是在具体的运营过程中，随着业务的增长，出现了一些技术性的难题，如果不解决，业务就会遇到瓶颈，业务增长就遇到了一个很大的困难，甚至有用户说我不来你这里了，这里技术太差了，这些技术难题如果在团队里没有人能解决，那么就是架构师必须挺身而出的时候。
人员管理与指导
除了架构师自己能搞定很多困难的问题，当然他之前有可能自己就是一个开发高手，但是在团队里面成为架构师这样的一个角色后，他绝不可能自己单打独斗，他还需要帮助其他的开发技术人员得以成长，这个时候就涉及到了人员的管理和指导，所有的活都让架构师来干是不可能的。
技术决策与推进
架构师首先是技术人员，而且他可能是这个团队里面对于技术的理解、掌握最高明也最透彻的人。在很多时候，他需要做技术的决策，决定整个团队的技术的发展方向，整个产品的技术基础。不仅是他要做这些决策，还要保证这些决策能落到实处，能够真的让这个软件的发展是按照他的预想来进行的，这就是架构师的工作。
小团队并不是不需要架构师，任何一个团队哪怕只有一个人，这个人也一定会做一些技术的决策，同时他也会成为这个技术决策的执行者，这个时候其实他就是兼架构师。那么两个人、三个人、五个人的团队，总会遇到一些需要决策的技术问题，往往我们会发现在这个团队里面有谁是这些技术决策最终的决定者，因为各种原因他说服了所有人，反正最后大家都听他的，那么这个人无论他有没有一个职称，他都是架构师。
程序员怎样能向架构师方向靠近
作为一个普通程序员，如果我们不仅停留在表面，还去关注一个事情，需求、设计、函数为什么会那个样子，当我们去追根溯源理解更多的时候，就开始往架构师方向走。如果觉得活干的很累，事情老是做不完，又出bug，而且经常会和别人出现各种各样的冲突，因为各种各样协调不一致的原因，系统代码又错了，这个时候不仅仅是简单的去责怪别人，我会去想，在架构上是不是出了问题，在当初设计的时候是不是就没有设计好，所以才会出这么多问题，当我们以这样的方式，从全面的，整体的，追根溯源的角度去思考问题的时候，就开始像一个架构师了。
什么是管理能力？
收集信息的能力
在管理一些事情的时候，首要的目标是做出正确的决策，那么在此之前，需要收集足够的信息，来帮助理解需求是什么，限制是什么，老板要求做到什么样子。比如说要做到在线购物，一键下单，在三十秒内就可以把货加入到购物车，然后就开始进入配送流程，这些都是需求，同时还有很多限制，老板要在全国开60个分店，60个分店的网络要连在一起，这是需求同时也是限制，因为要去找那么多台机器，联系多个机房，或者说没办法联系这么多机房，那么就要在有限的机房里面，同时支撑着60个城市的网络速度。如果无法同时支撑的话，需要考虑CDN这样的部署，如果自己的公司不打算建CDN的话，就找云服务商，去解决这些问题。
除了收集这些信息外，还需要收集的信息有哪些可供选择的选项，技术决策、技术选型这都是选项，这些选项当中，最难的是那些热门的看上去很多人都很喜欢的、一旦用了以后给人感觉很高端，比如说用一个NoSQL的数据库、AI人工智能的框架等等，这些东西非常拿得出手，但是不一定真的用得上。
分析问题、做出决策的能力
怎么能去做出决策，权衡利弊，或者说能不能把每一个选项的好处和坏处都列出来，去估算它究竟会带来多大的影响，比如说选择了一种数据库，名字叫MySQL，那么MySQL的数据量撑到多少的时候会出现瓶颈，还是说MySQL多少数据量都没有问题，但是这个时候还要再想，团队里有没有MySQL的高手，如果有，则能够很有信心的解决它，如果团队里对MySQL都不熟，则可以判断一下业务的发展，如果在最近的一年内，数据量增长单表不会超过一亿条，因此可以一边用MySQL，一边随着业务的增长，有人去学习，这就是在分析权衡、做出决策。
授权与监督的能力
然后再进一步，做出了决策，要开始执行了，让谁去做什么事情，需要架构师要去授权、分配任务。授权完了以后，怎么判断他做的怎么样，去监督评价他的工作，指出哪些地方需要提高，或者说让别人来做，他去做其它事情。
收集反馈、及时调整的能力
同时作为一个架构师，决策可能会出错，如果架构出了错或者决策出了错，在哪里可以得到反馈，可不可以及时的做调整，比如说选择了一个消息队列的RabbitMq或者ZeroMq等等，然后在这个过程中，因数量大了产生瓶颈，这个瓶颈到底是在技术选型出的问题，还是参数没有配置好，还是说这个地方用消息队列就错了，我应该用别的东西。
对于架构师来说不仅仅要能够做出正确的决策，还要能够判断有没有错，如果错了，能不能够及时的认错并改正，这可能比做出正确的决策还要难，但是，所有的架构师都能够做正确的决策，不会犯错误，并不现实，减少错误，及时改正，这是非常重要的，甚至是不可或缺的能力。
走向目的地的能力
在庄表伟看来，管理能力就是走向目的地的能力，或者说带领团队一起达成目标的能力。在这样的一个过程中，首先知道目标在哪儿，其次，能够把这个目标传递给整个团队的每一个人，能够一起往前走，如果走错路了，还能修正方向，最终能够走到那，这就是管理的能力。我们的团队在技术方面，在架构方面是有追求的，那么怎么样才能够实现这些追求，这就需要架构师有管理能力。如果说有一个架构师说，架构已经设计好了，但是成员都不听他的，或者说架构都设计好了，他们下面人就乱来，这证明架构师管理能力不足，因此架构并没有落到实处，这就是由于管理能力的缺乏而导致的。
架构师应该管些什么？
架构师应该管些什么呢？利用他的管理能力，或者说发挥他的管理特长，他应该管的是什么架构，质量和进度，我们分这三个方面来一一的展开来说。
架构师如何管理架构？
制定架构规范
架构师如何来管理架构，这是他必须要做到的工作，我们可以分三个部分来说，先说如何制定架构规范，写架构文档是必须的，架构文档中有一个部分，很容易被忽略，就是架构的规范，系统会做成什么样子，这是架构设计文档，无论是逻辑设计、部署设计、框架设计还是数据流图，这些都是架构文档，但是，架构还要有规范，这些规范的目的是明确什么是对的，什么是错的，甚至仔细到，我们这个项目组如何来命名，函数怎么命名，文件怎么命名，对象怎么命名，包怎么命名，调用要用什么规范，如何来传递参数，如何来确保它的单元测试是正确的，如果遇到了错误，应该以什么样的规范去修正它，遇到了一些需要去检查的漏洞，应该有一个检查的列表，这些都是规范。为什么要制定一些规范，其实来源于过去的经验，没有规范，往往就会产生很多的争论，会耗费大量的时间，除非已经定下来了，所有的成员都这样做，那么就没有争论。
参与需求评审
其次是参与需求评审，架构师并不需要关注所有的需求，但是每一个需求他都要过一遍，他知道只有这些需求，因为需求可能会导致架构的变更。新来了一个需求，架构师要有敏感度，需求会不会对架构产生影响，而不是项目经理把任务分一分，做一段时间，这个架构好像跟当初设计的就不一样了，这个时候架构师就得喊停。还有一种情况，需求来的很频繁突发，架构师要按照这个趋势应该抽取出一个模块，来满足这三个甚至五个需求，架构师应该在这个模块上，定义一些足够好的API，确保将来再发生新的变更的时候，这个API能够工作的很好。
还有一种就是，简单需求导致架构风险的例子，比如说，某一个产品经理要求下个礼拜搞一个活动，是一个促销活动，每30个人当中，会让一个人中奖，让他能够全场免单。然后可能觉得，这个需求很简单，就30个人里面做一个随机数就结束了，但是万一他的促销力度其实很大，因为他的免单是没有上限的，这就是一个架构的风险，因为它会导致一个访问量的巨大的一个涌入，这个时候必须提前的预感到架构，可能会存在风险，要么就跟产品经理说现在的架构承受不了这个促销活动，不能免单，最多打对折，如果免单的话，架构承受不了，或者是说，推迟一下，先把服务器扩容，能够把这个促销活动撑下去。
架构看护
管理架构，有一件事情，很多架构师也许不会注意，架构师需要看护的。架构设计完成，仅仅是一个开始，因为架构一定会逐渐的腐化，如何推迟这个过程是架构师永远的难题，看护就是不断的去看现在这个架构写成什么样子，项目组有五个人或十个人，大家每天都在往里面写代码，要去看这些代码是不是在乱来，虽然他们都完成了需求和功能，功能测试也正确，成员还在按照当初的架构的设计的方向在走，如果他们已经没有像架构师设计的那样做。他们在随意地命名、加模块和加对象的时候，要及时的叫停，甚至说不行，推翻重来，架构师不能接受架构变更，这个时候架构师要做的工作可能会面临很大的阻力，但是他必须把架构给看住了。
有很多销售主导的公司，首先架构师需要的不是去坚守。而是去理解销售到底想要做什么，而且要去理解销售的那一套话语权，理解他的那一套话语，然后说，长期来看销售如何才能够做到最大和最多，如果从这个角度，再去考虑架构该怎么做，则不是去对抗的，是去帮助他们。这个时候才有可能和每一个团队，每一个部门和每一种角色都形成好的合作。
架构师如何管理质量？
明确质量标准
架构师除了管理这个架构，当然还要管质量。因为产品的质量，很多时候是由架构的设计决定的，前面说要设计架构规范，其中有一部分就是质量的标准。我们可以关注两类质量，有一类质量比较清晰一些，比如说可以量化的，每1000行代码或者1万行代码，里面一共发现多少个bug，这些bug越少，这个系统的质量越高，这些可能不是架构师需要特别关心的问题，但是还有一些质量是无法量化的，比如说，同样的测试，一个代码测试下来完全没有问题，但是代码写的很烂，可能架构没有解耦，命名混乱，嵌套深度太深，依赖关系没有梳理清楚等等，这些问题很难被简单的量化。可以用一些检查工具，去检查有多少个架构缺陷，这些是很难被量化的。而且更重要的是，这种架构质量，很多时候只有架构师这样的资深的开发人员才能够明确的提出来说，架构不能够这个样子，就是质量标准必须明确。
关注DFx
第二个部分是华为内部的一个说法，叫DFx。（Design for X ，表示面向产品非功能性属性的设计。其中“X”代表产品生命周期或其中某一环节，如供应、安装、维护等，也可以代表产品竞争力或决定产品竞争力的因素，如可靠性、节能减排、网络安全性等。）我们通常会做面向可靠性的设计，面向环保的设计，面向可服务性的设计，这些东西都不是面向最终用户的，可见需求的设计，都是非功能性的需求。
在设计架构的质量的时候，如何去界定，例如可靠性，假设一个系统它会down机（指服务器离线），那么最直觉的一个办法是，要做一个分布式的系统、负载均衡、双机热备，来提升它的可靠性，但是假设要求可靠性能够达到99.999%，现在有十台机器，能不能保证99.9%或者99.999%，如果算不出来，或者说心里就没底。或者说就加机器进去，加到足够就不会有事，那其实证明心里是没数的，并不知道要达成99.9%的这个可靠性，需要做到多少才能够实现。而且再往下说的话，光靠加机器不能解决问题，机器多了以后带来的更多的不稳定性和系统的复杂度的增加又怎么办，以及成本的上升怎么办。还有一种设计叫做可服务性，有一个概念叫做服务质量的优雅下降，当系统出了故障以后，首先要保障的是哪些服务。然后如果这个系统故障再一次蔓延的时候，还能够维持住哪些东西，最后才坏掉，这些都是在做架构设计的时候需要考虑的东西。
CODE REVIEW
架构师如果想要关注质量，想要把质量管好的话，他必须深度参与codereview，通过代码评审来把好这个质量关，有很多研发团队，都会自己在公司里面搭一个gitlab，有些公司会直接把他的项目放在像我们华为软件开发云上，那么，我们软件开发就会支持一个基于Mergerequest的合并请求的codereview，架构师需要做codereview其实是在代码合入主干之前就去评审，这些代码是不是满足质量的要求。与此同时，通过代码评审，尤其是通过架构师对于代码的评论、意见和建议，来帮助整个团队的成员不断的提升技术能力，这样才能够把质量管起来，如果说这个代码已经合入进去了，编译测试都通过，甚至都已经上到生产环境了，这个时候再去看，代码质量好像不太好，这个时候就已经晚，防微杜渐最好是做在前面的，这就是codereview的重要性。
架构师如何管理进度？
分析依赖任务
一个稍微大一点的项目的话，项目经理和架构师是两个岗位。但是作为产品经理不了解架构，你做不好产品，反过来你如果做架构师不懂产品的话，你做不好架构师。架构师要关注和管理进度，因为仅仅是按照需求的角度说，按照需求的优先级排序，先做最紧急最重要的，然后再做次重要的和次紧急的等等，但是这样会存在问题或者存在风险，首先，架构师需要分析任务之间的依赖关系，某某需求没法先做，因为另外的一个需求还没完成，或者说架构改造还没完成，撑不住后面的这个需求，所以，按照现在的设计和技术的现状，最好是以XYZ这样的顺序来完成任务。这样不仅仅是更加的合理，而且会更加的有效，通过这样的角度，架构师其实对于开发进度是有自己的发言权。
提出前瞻性需求
还有一部分是，提出一些前瞻性的需求，就是说从客户和产品经理那并没有发现这些需求，但是从产品总架构师来说，要提前预见这些问题，请注意，关键词是提前半步，不要超前太多。比如说现在的数据量，大概就是100万左右，但是已经要考虑分布式，多中心，以10亿级别甚至百亿级别的容量去规划，考虑可靠性和稳定性，那就是想太多了，纯粹的为了追求技术而冒险。
核心代码和单兵能力
还有一个角度，其实不能说是架构师去管理进度，而是架构师要参与和影响进度，比如说，有一些核心的代码，就应该是架构师来写，框架性和接口性的，这种规范性的代码架构师来写，哪怕现在没有最重要的任务，需要架构师来写代码，架构师也要自己写写，因为三天不练手就生了，缺乏了对于代码的感悟，也缺乏了对于当前所用的这些技术的敏感度，就会出问题，而且架构师也必须具有这样的能力，任何人如果说这个事情做不了，架构师能够把这个人推开，自己来写。但是这样的行为要慎重，因为不可能动不动就把别人推开，自己干，那么团队人员的能力是无法成长，只能靠自己，那还要别人来干什么，都自己干完了，别人不干了肯定都是不行的。
架构师如何做管理？
分析
架构师如何来做管理，首先他要有分析的能力，尤其不仅仅是分析技术，还需要理解需求背后的商业目标，因为一个产品经理。他跟你提了一个需求的时候，你可能只是很直觉的说，在技术上如何去实现它，却没有想过，这个需求背后真正要达到的商业目标是什么，因此很有可能仅仅是实现了眼前的一个需求，缺乏前瞻性，如果你看出来了这个产品经理，他其实想要达到的是一个什么样的方向，如果现在不去考虑的话。那么将来的架构会出现风险。
另外一方面，要能够看得出技术发展的方向。比如说看出容器技术是一个必然，成为主流技术的一个方向，在多久之前就开始投入容器的研究，比如说庄表伟认识一个高手，远比他厉害，是他第一家公司工作的同事，当他在研究docker的时候。他的同事已经用了一年多docker了，公司里面已经全部docker化了。他当时真是佩服的不得了，因为他听到docker的时候其实也蛮早，是docker刚刚火起火起来的大概半年的时间，但是他得同事在火起来之前就已经关注到了，甚至就已经在公司里面用起来。这是一种非常了不起的前瞻性，这是对技术的准确把握的能力。
决策
架构师需要做决策，在做决策的时候，如何去判断这个技术是合适的，所谓的合适，不仅仅从技术的层面去了解他是合适的，必须了解真正的商业目的是什么。举个例子说，要做一个直播平台，要实现很多很多的功能，一个直播平台最终是靠什么赚钱，对于这个直播平台来说，最值得留下来的是什么。一个直播平台，最重视的，很有可能是这个直播平台能够留住多少用户，今后来到这里来上课，那么对于想要留住用户这样的一个商业目的，再来讨论，把用户都留下来了，他们能够为直播这个平台带来利润吗？在技术上首先要支撑的需求是谁，可能是回看或是回听，比如说一场直播做下来了，很多直播做完了就没了，现在像千聊这样的，或者说还有其他的直播平台，可以回看所有的直播，从头到尾看下来，包括当初所有的人的聊天记录，所有人的问答记录都能够留下来，这就是从商业目的出发，来做的技术决策，要把所有的直播的内容全部存储下来，方便回答。
推进——成为技术布道师
其实很多时候做管理，不仅仅是说做决策，更重要的是推动别人去做事情，尤其是推动别人做的那些事情达到了，想要达到的目标就是管理。那么作为一个技术管理者，或者说作为一个架构师，要想推动别人做事，就要成为一个技术的布道师，在内部做各种相关的技术的宣讲，或者说上课，或者说鼓吹某某新技术，值得大家去学习，这个就是布道师的一部分，但是当然我也可以比较传统的，带几个徒弟。可能会写博客、做直播、写文章或是写书，来建立在这个公司内外的技术影响力，有时候影响力很有用，虽然你同样说同样的话，但是一个有影响力的人说这些话别人就会听，就会在心里，别人就会愿意照你的去做，这就是建立影响力之后，对于做架构的人带来的好处。
架构师需要管理哪些人？
如何管理上级——获取支持
作为一个架构师，其实需要管理很多人，很多时候，我们说管理通常只认为是管理下级。其实架构师也需要管理上级，管理同僚，管理下属。管理上级的用处是获取支持，支持你去做那些架构的变更、追求那些架构的这个方向，如果他们觉得你不靠谱，在吹牛，你自己都没有搞明白。那么你的技术方向就不会获得支持，这个时候学会讲故事很重要，把一些复杂的技术问题，通过一个简单的故事让领导明白。这个非常重要。架构师的领导不会是架构师，就算他很厉害，非常牛，但是他不会特别专注于你的那个领域，因此你能够让他理解你这个领域的那些事情，那些决策的来龙去脉，你能不能够表达清楚，让领导相信你，无论是技术的决策，还是所有的风险，你都考虑到了。你如何让领导相信这些，这就是管理上级的一部分。
另外一方面所谓显得靠谱，重要的一点是能够长期的让领导对你产生合理的期待。有些人会喜欢吹牛，而且他吹牛的能力很强，他确实让领导相信他能够撑住一万人，或者说十万人，或者说100万人怎样，或者说百万并发不在话下。领导真的信了，然后搞砸了，然后领导再也不相信你，这个人就不靠谱，以后他再说别的话，领导会觉得他无非是夸夸其谈，这个人在领导的心目中信任度下降的厉害，这就是很惨的一种事情。通常在这个时候，要么就是慢慢的熬出来，重新变得靠谱，要么就真的只能换工作了。
如何管理同僚——改进协作
稍微复杂一点的公司，或者稍微复杂一点的项目里面，通常不会只有一个架构师，甚至不会只有一个项目组，会和其它的项目组合作，所以我们会做自己的架构，同时也会评审别人的架构。因为我们互相之间有调用关系和依赖关系，或者我们甚至互相之间都访问的是同一个系统。比如说中间层或者是底层的，这个架构，如何让别人能够支持你，或者说你能够支持别人，很多时候，同僚之间，大家没有上下级关系的时候是比较难相处，因为你其实并不知道他具体是怎么工作的，或者说他也不了解你有多少难处，他也不会特别好的支持你，你也不太想特别好的支持他。这个时候，要与人为善，也许对于同僚来说，无论是他的架构、他的这个系统还是他的那些API，能帮上一些忙的时候，就去帮他，也许将来他也会帮你，甚至大家都会有需求排队的情况，他会帮你先把你的那个需求做了，这个非常现实，如果你能够识别出这个团队当中的其他那些人，你很乐于去帮助别人的时候，你会收获一些善意，甚至收获一些友好度和便利，这是很划算的事情。
如何管理下属——能力培养
管理下属也很重要，对于一个架构师，而不是项目经理，管理下属首先要达到的目标，跟项目经理有区别，项目经理首先达到的目标是保证项目进度完成，保证项目质量不出问题，而架构师很多时候是培养能力的角度出发，要让下级能够快速地提升能力，很重要的一点是点燃下属对于技术追求的渴望，不仅仅是在宣传，这个技术很好，你们去学一学，而是，他们本身对这些技术产生一种追求。在分配任务的时候，不是说他能完成，我就让他做，他不能完成的，就不让他做，很多时候，我们会帮助那些有潜力的新人，让他们去做一些略有挑战的任务，让他们能够逐步的提升能力。对于这些在成长中的员工来说，他们会认为自己在这个团队里面在成长收获，更加有干劲，这恰恰是非常重要的一种管理能力。
SCM人员如何协调与开发人员的关系
配置管理人员其实是帮助架构师去管理那些架构规范的。就比如说命名规范、目录规范，如果用data或是用SVN的话，一定有分支的命名规范和合并规范等等，这些东西是为了帮助开发更加顺畅的，而通常这些规则的执行者就是SCM人员。SCM人员很有可能的问题是，他们简简单单，只是一个规则的执行者，他们并不理解这些规则。于是就会被开发人员所鄙视，啥都不懂就在这管理。如果SCM人员更加的理解架构、架构背后的原因和架构规范的来源。这个时候他们可以理直气壮的怼回去。而且他们在执行架构规范的时候也可以更加的合理、灵活和变得正确，这时候他们的价值才能够体现出来。
题外话
一将无能，累死三军
因为庄表伟原来做过一个关于架构师的演讲，其中反复的强调这个“一将无能累死三军”的问题。很多时候，如果一个系统，开发的过程出现返工，最大的返工就是系统推翻重做，全部重做，或者说架构推翻，重做或者重构，如果架构出现错误和隐患，上线以后挂了，一将无能，就会要累到所有人加班，推翻重来。作为一个架构师，不仅仅是高高兴兴地把架构设计出去，往外一扔就结束了，而是负担着巨大的责任，如果做不好这一点，就是有罪的。
你应该懂得更多
作为一个架构师，应该懂得更多，不仅是懂管理，刚才在前面的一些部分也提到了，要懂产品、市场、用户、业务、需求很多东西。甚至有必要的时候能够去做客服，能够把用户的需求给搞清楚，去做销售，把客户攻下来，去做运营等等。因为这些东西最终都会影响架构，越懂得多，架构才有可能做得更好。
架构师必须了解的是整体是全局，甚至是周边，对于细节他可以不太了解。系统代码出现问题，如果有必要，他可以理解到最细节的程度，如果说发现这地方有一个问题、疑点和难题，可以一头扎下去，从头到底，到最底层的代码全都能够看懂理解，这是一个重要的能力。如果没有这样的能力垫底，只是泛泛的了解，所谓的浮在面上的懂一个大概，这是非常危险。无论是自己被自己坑了，还是自己被别人坑了，都是有可能。
不要小瞧PPT
不要小瞧PPT。为什么要说这句话，其实，怎么说呢，因为我在某一个JavaEye老炮群里面，其实聊过这个话题，很多人做技术的人，尤其是技术比较钻研，对技术有追求的人，通常会瞧不起一种叫做PPT架构，真的有这样的架构师，他们最擅长的是写PPT，但是千万不要小瞧PPT，PPT是一种表达观点，说服他人贯彻执行用的工具，如果你的PPT写不好，通常你的表达能力会不够好，通常你的沟通能力也不够好，甚至很有可能你的逻辑思维能力都不够强，写一个好的PPT是非常重要，非常关键的能力，群发这样的能力很有可能在职业成长的过程中受阻。
架构师的工具箱
架构师需要很多工具，除了技术的那些工具和刚才说的PPT，还需要很多的画各种的图的工具。最重要的一点是，架构师需要去了解非常多的工具。有必要的时候它们都能用起来，甚至说，Excel玩的很好，可以通过Excel来帮助分析架构当中的问题。vision玩的很好，UML玩的很好，还有很多在线的工具，玩的很好，这些工具都有帮助，如果没有这些工具的话，就只能在各种低效率低水平的层面去挣扎。
为什么选择软件开发云
