合浦仔林哥
从来不觉得技术专家是研究哪个框架，那种设计语言就可以。①你需要多接触大项目，你才有可能理解什么叫“”业务需求不是你的技术需求”。②独立思维能力，能从复杂的业务场景中梳理出一定的逻辑顺序，预见一些别人想不到的业务场景，之后提交不同领域去讨论，这个过程中，你会体会什么叫“说人话”。③分水岭。如果你执着技术，你会发现，想做专家，你需要重新学习你大本时候最讨厌的一门课程，“高等数学”。如果你转向业务实现，你会发现，想做专家，你可能要不断深入现实中的业务场景，甚至扫垃圾这种最低级的工作，你都应该有切身的体验才可以。
Echo1980
我在做开发的头三年的目标，是让自己成为垂直业务方面的开发熟手。
4-5 年，我让自己成为了专家，人家有问题了常常来问我，业务和架构上我也有自己的见底与把握。
6-8 年，梳理业务、做架构、带团队，总结和提炼技术能力与思想。
从开发生涯伊始，学习方法论、各种思想、最佳实践（包括看源代码），尝试一些新东西，这个阶段漫长而有弹性，不断实践与总结，行事方式固化为习惯，最大的收获就是开始做某一项事情时，心里有底，有思路有方向有方法，不会抓瞎，少走弯路。
学习代码的人和编写代码的人如果不在一个理解层面，阅读并不能帮到你什么，更不能说通过了解了代码的实现就成为了这个领域的专家。了解代码实现顶多只能应付面试问题，当别人问题为什么的时候，答案并不在代码实现当中。
阅读代码的精髓在于你完全了解了作者在领域中面临的问题，并在纷繁复杂的代码逻辑中抓出了作者解决这个问题的关键。自称熟读过的人，其实少有人能做到
这个收获很难用量化来衡量，但就像蓄水池，越蓄越多的感觉。
所以题主你提的三个“明白”，不是说不重要，但太死板，天天坐在那里看源代码看书是看不出什么来的，必须定好眼下要达标也可操作的 Flag，结合业务去追求跟实现，不断实践与总结。
天天看框架源码，即使你写出一个框架来，在业务实现方面你可能仍是 newbie；你就算花再多时间在编译器知识上，但是业务跟编译器毫无关联，你的编译器知识也不可能提升。
总之先考虑好第一步——定好眼下要达标也可操作的 Flag，结合业务去追求跟实现，不断实践与总结。想太多会提升焦虑感，虚无还没好处，目标定得太完美就是失败。
木子羽辰
从这个问题的描述来看，显然是有一个前提的——程序员。
那么针对“程序员”这个称号，显然还应该再从两个方面来将问题分解。
一、初级程序员
作为一个刚刚入行不久的初级程序员，他自身可能对某一个编程语言的编程语法和 API 比较熟悉，但是对基于这门语言实现一些实际的项目和应用，可能还停留在瞎子摸象或者井底青蛙的层面（这里没有贬义，只是做一个比喻）。那么这种情况下，要研究某一个框架、软件，他就会缺少很多其他层面的知识、技能、经验的储备。比如你只是一个初级的前端开发者，刚刚熟练编写 HTML/CSS/JavaScirpt前端 Web，那么要研究 nginx、Node.js、Vue.js、Angular 4+、Flask 等等，可能前期就会显得比较吃力。因为这些软件、平台、框架里，包含了关于负载均衡调度、request/response、依赖注入、Component、Python装饰器、路由、重定向等基础知识。
那么要达到该领域的技术专家的水平，因为这位程序员可能平时还要上班，所以在保持勤奋的前提下，大约需要 3 个月左右的业余时间完整的学习有关的知识。
但是仅有这些还不够，还不能形成你的能力。另外还需要 2~3 个月的时间，好好利用新的框架去开发实现若干个项目，而且这些项目还不能太简单，必须要有一定的复杂度。
只有这样，你的开发经历才能更全面的覆盖到这个框架的更多的方面，才能称之为技术专家。
二、中高级程序员
这类人群已经在程序员领域有了一定的工作年限，也有了一定的开发经验。他们已经掌握了一些框架和软件等技术。那么他们面对新的框架和软件，会根据自己以往的经验和技术逻辑去领会新框架的原理。古语中对于一项技能有“道”与“术”的区别。那么这些中高级程序员对新框架的“道”的方面已经了然入心，因为这些新的框架其实与他们以前掌握的那些在逻辑架构和运行原理方面都是很相似的，他们需要学习的仅仅是原理上的不同，还有在编程语法、实现方式上的不同而已，那么这就是“术”的层面，而“术”是很容易掌握的，就好比是从模仿到掌握的过程。
野生动物Frank
从事软件开发十几年了，对于程序员的工作有一点自我的见解，首先程序员的工作属于一个技术活，技术类的工种需要时间的积累，但要达到某个领域的技术专家，首先是时间层面的积累，但仅仅是积累是不够的，不是达到多少年一定成为技术的专家，成为某个领域的佼佼者，时间只是其中一个因素。
如何成为某个技术领域的专家？
牢固的基本功。要达到某种境界没有牢固的基本功做铺垫几乎是不可能的事情，程序员要说到基本功其实是一种很笼统的说法，基本功不仅仅是编程语言的语法，还包括常见的一些编程技巧，还包括一些基本的算法基础，不同的人对于基础的理解也不相同。对于初学者理解基础就是编程语言的语法，从心理上觉得编程语言的语法搞定了，但在真正意义上的编程的时候，只是掌握基本的语法是实际的编程经验需要在项目中提炼。
如果放在技术专家的要求来定义基本功又会是另外的一个境界，从心理上要认识无论哪个层次的程序员都要重视基本功的积累，在平时工作之余要拿出时间来温习基本功，按照一个标准的程序员的要求看认识基本功，常见的项目有编程语言的语法，项目操作过程中遇到的一个困难的总结汇总，数据结构基础算法，常见的编程场景处理能力，这些都属于编程基本范畴。
编程框架能力。这点就足够拉开了和普通程序员的区别，之所以能够在一个行业内成为头部的玩家，就需要具备一定的高层设计能力，这种能力不仅仅是简单的模块设计能力，还需要具备整个系统的设计开发能力，有些程序员做一辈子都未必真正设计搭建过一个框架，所以不能简单的认为能够设计好一个模块的框架就能把事情做得非常利索了，不能简单的认为。
其实框架能力在行业内讲就是造轮子的能力，当然不是每个人在自己的技术生涯中都有设计框架的机会，如果能够赶上一次也是不错的机会。
坚韧不拔的意志。这点主要是在精神层面的，不是每个人都能在一个领域长期坚持不懈的待下去的，能够数十年如一日坚持做好一件事都是对人毅力最大考验，能够一直坚持做这件事人数已经不多了，如果在加上做的出色的数量将会变得更少了，所以讲工匠精神不是每个人都能坚持做到最后的。
要想成为程序员里面某个领域的专家，不是仅仅靠时间来积累出来的，但时间的积累达到的一个典型的基础，不要觉得入行的时候自己的基础不好，但时间长了坚持的长了，常见的编程模式或者套路也都能掌握清楚了，不是谁天生就是某个项目的专家，什么事情就怕一个坚持的劲头，一股不服输的精神，坚持的时间长了在理论上还能缩减成为专家的次数，希望能帮到你。
大学生编程指南
这个问题，我想起一个博士的话，一门模式的编程语言，一个月我就入完门了。现在只谈我自己的情况，应该就一个月左右的时间，说不上达到专家级，超越70%人应该是可以的，够用了。如果我想学新知识，先买书，再看入门博客知识点，动手实验实验，找人交流交流。作为程序员，写的代码要符合设计模式，程序写给CPU看，更重要的是写给未来的自己、同行看，大家的技术才能一起上一层楼。
积问累识
边学边在项目中使用，半年已经足够了。不实际使用，可能十年也就了解的程度，所以，能动手就别bb，跑一跑什么知识都了解了。生产上出了问题，部门老总在你背后看着解决，几次你就成专家了。
暖宝宝爸
根据通常的1万小时定律，一般要成为某个行业里的专家，需要在这行业里工作1万个小时。但是软件行业不一样，他是一个迭代更新非常快的行业。特别是系统架构。要是你研究一个系统框架1万个小时，那么这个框架说不定已经过时了。
学习某一个技术框架，成为这个框架的专家水平。我觉得因人而异。有些技术基础扎实的人，或者本身就是其他技术架构的专家，那么他学习一个新框架，估计1,2个月就差不多了。如果是一个有潜力的小白，那么我个人认为要成为该领域的专家，至少需要2-3年的潜心研究。还要通过项目的实践才能成为技术专家水平。当然如果你只是拿着框架在使用，不潜心研读他的底层代码，那么你至多能成为一个熟练的老手，很难成为专家。这是个人的浅见，欢迎批评指正
沪皖新世界
因人而异，如果有基础，数据结构+算法基础好，学习框架很快，1-3个月即可熟练运用，而如果缺乏基础可能得半年、一年。从我自身来讲学习某一框架需要学习1个月到1年不等，再实践3年，才可以说是非常熟悉，了然于胸了。
当然也看框架和软件本身的复杂度，越复杂自然学起来越难，同时框架跟某特定业务有关，如果你从事这个方向自然就容易熟悉。比如做Web要熟悉Spring全家桶、Nginx，做大数据熟悉Hadoop系列，做ai熟悉PyTorch或TensorFlow等。框架或软件是分领域的，如果所从事的非这个方向，往往学起来很费劲。但如果是同一方向，是手到擒来，轻松无比。
刀法如飞
框架就是别人给你制定的条条框框，学会了就像工厂的流水线上的操作工一样会干活了，不过换一个流水线你还得掌握另一些条条框框，专家、架构师就是给你制定条条框框的人。很多程序员以掌握某个架构然后自称架构师然后指点江山，指责其他不会某个架构的人，心中充满了伟大感，是不是很可笑；如同一个生产线上的操作工自称掌握了这条生产线。
大司马剑平
如果是已经有编程经验的话，学习能框架，特别快！！
看你每天花多少时间！
比如每天你花三个小时到四个小时左右，你大概一个月，就能掌握一门比较成熟的框架！
假如说你每天花半个小时到一个小时，你可能得2到3个月，甚至四个月，才能熟练的掌握一门框架，并利用它来开发！
如果是有有3到5年工作经验的朋友，他学习一门新的语言，或者新的框架可能1到2个星期，基本上就能应用了！
