从事软件开发十几年了，对于程序员的工作有一点自我的见解，首先程序员的工作属于一个技术活，技术类的工种需要时间的积累，但要达到某个领域的技术专家，首先是时间层面的积累，但仅仅是积累是不够的，不是达到多少年一定成为技术的专家，成为某个领域的佼佼者，时间只是其中一个因素。
牢固的基本功。要达到某种境界没有牢固的基本功做铺垫几乎是不可能的事情，程序员要说到基本功其实是一种很笼统的说法，基本功不仅仅是编程语言的语法，还包括常见的一些编程技巧，还包括一些基本的算法基础，不同的人对于基础的理解也不相同。对于初学者理解基础就是编程语言的语法，从心理上觉得编程语言的语法搞定了，但在真正意义上的编程的时候，只是掌握基本的语法是实际的编程经验需要在项目中提炼。
如果放在技术专家的要求来定义基本功又会是另外的一个境界，从心理上要认识无论哪个层次的程序员都要重视基本功的积累，在平时工作之余要拿出时间来温习基本功，按照一个标准的程序员的要求看认识基本功，常见的项目有编程语言的语法，项目操作过程中遇到的一个困难的总结汇总，数据结构基础算法，常见的编程场景处理能力，这些都属于编程基本范畴。
编程框架能力。这点就足够拉开了和普通程序员的区别，之所以能够在一个行业内成为头部的玩家，就需要具备一定的高层设计能力，这种能力不仅仅是简单的模块设计能力，还需要具备整个系统的设计开发能力，有些程序员做一辈子都未必真正设计搭建过一个框架，所以不能简单的认为能够设计好一个模块的框架就能把事情做得非常利索了，不能简单的认为。
其实框架能力在行业内讲就是造轮子的能力，当然不是每个人在自己的技术生涯中都有设计框架的机会，如果能够赶上一次也是不错的机会。
坚韧不拔的意志。这点主要是在精神层面的，不是每个人都能在一个领域长期坚持不懈的待下去的，能够数十年如一日坚持做好一件事都是对人毅力最大考验，能够一直坚持做这件事人数已经不多了，如果在加上做的出色的数量将会变得更少了，所以讲工匠精神不是每个人都能坚持做到最后的。
要想成为程序员里面某个领域的专家，不是仅仅靠时间来积累出来的，但时间的积累达到的一个典型的基础，不要觉得入行的时候自己的基础不好，但时间长了坚持的长了，常见的编程模式或者套路也都能掌握清楚了，不是谁天生就是某个项目的专家，什么事情就怕一个坚持的劲头，一股不服输的精神，坚持的时间长了在理论上还能缩减成为专家的次数，希望能帮到你。
评论0
加载中...
我是不太敢称自己为专家，对于一些软件、框架的掌握，我甚至都不敢说自己“精通”，最多也就是熟练掌握，倒不是因为我谦虚，一方面确实认为想要在一个领域达到专家的水平是非常有难度的，自认为达不到这个程度，另外一方面，就是觉得如果是软件、框架这个层次，不一定非要做到专家水平，设置可以说没必要做到专家的程度。
具体给一个时间长度没有意义，因为难易程度不同、每个人的基础不同、学习的背景和出发点不同：
我认为最快掌握一个框架，就是“被逼无奈”、“走投无路”的时候，为了解决项目上的某个棘手的问题，学习一个作为解决方案的框架或软件，这个过程是最快的；我曾经开发一个新项目，时间周期特别的紧，项目中需要使用 Kafka，从搭建、集成、使用，再到略加深入的研究，前后大概花了两周的时间；当然，也只能算作“熟练掌握”罢了；
在学习 Kafka 的过程中，因为之前我对 RabbitMQ 有一定的了解，所以学习起来会比较快，很多的时候我是在比较两者的不同，而如果对消息队列没有一点了解的程序员学习 Kafka，可能会花费更长的时间；
如果工作中没有特殊的要求，我学习一门框架的时间可能就长短不一了，可能几天、几周，甚至是几个月，而更多的时候，因为没有碰到过实际的问题，所以你很可能不会把每一个框架都做深入的研究。
跟其他的行业相比，软件行业的变化很快，技术更新的频率极高，比如医生可以始终在某一个非常小的领域进行研究，我就研究眼科，或者就一直做牙医，做一辈子，成为眼科的专家，但是程序员不行，你说我一辈子就研究 Spring 吧，将自己的技术积累押宝在当前某一个流行的软件或框架上，这个风险非常大；短期内可能会有成效，但是我们的职业寿命要四十年甚至更长。
有些程序员在某些大公司混的风生水起，非常熟悉公司的技术栈，但是当他换一个公司、换一个平台的时候，可能就会遇到发展的瓶颈；这是因为作为的“某一领域的专家”，只是依赖于当前公司这个平台，但不一定可以匹配市场的需求，错把平台资源当成自己的能力。
我十几年前刚成为 Java 程序员的时候，最流行的就要数 SSH 了，也就是 Spring 、Struts 和 Hibernate，现在再看看，Struts 几乎绝迹，Hibernate 半死不活，Spring 虽然很火，也是因为版本迭代的很快；
所以十年前我要是选择了一直研究 Spring 还好，要是选择押宝了 Struts ......
软件、框架的更新时很快的，我们不能把主要的精力放在它们身上。
在学习 Spring Cloud 、Dubbo 的时候，也要学习架构设计和演变；
在学习编程语言的时候，也要学习设计模式；
在学习通信框架的时候，也要把网络模型学习好；
学习 Angular、React、Vue 一堆框架，不如先把精力放在 HTML/CSS 上...
总之，基础打得牢，框架学的快，不要把百分百的精力都放在这些不断变化的框架上。
评论0
加载中...
边学边在项目中使用，半年已经足够了。不实际使用，可能十年也就了解的程度，所以，能动手就别bb，跑一跑什么知识都了解了。生产上出了问题，部门老总在你背后看着解决，几次你就成专家了。
评论0
加载中...
因人而异，如果有基础，数据结构+算法基础好，学习框架很快，1-3个月即可熟练运用，而如果缺乏基础可能得半年、一年。从我自身来讲学习某一框架需要学习1个月到1年不等，再实践3年，才可以说是非常熟悉，了然于胸了。
当然也看框架和软件本身的复杂度，越复杂自然学起来越难，同时框架跟某特定业务有关，如果你从事这个方向自然就容易熟悉。比如做Web要熟悉Spring全家桶、Nginx，做大数据熟悉Hadoop系列，做ai熟悉PyTorch或TensorFlow等。框架或软件是分领域的，如果所从事的非这个方向，往往学起来很费劲。但如果是同一方向，是手到擒来，轻松无比。
评论0
加载中...
每个人对专家都有不同的定义，我眼中的专家则偏向于能够看清楚当前领域方向，能引导未来设计的，这种才可以称为专家，专注点是可以设计和行业未来的人，甚至是根据paper设计出行业领先系统的人
大多数人的水平我感觉都不足以达到这个水平，大多数人的程度就是能够看懂源码和关键核心就可以成为大多数人眼中的小专家了，比如消息队列，你可以看懂kafka源码里面的关键设计比如怎么设计磁盘存储？利用操作系统特性？怎么设计高性能、高可用架构？怎么提高系统的吞吐？如何应对故障处理？这些其实就可以满足大家工作中80%的场景了
达到这个水平应该并不需要几年的时间，首先看下官方文档的核心特性介绍与使用，然后在自己的项目中去实践，最后去读一下核心流程的源码， 这个过程其实也并不是那么漫长，但是有一个问题，就是你到底能读懂多少？
从计算机底层开始说起(别说微机电路与CPU硬件那些)，最下层可能就是操作系统了，操作系统如何提供内存、IO、CPU、网络等资源的抽象，这里面有那些特性是我们可以借鉴的？然后就是linux内核的一些设计，再网上层就是各种数据结构和算法，然后就是各种模式，并发模式、设计模式、架构模式？再接着如果是分布式系统还有各种分布式、网络、共享等问题，最后特定领域往往还有专门的设计，这些基础你掌握的多少，直接回决定你读源码能够读懂多少，路漫漫何其远兮，但是你会发现这方面其实外面的机构基本不会讲，其实这些才是真正的核心，但是很少有人会修炼，祝你好运
评论0
加载中...
从这个问题的描述来看，显然是有一个前提的——程序员。
那么针对“程序员”这个称号，显然还应该再从两个方面来将问题分解。
一、初级程序员
作为一个刚刚入行不久的初级程序员，他自身可能对某一个编程语言的编程语法和 API 比较熟悉，但是对基于这门语言实现一些实际的项目和应用，可能还停留在瞎子摸象或者井底青蛙的层面（这里没有贬义，只是做一个比喻）。那么这种情况下，要研究某一个框架、软件，他就会缺少很多其他层面的知识、技能、经验的储备。比如你只是一个初级的前端开发者，刚刚熟练编写 HTML/CSS/JavaScirpt前端 Web，那么要研究 nginx、Node.js、Vue.js、Angular 4+、Flask 等等，可能前期就会显得比较吃力。因为这些软件、平台、框架里，包含了关于负载均衡调度、request/response、依赖注入、Component、Python装饰器、路由、重定向等基础知识。
那么要达到该领域的技术专家的水平，因为这位程序员可能平时还要上班，所以在保持勤奋的前提下，大约需要 3 个月左右的业余时间完整的学习有关的知识。
但是仅有这些还不够，还不能形成你的能力。另外还需要 2~3 个月的时间，好好利用新的框架去开发实现若干个项目，而且这些项目还不能太简单，必须要有一定的复杂度。
只有这样，你的开发经历才能更全面的覆盖到这个框架的更多的方面，才能称之为技术专家。
二、中高级程序员
这类人群已经在程序员领域有了一定的工作年限，也有了一定的开发经验。他们已经掌握了一些框架和软件等技术。那么他们面对新的框架和软件，会根据自己以往的经验和技术逻辑去领会新框架的原理。古语中对于一项技能有“道”与“术”的区别。那么这些中高级程序员对新框架的“道”的方面已经了然入心，因为这些新的框架其实与他们以前掌握的那些在逻辑架构和运行原理方面都是很相似的，他们需要学习的仅仅是原理上的不同，还有在编程语法、实现方式上的不同而已，那么这就是“术”的层面，而“术”是很容易掌握的，就好比是从模仿到掌握的过程。
评论0
加载中...
我在做开发的头三年的目标，是让自己成为垂直业务方面的开发熟手。
4-5 年，我让自己成为了专家，人家有问题了常常来问我，业务和架构上我也有自己的见底与把握。
6-8 年，梳理业务、做架构、带团队，总结和提炼技术能力与思想。
从开发生涯伊始，学习方法论、各种思想、最佳实践（包括看源代码），尝试一些新东西，这个阶段漫长而有弹性，不断实践与总结，行事方式固化为习惯，最大的收获就是开始做某一项事情时，心里有底，有思路有方向有方法，不会抓瞎，少走弯路。
学习代码的人和编写代码的人如果不在一个理解层面，阅读并不能帮到你什么，更不能说通过了解了代码的实现就成为了这个领域的专家。了解代码实现顶多只能应付面试问题，当别人问题为什么的时候，答案并不在代码实现当中。
阅读代码的精髓在于你完全了解了作者在领域中面临的问题，并在纷繁复杂的代码逻辑中抓出了作者解决这个问题的关键。自称熟读过的人，其实少有人能做到
这个收获很难用量化来衡量，但就像蓄水池，越蓄越多的感觉。
所以题主你提的三个“明白”，不是说不重要，但太死板，天天坐在那里看源代码看书是看不出什么来的，必须定好眼下要达标也可操作的 Flag，结合业务去追求跟实现，不断实践与总结。
天天看框架源码，即使你写出一个框架来，在业务实现方面你可能仍是 newbie；你就算花再多时间在编译器知识上，但是业务跟编译器毫无关联，你的编译器知识也不可能提升。
总之先考虑好第一步——定好眼下要达标也可操作的 Flag，结合业务去追求跟实现，不断实践与总结。想太多会提升焦虑感，虚无还没好处，目标定得太完美就是失败。
评论0
加载中...
框架就是别人给你制定的条条框框，学会了就像工厂的流水线上的操作工一样会干活了，不过换一个流水线你还得掌握另一些条条框框，专家、架构师就是给你制定条条框框的人。很多程序员以掌握某个架构然后自称架构师然后指点江山，指责其他不会某个架构的人，心中充满了伟大感，是不是很可笑；如同一个生产线上的操作工自称掌握了这条生产线。
评论0
加载中...
从来不觉得技术专家是研究哪个框架，那种设计语言就可以。①你需要多接触大项目，你才有可能理解什么叫“”业务需求不是你的技术需求”。②独立思维能力，能从复杂的业务场景中梳理出一定的逻辑顺序，预见一些别人想不到的业务场景，之后提交不同领域去讨论，这个过程中，你会体会什么叫“说人话”。③分水岭。如果你执着技术，你会发现，想做专家，你需要重新学习你大本时候最讨厌的一门课程，“高等数学”。如果你转向业务实现，你会发现，想做专家，你可能要不断深入现实中的业务场景，甚至扫垃圾这种最低级的工作，你都应该有切身的体验才可以。
评论0
加载中...
你说的专家不知是个什么概念，如果只是能够做到熟练运用，那不是太难，一个能力尚可的程序员一般都能一通百通，学习和精通一门语言、框架从几个月到二三年不等，但这绝对算不上专家，也就普通软件工程师水平。
要达到计算机领域的专家绝非易事，而且也不是精通某一框架或软件这么简单，至少得要在某一领域取得一定的技术成果，我觉得一般拥有正高职称的称之为专家应该不心虚，副高职称的免强也算。
绝大多数程序员有生之年都达不到专家水平，不是能力问题，而是为了生计不得已在技术层面停留太久，没机会钻研更深层次的东西。相反有些科研机构钻研某一技术时间长了能够成为这一领域的专家。
最后，真正的专家是没功夫长篇大论在我们上写问答的，写问答的都是闲着没事装B的。
评论0
加载中...10
回答0
回答0
回答0
回答0
回答0
回答1
回答0
回答10
回答3
回答
