天天写业务代码的程序员，怎么成为技术大牛，开始写技术代码？ 第1页

一个产品业务的开发过程中必然存在很多需要解决的问题，比如 崩溃，死锁，性能低下，延迟高，服务器不稳定，数据丢失，某些功能不知道怎么实现。

产品业务如果要成功，这些问题必须要解决，至少解决其中绝大部分。

谁解决这些问题谁就是大牛，你想去写业务逻辑公司也舍不得。

遇到这种问题直接退缩或者推给别人，就写一辈子业务逻辑吧。

问题就是机会，你主动去解决问题，你没搞定别人也没搞定啊，万一搞定了就是你牛逼，多划算的买卖啊。

以我多年解决问题的经验来看，其实大多问题并不难，只需要认真去google下跟踪调试进源代码深处就能解决，这种问题其实就是谁敢上谁就行。很多人不去解决，就是因为懒和怂。问题解决多了，就会越来越有感觉，别人也就更倾向把疑难杂症交给你。所以一个组里只有一两个人能成长起来，因为只要有一个人成长了其它人就失去了机会，并不是这一两个人比其他人优秀很多，只是他们是第一个敢于主动迎难而上的人。

要不怎么说，性格决定命运呢。

2016.10.08更新：更加完整的回答请看我的专栏文章，补充了一个点：Do exercise

===================以下是原答案=================================

粗略的扫了一下前面的答案，有几个典型的答案我觉得有必要反驳一下：

1）拜大牛为师 -- 你想得美

看起来很美好，实际上想拜大牛为师的多了去了，大牛凭什么看中你呀；而且一个公司或者部门的大牛本来就不多，你正好和大牛在一个组的几率是很小的；如果都不在同一个组，你根本都没有机会接触大牛，更别说深入请教和学习了；

如果是组内的小牛，一般都是骨干核心，本来工作也很忙，你天天问一些在他看来比较低级的问题，别人也烦呀。像我这种乐于助人好为人师的，可遇不可求 ：）

2016.09.26补充：不是说不要向比你厉害的人学习和请教，而是说不要问书本或者google能够查到的东西；

2）业务代码一样很牛逼 -- 很傻

这样的答主我估计没有怎么真正参与业务开发吧？ 实际上在公司里面，业务代码真的没太多技术含量，就是实现产品功能即可，而且翻来覆去就那么一些，写多了真的会很烦躁的。

3）业务代码写多了能力就上去了 -- 很天真

这也是误人子弟的，写一万行hello world，水平不可能提升的；redis也就3万行代码规模，几个人能写出redis ？你写10万行业务代码都写不出redis的。

4）上班太忙没时间自己学习 -- 你想多了

嗯，这是中国国情，难道你还指望每天上班给2小时给你自我提升 ？

我讲讲我是怎么混出来的。

最重要的是明确一个道理：靠自己！在你水平不高的时候，不要想着人脉、关系这些，不要被那些乱七八糟的励志书忽悠了。否则你会发现热脸贴冷屁股，要不就是浪费钱请人吃了饭而已。

要靠自己去学习提升，没有时间就挤出时间，将打游戏、睡懒觉、看电影的时间挤出来；

要靠自己去争取机会，不要等着机会砸到你头上。你说自己天天完成业务代码就OK了，从来不分享、从来不提优化建议、别人讨论nginx你连nginx是啥都不知道、有任务能推就推。。。。。。然后等着哪天主管突然给你安排一个有技术含量的事情？这是不可能的。

要考自己主动去探索，不管是熟悉更多业务，还是熟悉更多代码，还是了解整体架构，都需要自己主动去做。不要指望谁告诉你这里是重点，那里是难点，还有关键点在哪里。

总结一句话：只有你自己牛逼了，机会才会到你头上！

前面讲了大道理，接下来讲我的实际方法，不多，就两条。

【Do more】

做的更多，做的比你主管安排给你的任务更多。

我在华为的时候，负责一个版本的开发，这个版本的工作量大约是2000行左右，但是我除了做完这个功能，还将关联的功能全部掌握清楚了，代码（大约10000行）也全部看了一遍，做完这个版本后，我对这个版本相关的整套业务全部很熟悉了。经过一两次会议后，大家发现我对这块掌握最熟了，接下来就有趣了：产品讨论需求找我、测试有问题也找我、老大对外支撑也找我；后来，不是我负责的功能他们也找我，即使我当时不知道，我也会看代码或者找文档帮他们回答。。。。。。最后我就成了我这个系统的“专家”了。虽然这个时候我还是做业务的，还是写业务代码，但是我已经对整个业务都很熟悉了。

以上只是一个简单的例子，其实就是想说：要想有机会，首先你得从人群中冒出来，要想冒出来，你就必须做到与众不同，要做到与众不同，你就要做得更多！

怎么做得更多呢？可以从以下几个方面着手：

1）熟悉更多业务，不管是不是你负责的

2）熟悉更多代码，不管是不是你写的

3）熟悉端到端

比如说你负责web后台开发，但实际上用户发起一个http请求，要经过很多中间步骤才到你的服务器（例如浏览器缓存、DNS、nginx等），服务器一般又会有很多处理才到你写的那部分代码（路由、权限等）这整个流程中的很多系统绝大部分人是不可能去参与写代码的，但掌握了这些知识对你的综合水平有很大作用，例如方案设计、线上故障处理这些更加有含金量的技术工作都需要综合技术水平。

4）自学

写业务代码所用到的技术比较少，我们可以自己学习更多，说不定哪天就用上了。

以java为例，大部分业务代码就是if-else加个数据库操作，但我们完全可以自己学些更多java的知识，例如垃圾回收，调优，网络编程等，这些可能暂时没用，但真要用的时候，不是google一下就可以了，这个时候谁已经掌握了相关知识和技能，机会就是谁的。

以垃圾回收为例，我自己平时就抽时间学习了这些知识，学了1年都没用上，但后来用上了几次，每次都解决了卡死的大问题。

【Do better】

要知道这个世界上没有完美的东西，你负责的系统和业务，总有不合理和可以改进的地方，识别出来，并且给出解决方案，然后向主管提出，一次不行两次，多提几次，只要有一次机会，你就有机会了。

例如：

重复代码太多，是否可以引入设计模式？

系统性能一般，可否进行优化？

目前是单机，如果做成双机是否更好？

版本开发质量不高，是否引入高效的单元测试和集成测试方案？

。。。。。。。。。。。。。。。。。。。

只要你去想，其实总能发现可以改进的地方的；如果你觉得系统哪里都没有改进的地方，那就说明你的水平还不够，可以多学习相关技术，多看看业界其它公司怎么做，BAT都怎么做。

我2013年调配到九游，刚开始接手了一个简单的后台系统，每天就是配合前台做数据增删改查，看起来完全没意思，是吧？如果只做这些确实没意思，但我们接手后做了很多事情：

解耦，将一个后台拆分为2个后台，提升可扩展性和稳定性；

双机，将单机改为双机系统，提高可靠性；

优化，将原来一个耗时5小时的接口优化为耗时5分钟。。。。。。

后来我们这个组承担了更多的系统，现在这个小组5个人，负责了6个系统。

归纳总结一句话：靠自己、做更多、做更好！

记住：不是因为给你安排高水平的工作你才有机会提升水平，而是因为你水平高了才有机会给你安排高水平工作！

==================2016.01.17补充======================

特别申明一下：我说业务代码没有“太多”技术含量，并不是说“完全”没有技术含量，理解问题千万不要走极端。有个网友说写了半年业务代码就觉得没意思了，我觉得这就有点急躁了。即使是业务代码，也还是有一定技术含量的，以java编程为例，static、final、synchronize、HashMap、try-catch-finally等语言基本特性，这些在业务代码开发中还是比较常见的，很多人也经常用，但大部分人都没有深入去研究这些语言特性的原理和作用，只是一知半解的使用，所以经常会看到代码中乱用、滥用、随便用的现象。

===================2016.09.28补充======================

成为技术大牛就像游戏中打怪升级一样，要不断的打更高级别的怪物才能不断升级。这个过程中，业务代码只是比较初级的怪物，业务代码都写不好，肯定不能成为技术大牛；但只是把业务代码写好了，一样成为不了大牛！就像游戏时小怪都打不死，直接去打BOSS是不可能的；但一直只是打小怪，即使能够秒杀小怪，离打大BOSS还差得远

技术代码都是偷摸干的。不然码农天天加班干嘛，真以为写业务代码呢，还不是天天折腾技术。说是加班写代码，其实是在加班玩”游戏“。 什么MVC, MVVM, Design Pattern, 面向对象，函数式编程， 还不都是打着省时间提高效率的名义编出来的。 明明写个页面就好的东西，非要分层啊分模型啊。

上面的话都是在黑，小朋友不要认真往心里去。