怎么成技术大牛

Ⅰ 非科班出身，如何学好编程成为技术大牛

首先确定自己的位置： 一、菜鸟 第1 层楼属于地板层，迈进这层楼的门槛是很低的。基本上懂计算机的基本操作，了解计算 机专业的一些基础知识，掌握一门基本的编程语言如C/C++，或者Java，或者JavaScript，...， 均可入门迈进这层。 二、大虾 从...

Ⅱ 怎么样成为编程技术大牛

编程技术是指利用计算机实现某种目的或解决技术问题，使用一些编程语言编写程序代码，最终得到结果。那么怎么样才能成为变成技术大牛呢？

学习你所说的并不是你需要知道的，不是读一本书和掌握它。使用数据在构造算法方面，至少有5 ~ 10本书在这方面;在软件设计方面，光理解结构设计和方向。设计和设计模式是不够的，还需要理解软件架构设计、交互设计、面向方面的设计和方向。设计的设计、数据结构算法的设计、情感设计等，否则很难进入大牛这一楼层的。

主要还是多接触，多看书，多编码，多自己动脑子解决问题，多帮助别人，积累经验。

Ⅲ 学习java，C++，大数据我们如何成为技术大牛

仅供参考：
0段—非程序员：
初学编程者，遇到问题，完全是懵懵懂懂，不知道该怎么编程解决问题。也就是说，还是门外汉，还不能称之为“程序员”。计算机在他面前还是一个神秘的黑匣子。

1段—基础程序员：
学习过一段时间编程后，接到任务，可以编写程序完成任务。
编写出来的代码，正常情况下是能够工作的，但在实际运行中，碰到一些特殊条件就会出现各类BUG。也就是说，具备了开发Demo软件的能力，但开发的软件真正交付给客户使用，恐怕会被客户骂死。
程序员程序是写好了，但到底为什么它有时能正常工作，有时又不行，程序员自己也不知道。
运行中遇到了bug，或者需求改变，需要修改代码或者添加代码，很快程序就变得结构混乱，代码膨胀，bug丛生。很快，就连最初的开发者自己也不愿意接手维护这个程序了。

2段—数据结构：
经过一段时间的编程实践后，程序员会认识到“数据结构+算法=程序”这一古训的含义。他们会使用算法来解决问题。进而，他们会认识到，算法本质上是依附于数据结构的，好的数据结构一旦设计出来，那么好的算法也会应运而生。
设计错误的数据结构，不可能生长出好的算法。
记得某一位外国先贤曾经说过：“给我看你的数据结构！”

3段—面向对象：
再之后，程序员就会领略面向对象程序设计的强大威力。大多数现代编程语言都是支持面向对象的。但并不是说，你使用面向对象编程语言编程，你用上了类，甚至继承了类，你就是在写面向对象的代码了。
我曾经见过很多用Java,Python,Ruby写的面向过程的代码。
只有你掌握了接口，掌握了多态，掌握了类和类，对象和对象之间的关系，你才真正掌握了面向对象编程技术。
就算你用的是传统的不支持面向对象的编程语言，只要你心中有“对象”，你依然可以开发出面向对象的程序。
如，我用C语言编程的时候，会有意识的使用面向对象的技巧来编写和设计程序。用struct来模拟类，把同一类概念的函数放在一起模拟类。如果你怀疑用C语言是否能编写出面向对象的代码，你可以看一下Linux内核，它是用C语言编写的，但你也可以看到它的源代码字里行间散发出的浓浓的“对象”的味道。

真正掌握面向对象编程技术并不容易。

在我的技术生涯中，有两个坎让我最感头疼。
一个坎是Dos向Windows开发的变迁过程中，框架的概念，很长一段时间我都理解不了。Dos时代，都是对函数库的调用，你的程序主动调用函数。Windows时代，则换成了框架。就算是你的main程序，其实也是被框架调用的。UI线程会从操作系统获取消息，然后发送给你的程序来处理。Java程序员熟悉的Spring框架，也是这样一个反向调用的框架。
现在因为“框架”这个术语显得很高大上，因此很多“类库”/“函数库”都自称为“框架”。在我看来这都是名称的滥用。
“类库”/“函数库”就是我写的代码调用它们。
“框架”就是我注册回调函数到框架，框架来调用我写的函数。

另一个坎就是面向对象。很长一段时间我都不知道应该怎么设计类和类之间的关系，不能很好的设计出类层次结构来。
我记得当时看到一本外国大牛的书，他讲了一个很简单、很实用的面向对象设计技巧：“叙述问题。然后把其中的名词找出来，用来构建类。把其中的动词找出来，用来构建类的方法”。虽然这个技巧挺管用的，但也太草根了点，没有理论依据，也不严谨。如果问题叙述的不好，那么获得的类系统就会是有问题的。

掌握面向对象思想的途径应该有很多种，我是从关系数据库中获得了灵感来理解和掌握面向对象设计思想的。
在我看来，关系数据库的表，其实就是一个类，每一行记录就是一个类的实例，也就是对象。表之间的关系，就是类之间的关系。O-Rmapping技术（如Hibernate），用于从面向对象代码到数据库表之间的映射，这也说明了类和表确实是逻辑上等价的。
既然数据库设计和类设计是等价的，那么要设计面向对象系统，只需要使用关系数据库的设计技巧即可。
关系数据库表结构设计是很简单的：
1，识别表和表之间的关系，也就是类和类之间的关系。是一对一，一对多，多对一，还是多对多。这就是类之间的关系。
2，识别表的字段。一个对象当然有无数多的属性（如，人：身高，体重，性别，年龄，姓名，身份证号，驾驶证号，银行卡号，护照号，港澳通行证号，工号，病史，婚史etc），我们写程序需要记录的只是我们关心的属性。这些关心的属性，就是表的字段，也就是类的属性。“弱水三千，我取一瓢饮”！

4段—设计模式：
曾经在网上看到这样一句话：“没有十万行代码量，就不要跟我谈什么设计模式”。深以为然。
记得第一次看Gof的设计模式那本书的时候，发现虽然以前并不知道设计模式，但在实际编程过程中，其实还是自觉使用了一些设计模式。设计模式是编程的客观规律，不是谁发明的，而是一些早期的资深程序员首先发现的。
不用设计模式，你也可以写出满足需求的程序来。但是，一旦后续需求变化，那么你的程序没有足够的柔韧性，将难以为继。而真实的程序，交付客户后，一定会有进一步的需求反馈。而后续版本的开发，也一定会增加需求。这是程序员无法回避的现实。

写UI程序，不论是Web,Desktop,Mobile,Game，一定要使用MVC设计模式。否则你的程序面对后续变化的UI需求，将无以为继。

设计模式，最重要的思想就是解耦，通过接口来解耦。这样，如果将来需求变化，那么只需要提供一个新的实现类即可。
主要的设计模式，其实都是面向对象的。因此，可以认为设计模式是面向对象的高级阶段。只有掌握了设计模式，才能认为是真正彻底掌握了面向对象设计技巧。

我学习一门新语言时（包括非面向对象语言，如函数式编程语言），总是会在了解了其语法后，看一下各类设计模式在这门语言中是如何实现的。这也是学习编程语言的一个窍门。

5段--语言专家：
经过一段时间的编程实践，程序员对某一种常用的编程语言已经相当精通了。有些人还成了“语言律师”，擅长向其他程序员讲解语言的用法和各种坑。
这一阶段的程序员，常常是自己所用语言的忠实信徒，常在社区和论坛上和其他语言的使用者争论哪一种语言是最好的编程语言。他们认为自己所用的语言是世界上最好的编程语言，没有之一。他们认为，自己所用的编程语言适用于所有场景。他们眼中，只有锤子，因此会把所有任务都当成是钉子。

6段--多语言专家：
这一个阶段的程序员，因为工作关系，或者纯粹是因为对技术的兴趣，已经学习和掌握了好几种编程语言。已经领略了不同编程语言不同的设计思路，对每种语言的长处和短处有了更多的了解。
他们现在认为，编程语言并不是最重要的，编程语言不过是基本功而已。
他们现在会根据不同的任务需求，或者不同的资源来选择不同的编程语言来解决问题，不再会因为没有使用某一种喜爱的编程语言开发而埋怨。

Ⅳ 技术大牛是如何炼成的

• 如果回答对楼主有帮助，给个采纳好不，谢谢啦

• 破仑说：不想当将军的士兵，不是好士兵。无论你在做开发、测试、运维，你都是一个技术人员，而我相信，每个技术人员的心中，都有一个成为技术大牛的目标，这个目标鞭策着每一位有梦想的人，去努力和改进自己。 梦想总是在现实面前有过一度的彷徨，因为你会发现，真正的工作和心中的理想状态天壤之别，不是一码事。当你面对的是，天天加班写业务代码，每天都有执行不完的测试，扛机器接网线敲shell命令，你也许会怀疑，这是我想要的人生吗？接下来，就让我们带着疑惑，去寻找答案！三大误区误区一：拜团队技术大牛为师，给你开小灶首先，不可否认，大牛的确有能力将你锻炼培养成另一位大牛，但是，无论是单独给你开小灶，还是培训整个团队，时间成本消耗过大，因此，一般没有大牛愿意这样做。其次，很多人都认为不懂就问是个好习惯，但是你忽略了很多问题大牛是不屑回答的，比如像“jvm的-Xmn参数如何配置”这种上网能找到答案的问题，只会浪费他人以及自己的时间。最后，大牛是个极具小众的群体，因此，直接请教和辅导的机会非常少，即使有幸参加过几次真正大牛的培训，也不太可能让你嫣然一变，成为技术大牛的。总而言之一句话，以自己为主，系统且有针对性的进行学习；然后再以请教学习为辅提升自己。误区二：不断重复，停滞不前首先，要认清一个事实，写不好业务代码和只把业务代码写好的程序员，在技术大牛的世界里，没有什么本质的不同。如果光是沉浸在一个基础技术里积累学习，那么毫无疑问，这是你的惯性和惰性在束缚着你前进，打破它，不断向更大的挑战迈进，最终成为他人眼中的大牛。误区三：大环境的不公与碎片化时间首先，大多数人都在抱怨中国的环境对于自己可能性的扼杀，并认为很多本来能成为大牛的人才被现实埋没，不可否认，这个理由具有一定的客观性，因为环境的确可以改变一类人的发展和命运。但是，如果我们转过身来自问，是否自己真的已经倾尽全力？我相信，总是存在一些人，借着社会不公的理由，给予自己偷懒的借口；毕竟，大牛还是会有的，万一就是你呢？其次，如果你抱怨现如今社会的碎片化时间，不能有整段时间提供自己深入学习，那么，是否先改变自己的一个观念，那就是碎片化时间也可以深入学习。而未来，利用碎片化时间学习将可能成为一种趋势。正确的做法1、尽量多的尝试当你每次都做得更多，随着时间的发展，将会是这样，产品讨论需求找你、测试有问题也找你、老大对外支撑也找你，于是，你就成了这个系统的“专家”了。要想有机会，那就得与众不同，努力做到更多。怎么做得更多呢？可以从以下几个方面着手：1）熟悉不止你负责的更多业务，熟悉不止你写的更多代码。好处：需求分析的时候更加准确，能够在需求阶段就识别风险、影响、难点问题处理的时候更加快速，因为相关的业务和代码都熟悉，能够快速地判断问题可能的原因并进行排查处理方案设计的时候考虑更加周全，由于有对全局业务的理解，能够设计出更好的方案2）熟悉端到端比如说你负责web后台开发，但实际上用户发起一个http请求，要经过很多中间步骤才到你的服务器（例如浏览器缓存、DNS、nginx等），服务器一般又会经过很多处理才到你写的那部分代码（路由、权限等）这整个流程中的很多系统或者步骤，绝大部分人是不可能去参与写代码的，但掌握了这些知识对你的综合水平有很大作用，例如方案设计、线上故障处理这些更加有含金量的技术工作都需要综合技术水平。3）自学一般在比较成熟的团队，由于框架或者组件已经进行了大量的封装，写业务代码所用到的技术确实也比较少，但我们要明白“唯一不变的只有变化”，框架有 可能要改进，组件可能要替换，或者你换了一家公司，新公司既没有组件也没有框架，要你从头开始来做。这些都是机会，也是挑战，而机会和挑战只会分配给有准备的人。以java为例，大部分业务代码就是if-else加个数据库操作，但我们完全可以自己学些更多java的知识，例如垃圾回收，调优，网络编程等，这些可能暂时没用，但真要用的时候，不是google一下就可以了，这个时候谁已经掌握了相关知识和技能，机会就是谁的。2、尽量做到更好世界上没有完美的东西，你负责的系统和业务，总有不合理和可以改进的地方，识别这些“不合理”和“可改进”的地方，并且给出解决方案，然后向主管提出，一次不行两次，多提几次，机会，就是自己去争取和把握。例如：重复代码太多，是否可以引入设计模式？系统性能一般，可否进行优化？目前是单机，如果做成双机是否更好？版本开发质量不高，是否引入高效的单元测试和集成测试方案？目前的系统太庞大，是否可以通过重构和解耦改为3个系统？阿里中间件有一些系统感觉我们也可以用，是否可以引入 ？3、尽量动手实践光看不用效果差例如：学习了jvm的垃圾回收，但是线上比较少出现FGC导致的卡顿问题，就算出现了，恢复业务也是第一位的，不太可能线上出现问题然后让每个同学都去练一下手，那怎么去实践这些jvm的知识和技能呢？Netty我也看了，也了解了Reactor的原理，但是我不可能参与Netty开发，怎么去让自己真正掌握Reactor异步模式呢？看了《高性能MySQL》，但是线上的数据库都是DBA管理的，测试环境的数据库感觉又是随便配置的，我怎么去验证这些技术呢？框架封装了DAL层，数据库的访问我们都不需要操心，我们怎么去了解分库分表实现？怎么办？1）系统化的学习这个是第一阶段，看书、google、看视频、看别人的博客都可以，但要注意一点是“系统化”，特别是一些基础性的东西，例如JVM原理、Java 编程、网络编程，HTTP协议等等，这些基础技术不能只通过google或者博客学习，一般做法是先完整地看完一本书，有了全面的了解，然后再通过google、视频、博客去有针对性地查找一些有疑问的地方，或者一些技巧。2）自己动手丰衣足食这个步骤就是解答上文提到的疑惑，也就是自己去尝试搭建一些模拟环境，自己写一些测试程序。例如：Jvm垃圾回收：可以自己写一个简单的测试程序，分配内存不释放，然后调整各种jvm启动参数，再运行的过程中使用jstack、jstat等命令查看jvm的堆内存分布和垃圾回收情况。这样的程序写起来很简单，简单一点的就几行，复杂一点的也就几十行。Reactor原理：自己真正去尝试写一个Reactor模式的Demo，不要以为这个很难，最简单的Reactor模式代码量（包括注释）不超过200行（可以参考Doug Lee的PPT）。自己写完后，再去看看netty怎么做，一对比理解就更加深刻了。MySQL：既然有线上的配置可以参考，那可以直接让DBA将线上配置发给我们（注意去掉敏感信息），直接学习；然后自己搭建一个MySQL环境，用线上的配置启动；要知道很多同学用了很多年MySQL，但是连个简单的MySQL环境都搭不起来。框架封装了DAL层：可以自己用JDBC尝试去写一个分库分表的简单实现，然后与框架的实现进行对比，看看差异在哪里。用浏览器的工具查看HTTP缓存实现，看看不同种类的网站，不同类型的资源，具体是如何控制缓存的；也可以自己用Python写一个简单的HTTP服务器，模拟返回各种HTTP Headers来观察浏览器的反应。3）交流分享，发现自己的不足之处。与人交流分享，既需要我们将一个知识点进行系统化的梳理，并且考虑各种细节，这会促使我们进一步思考和学习。同时，听的人可以有不同的理解，或者有新的补充，这就令知识技能体系变得更加完善。后记无论结果怎样，当我们谈论过程的艰难与乐趣之时，是否可以不去计较自己是否付出太多？因为一个真正热爱技术的人，只会勇往直前，不忘初衷，坚持到底！