架构师的技术升级之路

1 就像大家以前准备政治考试时，先准备大点，在保证大点不拉下的基础上，再详细复习每个大点里的细节。比如，可以先了解Spring Cloud里有哪些组件，比如Ribbon可以用来负载均衡，Hystrix可以用来容错等，先把Spring Cloud里诸多组件先了解个大概，能用它们搭建成一个微服务体系后，再深入了解其中每个组件的细节，比如Spring Cloud Stream里Kafka配置细节。

但我经过和多位架构师沟通，他们在升级时，多少都在这方面走过弯路，我自己有时候也会不知不觉陷入技术细节之中，而忘记我学这个技术的初衷。这里给大家的建议是，在明确学习目标后(比如要学Spring Cloud)，刚开始别先自己闭门造车地为自己制定学习目标，可以先借鉴现有的视频讲解等的学习路线。制定学习计划时，以两到三天为单位，给自己定好一个短期目标，等到Spring Cloud组件全都了解后，再通过运行通若干个案例来深入了解组件的细节，这样就能控制住自己的学习步骤。

2 千万别理论和实际脱节。这似乎是废话，但我见过很多高级开发，平时就看视频和书，也不运行代码，结果进步的速度很慢。

如果没机会实践架构技能怎么办?看自己组里有没有架构的活。如果也没有怎么办?(别嫌我啰嗦)回家自己准备环境，按视频里的搭建架构环境。必要时，你甚至可以通过跳槽来换得一个架构师的实践机会。

3 架构师可以是技术控，但绝不能是完美主义，毕竟解决方案得和实际业务切合，并得考虑解决问题的成本。而且，架构师不能过于拘泥于细节，不能什么都事必躬亲，很多时候，得给出方向，或者把问题拆分成开发能理解的子问题，然后让手下人去干。 这似乎和技术没有关系，这就要求架构师更具备和人打交道的能力了，这点将在本文的第6部分详细说明。

6 指导技术难于自己实现功能，再论资深架构的协调(或者说扯皮)能力的炼成

不少开发者，尤其是资深开发者，或许都有这样的体会，对于一些功能，我宁可自己做，而不是把它们拆分成若干个子功能再安排手下人去做。或者我宁可去攻克一些技术的难题，也不愿意去和人扯皮，从而去制定架构里组件的选型方案。

可以这样说，架构师30%的价值来自他拥有的专业技能，30%的价值来自他分析和解决问题的能力，而40%的价值(甚至更高)来自于指导和协调能力。除去最后40%的价值，架构师其实和高级开发没什么差别。比如通过下面的例子，我们能看到架构师为什么还得具备指导和协调的能力。

案例1：当架构师被要求改善本公司系统(比如是个应用网站)的调用性能时，他就得和多个组打交道，往往是，有些组未必肯支持(毕竟现有系统用得不错谁都不愿改)，或者具体的改善点需要一些组来落实，这就相当于增加该组的工作量了。

案例2：当架构师搭建好一套分布式缓存系统后，就得培训其它组的开发人员，让他们合理使用这套系统。

案例3：又如架构师帮一个组解决了一个典型的OOM问题后，得把解决这个问题的思路向其他组推广，以便节省解决同类问题的时间。

从上述案例中，我们一定能感受到在沟通，协调方面架构师需要掌握的技能水准。这方面说难不难，多练就行，但对IT开发而言，动嘴要比动手写代码要难。下面也给出些提升“动嘴”能力的技巧。

1 首先得提升自己综合逻辑思维的能力，这点可以靠多写博客，甚至写书来提升。其实写的时候，就相当于把自己要讲的内容用文字整理了一遍，这样无形中也提升了自己综合表达能力。

2 在组内要多分享技术。其实刚开始分享时，一定不知道该说什么，甚至讲完后没人能懂(当然自己一定能懂)，但多讲几次后，口头表达和与别人的交流能力也上去了。

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!