为什么大部分程序员很难真正成为一个架构师?(图)

你有没有想过，为什么大多数程序员很难真正成为一名架构师？

很多也是不错的大学，毕业于计算机专业，计算机基础知识和技能没有问题，够努力，但还是有很多人不能真正成为一名合格的架构师。

从徒弟到匠人，从匠人到师傅，难点往往是转型的质变点。真正影响这个质变点的，还是你个人独立解决问题的能力和思维能力的培养。

认知升级——从外到内，从现象到抽象

我之前经常引用汽车观察认知的例子。即使大部分人实际上并不关心汽车的内部结构和汽车的运行机构，但只要知道汽车的外部构成以及如何使汽车移动就足够了。

这是错的吗？

老实说，这在大多数情况下都不会发生。

人的精力是有限的，你不可能深入所有新事物、新问题，了解事物的内在本质。但是回到自己的专业领域就不一样了。

面对自己的专业领域，必须从浪漫转向古典，探索事物的内在本质和工作机制。只有这样，你才能抽象出普遍规律，并将其应用到后续的新问题解决中。

当你深入研究问题时，你自然会将专业知识的广度转化为知识的深度。

而知识的深度对你来说是最有价值的。

一个人能解决复杂的问题，只是因为他见过，而不是因为他有分析和匹配问题的能力。

对于这样的人来说，面对一个新的领域，一个新的问题，往往是无从下手的。

因为他们还没有掌握在他们的专业领域中通用的问题分析和解决方法。

拿企业的业务流程来说，这些流程是千变万化的，但是当把流程分解的时候，你会发现所有的流程都是从底层的200到300个原子业务活动拼凑而成的。对于特定类型的技术问题也是如此。虽然你面临的问题不同，但都是分解后常见的原子能力。

一个问题的解决往往涉及三个方面。

你会发现问题分解并不太难。真正的难点在于你的原子可重用能力的储备，其次是这些能力应该如何组合。

如何提高这种能力？

一是每次解决一个新问题，都会通过来思考，在这个问题的解决方案中应该拆分哪些可复用的经验点。

二是养成定期深入回顾的习惯，即定期回顾是否发生过类似的场景或问题，这些问题组或问题列表，我将它们作为一个问题域进行研究，对这些问题进行抽象分析并解决它们。大概的概念。找出问题抽象的本质属性。

比如前面讲过解决性能问题的问题。

当你经常面临需要解决的业务系统性能问题时，你会发现需要学习JVM内存模型、内存泄漏检测方法、Linux进程和常用分析命令等工具。您还会发现影响性能的原因有很多，包括硬件资源、数据库、中间件、应用程序和数据量。

通过定期回顾，您将形成一个通用的性能问题分析和诊断模型。

而不是在遇到性能问题时立即重新启动服务器。

对于软件开发来说，也是经常强调学习一些主流开源软件的源码的原因。程序员要想成为架构师，就必须从软件开发的表象，到对内部原理和运行机制的研究，了解其中的缘由和缘由。

很多程序员每天都在做简单的 CRUD 增删改查功能的原因是一样的。大多数人不考虑事物的内部运作。

最简单的 CRUD 功能之一还涉及开发框架和基本类库。你能不能研究一下这些内容，了解一个软件功能的内部原理。同样，任何 CRUD 功能也都涉及到高可用和高性能，因此可以进一步研究相关的数据结构和算法。

多年前我担任项目经理时，出于同样的原因，我观察了团队中的开发人员。

一个大型的业务系统往往会分解成多个业务功能模块，但大多数人只熟悉自己的功能模块，对其他模块一无所知。而少数人往往会花时间自己去熟悉整个系统，熟悉自己负责的各个模块，了解各个模块之间的协同关系。

跳出框框往往不是技术问题，而是心理意识问题。

并不是所有的人都要求能够探索事物的内在原理和本质，但要想实现技能层次的转换，就必须由外向内，从场景到本质。

从穷尽一切到能够总结出一套适合自己的规律和方法论。

大型项目实践机会难得

如果我们谈论微服务架构框架，如果您首先熟悉Java软件开发。

那么你可能需要 1 到 2 周的时间来搭建一个开源的微服务开发框架，并在其中自测验证注册中心、网关、限流熔断、链路监控、安全等。

当然，你也可以将微服务框架应用到你目前正在开发的小产品上。

那么如果这样持续2到3年，你能算精通微服务架构吗？

显然不是。

最大的原因之一是当你的项目没有达到一定的规模，实际业务系统没有达到一定的用户数和并发数时，你在架构层面就不能遇到很多应用问题。

典型问题包括应用程序性能问题、复杂错误的快速定位和故障排除、安全问题以及应用程序本身的高可用性问题。通过理论学习，你很难完全掌握这些内容。

您可能已经阅读了很多关于高并发架构设计的书籍。连书上都会讲一些关键的经验点，但是你在实践中从来没有遇到过，不会引起共鸣。这些书中的经验总结不会因为当你阅读这本书时，它直接转化为你自己的内心体验。

理论学习不能转化为自己的经验，只能实践。

只有通过大项目的实践架构师，通过在实践过程中不断遇到和解决新问题，才能不断提升自己的技能和经验，最终转化为自己的体验模式。

如果没有大型项目实践，您实际上很难进行这种过渡。

如果没有大规模的项目实践，即使你把微服务技术原理的书都看完了架构师，也无法应用到实际项目中，最终会逐渐忘记。这些知识不会转化为你的内在体验模式。

所以当你有这么大的项目机会时，千万不要放手。如果你在一家公司多年没有这样的机会，你也可以考虑是否找一个新的工作机会锻炼一下。

我写过很多关于私有云PaaS平台、SOA架构设计、平台性能优化、SOA治理的文章。这些文章的总结来源于大型项目的实践。

通过大型项目的实践，您将有机会提高您的建筑设计能力。应该理解，架构设计过程本身就是一个迭代演进的过程。没有最优架构，只有最适合当前场景的架构。

以我们的 SOA 项目中运行实例日志存储的接口服务为例。从最初的数据库分表，到Solr全文构建，再到HBase的分布式存储库，是一个基于场景不断演进的过程。

架构设计不一定意味着你知道如何构建某个技术框架。这不能称为架构。

真正的架构是你在面对业务场景和问题域时，能够使用最好的技术方案解决问题的能力。

去做这个。

一句话概括就是模式应用能力，即当你面对不同的业务场景和问题领域时，用什么技术来解决最合适。你需要的是这种匹配能力。

真正的实践过程是不断提炼这种可复用的匹配能力。