架构师和程序员的区别-架构师和程序员哪个好 收藏 0

为什么大部分程序员都无法成为架构师？努力背后的真相

大家是否思考过，为什么大部分程序员很难真正成为一个架构师？

他们很多也是好的大学，计算机科班专业毕业，计算机基础知识技能没有任何问题，工作也足够的努力，但是仍然很多人无法真正成为一个合格的架构师。

从学徒到工匠，从工匠到大师，难的往往就是层层跃迁的质变点。而真正影响这个质变点的，仍然是你个人独立解决问题的能力，思维能力的培养。

我前面经常会举对汽车观察认知的例子。即使大部分人实际并不会去关心汽车内部结构和汽车的运行机理，只需要知道汽车的外部组成，知道如何让汽车动起来就足够了。

这个有没有错？

说实话，这个在大部分场景下并没有发生过。

人的精力是有限的，你不可能对所有的新事物，新问题都去刨根究底，搞清事物内在本质。但是回到你自己的专业领域就不一样的。

当面对你自己的专业领域的时候，一定要从浪漫派转变为古典派，要去挖掘事物内在本质和运作机理。只有这样你才可能抽象普适性的规律，在后续新问题解决中去应用。

当你深入问题内部的时候，自然将专业知识的广度转变为了知识的深度。

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

一个人能够解决复杂问题，往往仅仅是因为自己见过，而不是因为本身具备了问题分析和匹配的能力。

对于这类人当面临一个全新的领域，全新的问题的时候往往无从下手。

因为没有掌握一种在自己专业领域普适性的问题分析和解决方法。

拿企业的业务流程来说，这些流程千变万化，但是当流程分解后你会发现，所有的流程都是由底层的200到300个原子业务活动组装出来的。对于某一类技术问题同样道理，虽然你面对问题都不相同，但是分解后都是共性的原子能力。

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

• 问题的定义，目标的分解
• 你已有的原子能力储备
• 利用原子能力去匹配并向上整合解决问题

你会发现问题分解并没太多难度，真正的难点是在你原子可复用能力的储备，其二是这些能力究竟应该如何组合。

如何提升这个能力呢？

其一就是每当你解决一个新问题后，你会通过复盘去思考，解决这个问题的方法中应该拆分哪些可复用的经验点。

其二是养成周期性深度复盘的习惯，即定期的会回顾是否出现过类似的场景或问题，这些问题群或问题列表，我会作为一个问题域来研究，去抽象这类问题分析解决的通用思路。找寻问题抽象后的本质属性。

比如我前面谈到过性能问题的解决问题。

当你经常面对业务系统性能问题需要解决的时候，你会发现类似JVM内存模型，查找内存泄漏方法工具，Linux进程和常用分析命令等都需要学习。你也会发现影响到性能了包括了硬件资源，数据库，中间件，应用程序，数据量诸多原因。

通过周期性复盘你才会形成一个通用的性能问题分析和诊断模型。

而不是一遇到性能问题就去重启服务器。

对于软件开发来说，为何经常会强调去研究和学习一些主流开源软件的源代码，也是同样的道理。程序员要走向架构师，一定要从软件开发表象走向内在原理和运作机制的研究，知其然并知其所以然。

很多程序员为何每天都在做简单的CRUD增删改查功能，原因也是相同的。大部分人并不去思考事物的内在运行本质。

一个最简单的CRUD功能也涉及到开发框架和基础类库，那么能否对这些内容进行研究，了解一个软件功能实现出来的内部原理。同样，任何一个CRUD功能也涉及到高可用和高性能，那么能否对相关的数据结构和算法进一步研究等。

在多年前我当项目经理的时候，对团队里面的开发人员进行观察，也是同样的道理。

一个大的业务系统往往分解为了多个业务功能模块，但是大部分人往往只熟悉自己的功能模块，对其它模块一无所知。而少量的人往往是自己花时间去熟悉整个系统，熟悉自己主管的各个模块，并去了解各个模块之间的协同关系。

跳出盒子很多时候不是技术问题，而是思维意识问题。

不要要求所有的人都能够探求事物内在原理和本质，但是如果你要实现技能阶层跃迁，那么必须从外走向内，从现场到本质。

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

如果我们说微服务架构框架，你如果原来本身就对Java软件开发熟悉。

那么你可能花1到2周的时间就能够采用开源的SpringCloud搭建好微服务开发框架，并对里面的注册中心，网关，限流熔断，链路监控，安全等都进行自我测试和验证。

当然你也可以将微服务框架应用到你当前开发的小产品中。

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

显然不能。

其最大的一个原因就是当你的项目没有达到一定规模，实际的业务系统没有达到一定的用户数和并发量的时候，很多架构层面的应用问题你根本就无法遇到。

典型的包括了应用性能问题，复杂Bug的快速定位排查，安全问题，应用本身的高可用问题等。这些内容实际你很难通过理论学习完全掌握。

海量高并发架构设计的书你可能看了很多，即使书里面也会讲到一些关键经验点，但是你原来没有实践遇到过，你并不会产生共鸣，这些书里面的经验总结并不会因为你阅读了书籍就直接转换为了你自己的内在经验。

理论的学习无法转变为你自己的经验，唯有实践。

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

没有大项目实践，实际你很难完成这种转变。

没有大项目实践，即使你把所有的微服务技术原理的书全部看了，但是无法在实际项目中应用，最终仍然会逐步遗忘，这些知识并不会转变为你内在经验模式。

所以当你有这种大项目机会的时候一定不要放过，如果在一个企业多年也没有这种机会你也可以考虑是否找 一个新的工作机会去锻炼。

我在前面写过很多私有云PaaS平台，SOA架构设计，平台性能优化，SOA治理方面的文章，这些文章总结本身即来源于大项目实践。

通过大项目实践，你才有机会提升你这块的架构设计能力。要明白架构设计过程本身也是一个迭代演进的过程，没有最优的架构，只有面对当前场景最适用的架构。

就拿我们SOA项目一个接口服务运行实例日志存储。从最开始的数据库分表，再到Solr全文建设，再到转到HBase的分布式存储库，本身就是基于场景不断演进的过程。

架构设计一定不是你懂搭建某个技术框架，这不能叫架构。

真正的架构是你面对业务场景和问题领域的时候采用最佳技术方案去解决问题的能力。

要做到这点。

• 其一是要熟悉你所在的业务场景和业务流程。
• 其二是能够将技术能力匹配到业务上。

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

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

程序员和架构师的区别在哪？如何快速分辨？

​什么样的水平称得上高级工程师，什么样的水平只能称得上普通工程师？为什么大部分人停留在普通工程师的级别？

“我会做十道凉菜、三十道热菜。”这是哪种级别工程师的自我介绍？

平常我们最喜欢做的事情，哪些价值更高？哪些毫无价值？

如题，初级程序员和架构师的差别在哪里？工作年限？经验？老板重视程度？是否做出重大业绩？下面和千锋广州小编一起来看看吧！

首先，工作年限长的技术就一定更加高深么？

不见得！

这个世界上不知道有多少人，每天只是做着重复性的工作，毫无长进。虽说吃过的盐比其他人吃过的饭都多，但就是没记性，不断的重复着过去的错误。甚至伴随着年龄的增长、激情的磨损，反倒一年不如一年。

其次，工作经验，盖过100个房子的一定就比只盖过10个房子的更有经验么？

不见得！

有些人只需要盖过一个房子，就会对房子的地基、门窗、水暖管道、强弱电走线、等等了如指掌。而有些人，盖了一辈子的房子，连插头左右哪个是火线哪个是零线都分不清楚。

至于老板重视程度，这是结果，而非原因。技术高深，自然就受到重视；而不是相反的：受到了重视，所以技术才变得高深。

是否做出重大业绩，这确实是一个足够客观的衡量指标，但依然只是结果。更何况，如果是一群人共同做出的业绩，如何区分大家彼此之间的技术高低呢？

那么，普通工程师和高级工程师，差别到底在哪里呢？

什么样的水平称得上高级工程师，什么样的水平只能称得上普通工程师？什么样的人一看就知道是高级工程师，什么样的人一看就知道最多是普通工程师？

-初级Java程序员与门外汉的区别-

初级Java程序员面对技术任务，至少是知道从何处入手的。

比如说修汽车，门外汉连空气滤清器在哪里都不知道，更不要说如何拆卸，如何安装了。

计算机软件专业的毕业生，至少明白做一个手机上的软件是需要安装编译环境的，一个门外汉对于几行代码变出来的游戏界面感到颇为神奇。

但是作为一个软件工程师，我真的很好奇一大堆黄豆是如何变成液体豆汁而后突然变成固体豆腐的。

所以，初级程序员对自己所从事的行业，至少是有大概的了解的，甚至具有一定的工作经验，可以在高级别同伴的带领下完成最为基本的操作。

-初级程序员与普通程序员的区别-

初级程序员刚刚入门，能够在师傅的指导下完成最最基本的流程化操作。但是由于熟练程度不足，完成任务的速度和质量无法保证；稍有遇到自己没做过，或者不熟悉的技术问题，都需要花费更多的时间学习。

在一个行业内做过许多事情之后（也可以是一个大事情内部的许多细分小事情），对各种技术问题都有接触，并都有成功解决的经历。于是，大部分的技术问题不再陌生，甚至非常熟练。自然而然，成长为普通程序员。

两者最典型的区别有：

1、行业相关的众多技术点，是否都有了解；

2、行业相关的众多细分工作，是否都有“熟练”操作过，完成的质量是否有足够保证；

3、行业相关的不同任务，能否给出明确的工期预测；

-普通程序员与高级程序员的区别-

大部分人会停留在普通程序员的状态，因为伴随着大家对自身工作内容的逐步熟悉，伴随着大家日复一日重复同样操作的逐渐熟练，这些知识和技能足以满足通常的工作需要。

很少有人会考虑：

1、更快（效率）：目前的操作流程是否是最快的？如何改进？

2、更好（效果或性能）：目前的解决方案是否是最佳的？能否进一步提升性能？

3、更省（成本）：什么样的方式能够降低人力成本、财物成本？

会做炸鸡的厨师很多——初级；

努努力做出口感好的炸鸡，也不是太难，只要肯卖力练习就行——普通级；

尽心专研，做出超级口感的炸鸡，真的需要好好专研、总结的——更好；

像肯德基那样，让入门级的厨师甚至门外汉都能够做出口感好的炸鸡，则需要对炸鸡的油温、时间等等做出仔细的研究，然后制作出对应的设备、操作流程。这是对一个行业的彻底颠覆。这样的级别，就不仅仅是高级了，而是专家级别。

-如何最快速的成长-

如何最快速的从初级到高级？区别明确了，问题就好办了！

1、争取做自己不熟悉、不会做的；——不熟悉的熟悉了，不会做的会做了，自然就成长了；

2、多做自己不熟练的、有难度的；——不熟练的熟练了，有难度的变得轻松了，自然就进步了；

3、习以为常的操作，多考虑一下是否能够换个方式做得更快、更好、更省；（自己琢磨也好，参考业内高手也行）

4、可以的话，思考一下如何让门外汉或初级员工更方便的做这个事情；

5、尝试解决那些大家都解决不了的甚至被认为根本不可能解决的问题。

从初级到普通级别，勤学苦练足矣；

从普通级别到高级，则需要多动动脑子，多思考，多对比，多总结，多摸索。

越是有难度的问题，越是没人能够解决的问题，越是从来没有人考虑过的问题，价值越高！

-如何面试考察对方的级别-

1、你做过这个事情么？（或者：简历里你印象最深刻的事情是哪个？）

2、做的过程中遇到过什么问题？

3、你是如何解决这些遇到的问题（或者其它一些奇葩的问题）的？

4、类似的事情重新让你做的话，大概需要多久？

5、你们做过的这些工作，都有哪些地方可以继续改善提升的？

6、业内的通常做法是怎样的？为什么？有没有更好的方案？

初级程序员的自我介绍是这样的：我会做十道凉菜、三十道热菜；

普通程序员的自我介绍是这样的：我一小时能做二十道菜；

高级程序员的自我介绍是这样的：打从我来到饭店后，客人更多了，赚钱更多了；

架构师的自我介绍是这样的：你听过这道菜么？是我第一个搞出来的。

千锋广州小编相信大家看完以上的总结你会对程序员和架构师的差别有一个清晰的了解，大家要有一个意识，就是要奔着架构师的目标去，才能更好的提升自己！

本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com