Abstract at 20:00 on December 27 2017, live chat platform for thousands of Huawei's cloud developers topic in the league, there are many IT industry friends, Huawei cloud cloud software development as a lecturer, senior product manager, conducted a live broadcast to "architect of basic skills - management articles" as the theme, shared management of the reasons as the architect of basic skills, the management of what and how to manage.

Huawei said Yunda coffee - Zhuang Table Wei: Architect of basic skills - management articles

Speaker: Chong Wei table, open source community director, well-known programmer GitHub,

Author of "open source thinking set" for many years been in the first line of programming,

Coding and with maximum pleasure. Former Huawei endogenous community

Platform Architect, currently Huawei cloud cloud software development, senior product manager.

Architect is doing what?

Architect is a global concern, or that he is not concerned about the implementation of the current task, more importantly, the entire system as a whole structure, it is not reasonable, it is possible that the architect may not understand some of the specific details so he will grasp the overall situation.

Technology Selection

Architect is doing what? , According to the common situation in general, the first thing to do his selection techniques, in any place choose what technology, for example, in PHP, JAVA language, or Ruby programming language. NoSQL database database option, the market heard or something else very advanced database, or what kind of message queues. These techniques can not choose, what the risks are, after the election, and this is the architect of issues to consider. Many times reasonable selection of technology, not to know the details, but to know about, especially to understand some of the industry's authoritative evaluation, if know a lot of powerful friends, although they are not very clear thing that in the end it really easy to use, but look for a friend ask some friends cattle cattle company, they have been used, and ask them to find, they will be able to tell that he is not tricky, from this perspective, to learn more about some of the fly , cattle architect is also a very important skill.

Architecture design

After architecture selection, certainly do architectural design, this architecture is designed to look like, there are some delamination front and rear ends, business layer, logic layer, data layer, etc., but also to consider how to deploy, in addition to logic architecture, as well as to the deployment of architecture, but also consider how to facilitate the operation and maintenance, which are involved in infrastructure issues to consider.

To achieve non-functional requirements

In addition to the software do need to meet a variety of needs, as well as some non-functional requirements, for example, do a live platform, to be able to meet the lecturer can speak typing, the ability to upload pictures, these are functional demand, rather than functional needs what, say, thirty seconds can be recorded in a recording, or to record a one hundred eighty seconds of recording, and after recording finished uploading, how many delays to hear, now listen If people live fifty, and a hundred, a thousand or ten thousand people, what kind of time delay will change the number to how much time the delay will be unacceptable, these are non-functional requirements.

Solve technical problems

In addition to achieving the needs of a wide variety of non-functional addition, if the boss asks people to support live, the architect of the platform at this time how to do, this is a problem in the design phase must be considered, there are already a million people can met, but now live platform too hot, we must sustain twenty thousand people, then the whole platform can simultaneously run a thousand such class, two hundred people per class, how can we do? These problems may be in the beginning designed to take into account, but there may be in the process of specific operations, as the business grows, there have been some technical problems, if not solved, the business will encounter bottlenecks, business growth encountered a lot of difficulties, and even user you say I do not come here, where technology is bad, these technical problems can be resolved if no one in the team, then that is when the architect must come forward .

Personnel management and guidance

In addition to the architect that he can get a lot of difficult questions, of course, possible before he himself is after a development expert, but in the role of a team which has become such an architect, he himself could never go it alone, he needs the help of others development and technical personnel to grow, this time related to the management and staff of guidance, let all living architect to dry is impossible.

And to promote technical decision

The first is the architect technician, and he may be the team which for technical understanding, grasp the wisest and most thorough people. In many cases, he needs to make decisions and technology, decided to develop the technical direction of the team, the technical foundation of the entire product. He not only do these decisions, but also to ensure that these decisions can be carried out, can really make the development of this software is expected to follow him, and this is the work of architect.

小团队并不是不需要架构师，任何一个团队哪怕只有一个人，这个人也一定会做一些技术的决策，同时他也会成为这个技术决策的执行者，这个时候其实他就是兼架构师。那么两个人、三个人、五个人的团队，总会遇到一些需要决策的技术问题，往往我们会发现在这个团队里面有谁是这些技术决策最终的决定者，因为各种原因他说服了所有人，反正最后大家都听他的，那么这个人无论他有没有一个职称，他都是架构师。

程序员怎样能向架构师方向靠近

作为一个普通程序员，如果我们不仅停留在表面，还去关注一个事情，需求、设计、函数为什么会那个样子，当我们去追根溯源理解更多的时候，就开始往架构师方向走。如果觉得活干的很累，事情老是做不完，又出bug，而且经常会和别人出现各种各样的冲突，因为各种各样协调不一致的原因，系统代码又错了，这个时候不仅仅是简单的去责怪别人，我会去想，在架构上是不是出了问题，在当初设计的时候是不是就没有设计好，所以才会出这么多问题，当我们以这样的方式，从全面的，整体的，追根溯源的角度去思考问题的时候，就开始像一个架构师了。

什么是管理能力？

收集信息的能力

在管理一些事情的时候，首要的目标是做出正确的决策，那么在此之前，需要收集足够的信息，来帮助理解需求是什么，限制是什么，老板要求做到什么样子。比如说要做到在线购物，一键下单，在三十秒内就可以把货加入到购物车，然后就开始进入配送流程，这些都是需求，同时还有很多限制，老板要在全国开60个分店，60个分店的网络要连在一起，这是需求同时也是限制，因为要去找那么多台机器，联系多个机房，或者说没办法联系这么多机房，那么就要在有限的机房里面，同时支撑着60个城市的网络速度。如果无法同时支撑的话，需要考虑CDN这样的部署，如果自己的公司不打算建CDN的话，就找云服务商，去解决这些问题。

In addition to gathering information, but also information on what options there are to be collected, technology decision-making, technology selection to choose from which are options that are among the hardest are those who look a lot like the very popular, Once used after a really high-end, for example, with a NoSQL database, AI artificial Intelligence framework and so on, these things are very show for, but not necessarily really need them.

Analyze problems, the ability to make decisions

How can you go to make a decision, on balance, or can not put the pros and cons of each option are listed, to estimate whether it will bring much impact, for example, select a database, called MySQL, then MySQL is the amount of data to support how much time there will be a bottleneck, or to say how much the amount of data MySQL is no problem, but this time even to think about, there is no MySQL team of experts, if any, can be confident of solving it If the team of MySQL are not familiar with, you can determine what the development of business, if in the last year, the amount of data grows sHEET not more than one hundred million, so you can side with MySQL, while business grows, it was to learn, this is the trade-off analysis, decision-making.

The ability of the authorization and supervision

Then further, to make a decision, to begin, let anyone do anything, you need to go to licensed architects, assigned tasks. After authorization is over, how do how to judge him, to oversee the evaluation of his work, pointing out what needs to improve, or that someone else should do, he do other things.

The ability to collect feedback, timely adjustment of

At the same time as an architect, the decision may be wrong, if the wrong decision or wrong architecture, where you can get feedback, is it possible to make timely adjustments, such as selecting a message queue RabbitMq or ZeroMq etc., and then in this process, due to the large number of bottlenecks, the bottleneck in the technology selection in the end is out of the question, or the parameter is not configured, or that this place is wrong with the message queue, I should use something else.

Not only to be able to make the right decisions for the architect, but also be able to determine there is nothing wrong, if wrong, can we not be able to admit and correct in time, it may be even more difficult than to make the right decisions, however, All architects are able to make the right decisions, not make mistakes, is not realistic, reduce errors, correct them in time, which is very important, even indispensable capability.

Ability to destination

在庄表伟看来，管理能力就是走向目的地的能力，或者说带领团队一起达成目标的能力。在这样的一个过程中，首先知道目标在哪儿，其次，能够把这个目标传递给整个团队的每一个人，能够一起往前走，如果走错路了，还能修正方向，最终能够走到那，这就是管理的能力。我们的团队在技术方面，在架构方面是有追求的，那么怎么样才能够实现这些追求，这就需要架构师有管理能力。如果说有一个架构师说，架构已经设计好了，但是成员都不听他的，或者说架构都设计好了，他们下面人就乱来，这证明架构师管理能力不足，因此架构并没有落到实处，这就是由于管理能力的缺乏而导致的。

架构师应该管些什么？

架构师应该管些什么呢？利用他的管理能力，或者说发挥他的管理特长，他应该管的是什么架构，质量和进度，我们分这三个方面来一一的展开来说。

架构师如何管理架构？

制定架构规范

架构师如何来管理架构，这是他必须要做到的工作，我们可以分三个部分来说，先说如何制定架构规范，写架构文档是必须的，架构文档中有一个部分，很容易被忽略，就是架构的规范，系统会做成什么样子，这是架构设计文档，无论是逻辑设计、部署设计、框架设计还是数据流图，这些都是架构文档，但是，架构还要有规范，这些规范的目的是明确什么是对的，什么是错的，甚至仔细到，我们这个项目组如何来命名，函数怎么命名，文件怎么命名，对象怎么命名，包怎么命名，调用要用什么规范，如何来传递参数，如何来确保它的单元测试是正确的，如果遇到了错误，应该以什么样的规范去修正它，遇到了一些需要去检查的漏洞，应该有一个检查的列表，这些都是规范。为什么要制定一些规范，其实来源于过去的经验，没有规范，往往就会产生很多的争论，会耗费大量的时间，除非已经定下来了，所有的成员都这样做，那么就没有争论。

参与需求评审

其次是参与需求评审，架构师并不需要关注所有的需求，但是每一个需求他都要过一遍，他知道只有这些需求，因为需求可能会导致架构的变更。新来了一个需求，架构师要有敏感度，需求会不会对架构产生影响，而不是项目经理把任务分一分，做一段时间，这个架构好像跟当初设计的就不一样了，这个时候架构师就得喊停。还有一种情况，需求来的很频繁突发，架构师要按照这个趋势应该抽取出一个模块，来满足这三个甚至五个需求，架构师应该在这个模块上，定义一些足够好的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玩的很好，还有很多在线的工具，玩的很好，这些工具都有帮助，如果没有这些工具的话，就只能在各种低效率低水平的层面去挣扎。