你离大牛只差一个规划！程序员该如何实现个人成长？

在一家大的公司里，不同的人总会有不同的运气：

运气好的人遇上一个好的项目，升职加薪，从此就走上了人生的巅峰。

运气差的人摊上一个差的项目，升不了职，少加了薪，并且还获得不了技术成长。

记得刚毕业那会儿，所在团队的主要工作是，维护一个『又老又旧』的系统。比起写业务代码更不幸的是，我们的主要工作是修 Bug，bug，buG, bUg；

业务逻辑繁多、Bug层出不穷的情况下，程序员该如何实现个人成长？

观点：Bug改好了才能成长

回答者： +阿柱/wx 

十一年的技术生涯了, 也说两句吧. 

如果能你已经能把 写业务逻辑代码和改Bug 做好,  我可以很负责任的对你说: 你已经成长了,说不定还是个高手!  我这里说的"好" , 并不是你把策划或老板给你任务做完, 然后交给QA测试通过就好了.  

大道至简, 这里的好,简单来说就是:

第一: 你写的业务代码要达到好, 至少要: 准确, 稳定, 高效, 易读, 易扩展, 易维护; ... 

(做到这些, 你需要多少知识? 为了做好这些, 你会主动学习很多东西... 怎么说没有成长的机会呢? 机会是要自己创造的!)

第二: 你改bug要改得好,要做到: 改bug要用中医的治病态度和方法, 治未发之病, 尽量少治已发之病.  

(要做到治未发的bug, 就要有精益求精的态度, 如果每一次的codereview 你都能发现以前的不足或别人的不足 或 别人的优点, 那么恭喜你又进步了! )

其实你把第一条做好, 你已经很少bug了, 你再把第二条做好, 你...... 再也不会提出"如何成长"这么迷茫的问题了! 还可以多点时间陪陪家人. 

(当然这样做,可能会降低你在公司的知名度和重要性, 曾经在某公司经历过, 因为很多时候我在bug出现前, 都已经将它灭了, 所以老板很少见到我为bug而加班, 而另一部门的某位同学,却经常加班到很晚去改bug(他自己的bug), 老板认为他很重要,很敬业很典范, 对此我只能慈悲一笑了)   

附一个典故: 

魏文王问扁鹊曰：“子昆弟三人其孰最善为医？”扁鹊曰：“长兄最善，中兄次之，扁鹊最为下。”魏文侯曰：“可得闻邪？”扁鹊曰：“长兄於病视神，未有形而除之，故名不出於家。中兄治病，其在毫毛，故名不出於闾。若扁鹊者，鑱血脉，投毒药，副肌肤，闲而名出闻於诸侯。”魏文侯曰：“善。”

回答者： ruin.exe 

“维护一个『又老又旧』的系统，每天修复各种各样的bug”，这些“脏活”、“累活”看似枯燥无味，实际对于一位程序员来说不见得是一件坏事。

2014年我刚工作那会儿，开始也是维护一份很老的代码，每天都是改原来的老的代码，但是在这个阶段我通过不断总结别人写的代码的缺点，重构、优化不好的地方，技术迅速成长起来。另外，我对这些枯燥的维护工作没有反感，而是接受它把工作做好，我很快也得到了领导的赏识。马上被安排独立负责一些重要的工作。

如果你连维护工作都做不好，那么相信开发工作肯定也好不到哪儿去。任何工作只要你善于学习，你一定能够有很大的收获。多一份踏实，少一份浮躁，不断积累，或许能够取得更大的进步。

回答者：  天龙幻象

其实，区分一个程序员的能力，不是看是否能顺利写出代码，而是看能否应对各种BUG，解决BUG。

BUG往往千奇百怪而又无从避免，要处理一个BUG，往往要反复推敲代码，查阅各种资料，寻求各种帮助，找出各种可能。

在应对BUG时，头脑是最专注的，思考是最积极的，行动是最迅猛的，成长也是最快的。

BUG就象取经路上的九九八十一难，只有保持一颗上进的心，在不断挑战BUG中，不断成长，当将一个一个BUG踩于脚下的时候，自然就会功德圆满，圣光临身。

回答者：  人生如梦

1、基础很重要，不要觉得修改bug没与提升，解决bug是熟悉代码的过程，并且也是分析问题的过程，初期解决一些bug，中期可以做些issue分析，肯定会有提升。主要要端正态度，行行出状元。

2、其实我也被分配做过“烂项目”，但是不论是时间，人力，都不足的情况下，做出来的东西还得不到上线。但是既然公司决定做，肯定有做的目的，领导也会因为你没有把“烂项目”做烂，对你刮目相看，有可能比做优质项目更提早被发现。

3、如果你想在这个行业发展，业务代码是至关重要的，别人都不会的业务，你会，你说领导涨工资时候，为什么不想到你，难啃的骨头，啃的动啃不动，在于你是否接受这个任命。

4、中级学学设计模式，重构下以前的烂代码，未尝不是一件好事，优质团队，是不会给你重构的机会的，因为更高级的研发人员，早就做你做的这件事情了

说了这么多，态度决定一切，没错的。没有不好的项目，只有不动脑的开发

观点：量变可以引起质变

回答者： 金蛟剪 

刚毕业那会儿，干啥啥不会，写逻辑代码也能有巨大提升，当写够几万行十几万行业务代码之后，自己的源码阅读能力、程序设计能力、解决Bug的技巧都会有巨大的提升，有了强大的编程能力，那些所谓的有技术含量的东西绝大部分都可以在短时间内掌握。

写业务代码积累代码量，量变引起质变，所谓一力降十会，在积累了巨量的代码量之后，几乎任何所谓的有技术含量的东西都构不成挑战性。

回答者： 倔强得不服输 

我觉得初期的话，写写业务代码还是很有帮助的，当然你的工作不能仅仅局限于完成业务，更重要的是需要不断地对业务代码进行分析，不断优化。毕竟，业务是多变的。

随着业务的更迭，你的代码肯定是要调整的，这个时候，正是一个程序员思考代码设计的绝好时候。

然后量变引起质变，产生编程思维上的跨越。

回答者：Ares  

1.代码写的太松散，开始归类重构

2.目前功能实现不了，开始造轮子

3.造的轮子多了，开始优化框架

4.框架改的杂了，开始梳理体系

5.体系发现盲点了，开始看paper查资料学习

6.学习OK了~~LevelUp!

从量变到质变，保持学习态度

观点：先提高工作效率

回答者：  枫叶如澜

代码的量多后，你会思考如何用更少的代码完成之前相同的业务，这个是一种进步；

当随着业务不停发展，业务开始复杂后，思考如何将业务解耦、将代码如何模块化，这是一种进步；

随着bug的复现和增多，思考如何从一个或者两三个点去开始逐渐使用设计模式去重构部分功能模块，这也是一种进步；在新的业务场景中，大胆的引入新的技术，这也是一种进步。

但是这些进度都以你去自学和充电为基础的，没啥工作是强迫你去进步的，只有你自己的意识和行动。

回答者：魂の輪廻  

我觉得谈技能的提升应该先谈如何提高工作效率。

业务逻辑的开发如同堆砌，堆砌的速度的提高也是一种变相的提升。

编码过程中，主要面对的就是各个业务的实现及以前实现的各种业务的各种千奇百怪的BUG，一个业务的堆砌实际上并不会浪费很多时间，时间往往花在了解决各类BUG上，那么有效的减少BUG，是解决业务工作繁重的一个重要途径。当然了，让自己的代码没有BUG，这是刚入行的程序才会有的想法，BUG是肯定有的，能做的是把一些低级的BUG尽可能的杜绝掉，这就一定要做好单元测试。

单元测试在国内开发环境中是经常被忽略的一个环节，很多朋友会觉得我已经写好的一套业务逻辑，为啥我还要围绕着它再做单元测试，甚至一整套单元测试，这简直是一种极大地时间浪费。而后再去面对各种层面抛出的空指针之类的低级问题，打断手头的编码工作思路，切换到当初的业务思路上，如果这还是个陈年老业务，还要有一个代码的熟悉过程，熟悉起来之后才发现只是缺个空判断，抛开影响心情不说，修改后回到原来的工作思路上又是需要一段时间的，这期间就造成了很大的时间浪费，也消磨了精神。

有一个优秀的单元测试可以有效地改善这种情况，作为一个程序，应该在自己一有闲下来摸鱼的时间就应该来编写单元测试，防范于未然的同时，测试可以发现自己平时编程的陋习，提升编码质量，每当遇到因为测试不足导致的BUG出现，还可以更加准确地得知自己容易疏漏的关注点，提升编写单元测试技巧的同时，从代码层面规避被疏漏的问题。

单元测试的完善将有效的减少BUG的出现，BUG的减少将提高业务的堆砌速度，业务堆砌速度的上升将更加有利于提升开发者的开发效率和甚至精神状态，整个开发过程将变得更加健康，也就可能会有更多的时间用于学习提升。

观点：程序员不能只注重技术提升

回答者：  to+be+GUNDAM

对程序员最有价值的提升是个人技术提升。对公司最有价值的是员工的业务能力提升。

我觉得不管是技术型公司或非技术型公司，更加关注的往往是业务。因为技术要产生价值，往往要通过业务实现。这种情况就好比我们写代码的时候要隐藏具体实现，对外只暴露接口。而技术就是实现，业务就是接口。

许多程序员会有这样一种想法：“我提升技术实力，这样不管在哪一家公司，身价都不低。”
而事实是，现在许多公司招人都会加一个行业需求。比如，从事金融行业，从事互联网，从事旅游行业，就是没有哪家公司会要求从事编程技术行业。就因为技术实现业务，业务创造价值。如果你对业务不熟悉，你实现的业务真的有价值么？

所以程序员应当拥抱业务，而非一昧拒绝。只重技术这种行为在工作中本来就是一种严重偏科，注定与优秀越走越远。

回到问题中来，个人成长应该关系到个人对自己的定位和职业发展规划。如果当前的工作状况跟自己的定位和发展背道，势必影响个人成长。这种情况下，不要片面不要情绪化，先跟公司内相关负责人和上级领导沟通，沟通后再做决定，这才是聪明的正确的做法。

回答者： 平凡の草☆ 

程序员也分很多出路。

有的人在一个行业写10年业务逻辑代码，那他就是这个行业的大牛，

有的人在各行各业写10年不同项目代码，那他就是互联网界的大牛，

有的人喜欢精于钻研某一项技术，那他就是这个领域的专家，

有的人善于整体把握系统的架构，那他就是软件行业的专家，

只要你喜欢你的工作，你就会去主动的学习，成长。

观点：多花时间在设计上

回答者：梦里水乡  

重构，做好类图，交互图，时序图。过不了几年几就成为大牛了。。。

很多人一开始都不注重这些。当你真正开始这么做的时候，你会发现，大部分的时间是花在了设计上面，而不是写实现代码和修bug上面。

回答者： 恋恋风辰 

谈一谈我的经历吧，12年刚毕业时去做了QT为引擎的音乐软件，用的语言是C++，那会写出一个小功能就很有成就感，每天都积极的向主程领任务，做的也都是功能的活，做了很多功能积累了很多编程的技巧，vs调试技巧也越来越熟练，后来做功能的速度越来越快，慢慢的就有了厌倦感，总觉得做功能很容易，而且对底层的研究不到位，希望能做一些技术含量的活。

可是公司大部分的开发工作都是以业务为主，编程的框架和底层都是封装好的，没机会也没必要去修改。就这样，觉得一直做功能没什么长进，就换了一家公司，主要做游戏开发，来到公司后学了很多前端的知识，而这些也都是基于功能的api，我为了让自己的技术有长进，就尝试着读框架源码和修改一些底层的回调，制作一些小插件，就这样技术长进了很多。

过了两年，我又换了一家做游戏的公司，还是希望技术上能有更大的长进，刚开始去熟悉框架和游戏逻辑，做的和之前都差不多。由于我做功能做的多了，就有一些时间去琢磨框架底层，我抽时间去重构了一个简单的服务器框架，遇到很多问题，也去看了redis和libevent等通信框架的源码，了解了很多实际开发中没机会接触的知识。

其实我想说的是，技术的长进和工作有关系，但是关系不是很大，如果真的纠结于忙于业务，工作没挑战，大可以去了解公司业务框架底层的一些知识，这些业务是如何通信的，有没有可优化的点，如果自己实现这样一整套业务框架会怎样？当你着手做这些的时候就发现不懂得其实很多，我们往往以工作没有挑战作为离职的原因，其实，每到了一个新的公司，我们的工作还是以业务为主，频繁的换工作也只是增加了自己去熟悉不同公司的不同业务而已，所以，静下心来，仔细去琢磨公司这一整套的开发框架，从业务去思考框架为何这么设计，再从框架考虑现在的业务有哪些可改进的地方，如果有一天真的发现这样一整套流程都精通了，那也就不会纠结于工作没什么挑战了，因为你已经掌握了这个领域的大部分技巧。

观点：不同时期有不同的成长方式

回答者： 春夏秋冬 

简单说点：

1.新人期，要学会接受and进取；项目或公司领导毕竟大部分都是过来人，有很多的经历和经验，况且之所以是领导，定有过人之处，所以他们的安排一定有他们的考量。接到任务后，要用心思考前中后末的what and why，doing的过程就是how and leave up的过程。

这个过程可能是方方面面的，比如根据测试结果进行bug，比如部署、运维；如果业务场景多一点，也可以通过行业的视角去get more，比如与客户沟通交流的过程中可能就会发现某些需求的解决思路，然后抽时间代码验证your idea。几个月的时间，可能你就从一无所知的懵懂的小白状态，慢慢掌控项目中一到多个的模块，如此开发的过程中就会有许多的思路。否则只是按照coder来干的话，可能项目交付后你可能还对该项目或业务一知半解。 至于进取方面，一位工程师的成长绝不是简单的coder，因为代码的运行环境涉及方方面面，比如系统、网络、硬件，数据库，软件只是其中的一点。所以与其抗拒工作上的安排，不如积极主动虚心用心的干好工作，工作中有条件跟软件以外的领域接触开一下眼界和视野也是极好的。这个时期可能在一到两年，三年的话就比较老道了，呵呵。

2.拔高期。此时的你，已经对该行业或者该领域有了一定的认识，如果人际关系好的话，那么可能此时的你已经在工作的城市或环境中有了很多的朋友，无论是测试、安全、方案、管理、网络、硬件、客户群，还是你的技术及能力等等都有了一定的积累和阅历，那么接下来你就知道自己到底适合干什么，怎么干了。比如转型管理或销售，或者在代码之路走下去，或者专搞数据库，或者搞运维，其实真正的运维是很牛叉的（技术全面，经验丰富，比如近两年比较火的dev-ops，但这只是其中之一吧。

技术总监可能是你的目标，因为你不止懂开发）当然，也有一部分继续coder下去的，那么软件架构师可能是你的奋斗目标；如果此时的你还在天天写业务逻辑改bug，那么你真的该思考why了———在软件行业，有一句经典：三分技术，七分管理。如果你的项目总是出bug，绝对是管理的问题！因为有的公司可能对项目的业务真的接触不多，如果是这样，为什么不外包呢？如果是本身架构的问题，那么为什么不重构呢？当然，也不排除有的管理层的理念：只要程序能跑起来，能够从客户手中拿到money，谁管那么多啊！况且现在硬件的性价比稳定兼容等都特别好了，为什么不做好时间空间代码的交换呢？而且，现在各种软件产品基本都是成型的，但更多的还是各种调   

至于老系统，除了看money，我只能呵呵了。。。

这个时间段，可能是从第3年到。。。很久

（底层研发的暂不讨论）

3.大拿期。可能更多的是设计、管理和应酬

 戳这里，看更多观点，还可参与话题讨论噢~