0.开篇

从广义角度讲，我现在就是一名架构师，在一家非著名公有云小厂做架构工作。在工作中也是摸着石头过河，积累了一些经验。听了智慧老师的课后深有体会，产生了诸多共鸣。下面我将这些G点分享出来，供大家思考。



1.做架构？做架构师？

如智慧老师在开营仪式讲的那样，架构师训练营是训练大家做架构师的，不是教大家如何做架构。这两个有什么区别呢？我理解，做架构是各种方法的堆叠，是“过程”，做架构师需要架构思维的支撑，是“道”。就如会写字并不一定能让你写出打动人心的文章，也不会成为一个畅销书作者。文字只是方法和工具，思维才是核心。所以想做架构师，先从架构思维师开始。

2.架构师思维

这个话题很大，我仅仅说一下自己的理解。

思维可以理解为看问题的角度和方式，架构师和程序员看问题的角度不同，角度不同思考过程也就不同了。

架构师应该有三种架构视角：

2.1从上向下看：上帝视角、全局思维

一上来不要深入细节，不要总盯着一段代码，一个中间件，一个小模块、一个子系统，我们要站在系统之上才能看清楚系统的全貌，逐层递进，由简入繁。用代码逻辑，中间件等具体工具是无法拼凑架构，就像你只关注字写得好不好看，用词是否优美，语句是否流程也不可能写出一本好书一样。

2.2从前向后看：业务真的重要

我不想在强调业务和需求的重要了，其实没有业务就不存在程序员和架构师这个职业，那为什么我们还不重视业务呢。我总结有两点：

第一，技术人的职业优越感

“学好数理化，走遍填写都不好，技术人员技术牛就行，管他业务如何”

业务决定公司收入。老板请我们来是实现业务，完成公司业绩，不是炫技的。你球踢得再好，不进球也是白搭。不进球的前锋早晚让球队开除的。

第二，工作职责错觉

“业务和需求都是产品经理的职责，我们拿到PRD实现就好了”

程序员这么想还不严重，架构师可千万不能这么想。业务如此重要，制定业务的过程中需要相关干系人深度参与，架构师作为业务落地关键人，必须要参与到业务制定的关键步骤，为产品经理及干系人提供技术方面支持，这样的制定的业务才是可以落地的业务。简单说就是提早干预，全程护航。

2.3上下左右都要看：权衡利弊最关键

借用PMP的概念，软件工程开发涉及反方面面，时间、成本、范围、资源、质量、风险这些方面都需要权衡利弊，有舍既有得，妄想面面俱到。

这里展开说两点：

第一，场景必不可少

场景就是公司业务战略目标，公司业务方向，公司未来计划，公司现状，团队规模，当前投入，未来计划投入、对系统期许等等。做一个三个月上线、半年有产出的系统架构和做一个开发周期三年、做出来就是行业顶尖的系统架构完全不同。你不按照业务场景来闭门造车一定是行不通的。在当下中国互联网的大环境下，我相信大部分是前者。所以这就需要我们考虑下面的观点。

第二，架构需要进化，避免一步到位

记得我刚开始架构工作进行架构评审的时候，经常被相关部门同事说：“我们需要知道一个月后怎么办，不是一年之后怎么办。”

刚开始我在做架构设计的时候只想架构最终是什么样子的，没有想过他怎么进化到那个样子。

为什么不能一部到位？

• 一步到位落地周期过长，有可能错过业务红利期。

• 业务在变化，架构也需要变化，有可能架构落地后业务已经变化了。

• 想得多不一定想的对，过于复杂的架构有可能在落地是发现问题返工。

所以我们需要一个能进化的架构，既能小步快跑快速落地，支撑公司业务。又能分步落地，小步试错，降低风险。最重要的是每一次落地过程中产生的经验还可以适用到未来架构设计和开发过程中，这才是可进化架构设计的精髓。

这里还要强调一定，架构分步设计的原则是朝着架构最终目标演进。条条大路通罗马，但是你要确定你要去的是罗马而不是巴黎。

3.架构师是否还要写代码？

我已经很少有时间写具体业务代码了，但是我画的关键业务时序图基本上等于伪代码。

我现在会参与一些自研中间件和工具包的开发工作，我觉得这些工作对团队的意义远远大于撸起袖子写业务。我把刀磨快了，我的兄弟上阵杀敌才趁手。

这点和智慧老师说的让别人依赖你写的代码不谋而合。

4.提升团队整体产生

架构师的工作不只是架构做完就万事大吉了，你还要保证架构的落地及未来演化。所以你一个人是无法完成这项工作的，你必须依赖团队的支持，所以你的工作也从单打独斗变成了团队作战。团队建设，技术能力提升，团队管理等必不可少，你要将你个人产出变成团队产出。本着这个思路这样你在做每一件事情的时候就会知道该不该做，怎么做。这点很重要。如同写代码的例子，我写工具一定比我写业务代码对团队贡献大，产出高。



5.结语

以上就是我个人听完智慧老师课程后的一些感想，希望能对你有帮助，如果你有其他想法欢迎给我留言，架构师的道路上我们结伴而行。