3000字告诉你如何渡过程序员菜鸟时期

周末闲来无事，和大家随便聊聊。本来想写的题目是如何成为一个优秀的程序员，后来想想，我自己也未必能算得上。所以还是谦虚一点，就把题目改了。

我这次不写那些方法论或者是感受的东西，这些可能大家get不到，也未必喜欢。这次写一点实际的，只要照着做，基本上不会被认为是个菜鸟，在职场当中也不会踩雷。

相信小习惯的力量

菜鸟和大牛的区别除了写代码、debug的核心能力差距之外，另外一个很大的差别就是在习惯上。大牛经过摸爬滚打练出了一系列优良的习惯，而菜鸟好习惯还没养成，坏习惯有了一堆。所以身为菜鸟的时候一定要有规范和习惯意识，养成好习惯，去掉坏习惯让自己越来越习惯写出优质的代码。

关于习惯仁者见仁，每个人也都有自己的习惯。我简单提几个，给大家抛砖引玉。

一个函数只做一件事

如果有一天你接手了另外一个同事的代码，发现他有一个函数里面装了三千行代码，你会是什么感受？

这是我亲身的经历，我当时看到代码的第一反应就是把这个人揪出来暴打一顿。代码和其他文本信息不同，越拥挤可读性越差。优质的代码和优质的文章很像，结构清晰、层次分明、表达准确。一个函数里面装几千行代码显然是老太太的裹脚布——又臭又长。

对于一个函数里究竟应该写多少代码，每个人有不同的理解。实际上我们也没必要硬扣，遵守一个简单的原则即可——一个函数只做一件事。举个简单的例子，假设我们要从上游读一批数据，然后画出某一个函数作用之后的结果。我们简单分析一下，表面上是画图这一件事情，但是这一件事情当中其实包含了好几个步骤，比如说从上游获取数据，获得函数作用的结果，最后才是画图。那么我们完全可以拆分成三个函数，一个函数获取数据，一个函数获取结果，一个函数画图。

这样别人以及以后的自己看这段代码就会非常清楚，每个函数做了什么一目了然。假如有一天老板无意间翻了大家的代码，别人的代码一个函数里装了几千行，你的代码层次分明，每个函数做什么都一目了然，你说老板会怎么想？

起长一点的变量名

新手一个很大的问题就是总喜欢起很短的变量名，像是a,b,c,d。或者是什么bd,aa什么的，看起来非常难看，可读性也很差。之前有几个同学找我帮他们看代码，给的都是这种代码，看起来感觉眼睛都被针扎了……

吐槽归吐槽，老实说我在之前打acm的时候也是喜欢短变量名，虽然不至于这么夸张，但一般一个变量名也不会很长。当然这是由于当时比赛的需要，大家争分夺秒，别人一个变量名叫btn，你叫binary_tree_node，很显然拼敲代码的速度你一定输。

但问题是后来毕业了之后我也一直保留这样的风格，不出意外地遭到了老板和同事的毒打。大家都表示不喜欢我这样的代码风格，我当时还坚持，觉得是自己代码能力的体现。后来去读了一下一些大牛的代码，尝试换了一种风格之后，发现真香了。虽然写起来的时候麻烦了一点（其实也还好，现在有各种代码补全功能），但是读起来是真的很舒服，思路也清楚了很多。所以如果你现在的代码不是这种风格的话，请一定尝试改一下，对自己对其他人都好。

另外一点是我们起名的时候可以是不规范的英文，哪怕不太准确也没问题，但一定一定不要用拼音。

拼音阅读起来比半通不通的英文还要费劲，而且用拼音做变量或者是函数名是一件非常非常low的事情，绝对会让对方对你的能力产生怀疑。市面上也有一些帮助起名的插件，有这方面需求的同学请务必去了解一下。

遵守代码规范

在新手的意识里可能没有代码规范这个词，但是这个确实是从新手走向进阶的必经之路。

不同的语言的规范是不同的，比如说Java和go当中流行驼峰命名法，所有变量都是驼峰的。而Python可能只有类名是驼峰的，普通变量和包名倾向于全小写用下划线分割。当然代码规范并不仅仅是命名规范而已，还有很多很多的规范。比如中间件的使用规范、多线程的开发规范、数据库的使用规范等等。

为什么我们要遵守这些规范？因为我们的开发工作并不是实现功能就完事了，以后还需要拓展和维护。遵守规范不仅可以不给以后的自己以及他人埋雷，更重要的是可以让自己的代码质量更高，更加专业。而且一些规范当中往往是藏着道理的，为什么套接字、线程以及数据库连接都需要维护一个“池”？这里面肯定是有门道的，不然为什么大家不怎么简单怎么来？我们在遵守这些规范的时候也能便于我们更好地理解各个场景当中的原理以及细节，这也是技术实力的一部分。

当然我们一开始未必能做得很好，但代码规范并不是很困难的事情，从我们有这个意识到做到遵守规范并不需要很多时间，但是带来的收益却是非常丰厚的。之前在前公司，有听说过过因为代码风格太差被老板给了差绩效的事情，我觉得挺冤枉的，可能就是一时疏忽给老板留下了差印象，如果当时写代码的时候能注意一点，完全可以避免，代码有些太大了。

会用不等于懂了

如果你是应届生，那么当你毕业进入职场，你必然会面临一个适应的问题。别的我们不提，单单只说技术方面。我们势必需要快速学习一些我们之前没有见过或者是不了解的技术，来应付工作当中的任务以及挑战。

这个是非常正常的，我想绝大多数程序员在刚毕业的时候都经历过，我自己也不例外。刚毕业的几个月是最辛苦的，我们需要承担很大的压力，对于转变之后的生活也不是完全适应。但当几个月过去，我们适应了生活，学会了一些基本的技能可以应付或者说胜任当下的工作之后，一个潜在的陷阱就到来了。

有一些人会不知不觉地停止学习，因为他已经足够应付工作了。在工作当中他会有一种在这个领域我当下会的技能已经足够了的错觉，有些人甚至会因此觉得其他资历更深的同事也不过如此，似乎并没有比自己多会多少东西。我当初就是这样，因为我发现我工作当中用到的东西玩的非常溜，用起来得心应手。我一度有些膨胀，觉得自己已经算是一个经验丰富的程序员了。直到后来有一次面试，被问到了一个常用的工具的技术细节，我张口结舌一句话也说不上来，我才发现，自己知道的只是皮毛而已，甚至连皮毛都算不上。

当然我们工作当中对很多技术的要求都只是会用，你会用就够了，这并没有问题。我也并不觉得每一门我们用到的技术都需要去刨根究底，但我们需要对我们的实力有清醒的认识，哪些是勉强会用的？哪些是真正了解掌握的？哪些是需要掌握但是只是勉强会用的？

能够想明白这些问题可以让我们保持一个清醒的头脑，对自己的当下的处境以及长远的发展目标都会有一个清楚的认识。

积累知识而不仅是经验

新手或者是小白有一个特点就是往往更加依赖经验而不是知识，举个例子吧。比如新手后端经常遇到的问题之一就是maven package失败，很多人解冲突的办法就是mvn clean & mvn install。也就是清空重新建立，因为大部分情况下这个命令可以解决问题。所以很多新手就记住了这个命令，每次遇到maven失败就这么来一次。

如果这个命令解决不了呢？这些人可能会换个命令试试。如果常用的解决问题的命令都试过了还是不行呢？这些人可能就僵住了，觉得这个问题解决不了了，得请大牛来看了。

这里的核心问题是新手积累的是经验而不是知识，他们只是简单机械地把出现的问题和解决方法做映射而已，并不是从原理和核心层面理解问题出现以及解决方案生效的原因。那么带来的结果就是，积累到的只是经验，下次能解决问题不是因为学会了问题的解决方法，也不是理解了这一块技术内容，只是单纯地记住了而已。这显然也是一种伪成长。

其实我之前也遇到过这样的问题，虽然我每次都有意识遇到问题记录下解决的办法，这样下次就可以不用请教别人了。然而虽然我记录的问题越来越多，但是每次遇到新的问题还是解决不了，需要请教别人。直到有一天，被我问的大牛露出了不耐烦的神情，才让我下定决心自己学会解决问题。

于是我不再是头痛医头脚痛医脚地解决问题，而是去学习了一下问题背后的原理和机制，再从报错日志上分析错误产生的原因，思考解决方案，最终彻底学会了解决这一类问题的方法。之后不但能够自己独立解决问题，而且还可以去帮助别人了。我后来回过头来想想，如果我第一次遇到问题的时候就自己尝试去学习其中的机制，而不只是记住解决方法，应该可以做得更好。

少说废话，多写代码

著名的Linux之父Linus有一句名言：talk is cheap show me the code。翻译过来就是废话少说，代码拿来。我觉得这句话非常符合这一行的精髓，我们不是靠嘴皮子吃饭的，而是靠实实在在的产出，这个产出最终是要落实到代码上的。作为一个新人，可能我们会有这样的问题，那样的困惑。然而这许多的问题和困惑我们光想是没用的，只能用硬实力来解决。

著名的C语言作者谭浩强也有一句名言：新手学编程最应该做的事情就是写满一万行可以运行的代码，之后你就自然入门了。道理其实也是一样的，少说废话，多做实事。多做多练，实力自然不会差。空想吹逼是成不了大牛的。所以如果你犹豫想要学习一门新的领域，但是不知道从何做起的时候，不妨想想这句话，别管它三七二十一，先搞起来写起代码来再说。搞着搞着，你自然就明白后面应该怎么做了。

以上就是我自己积累的一些思考和想法，如果你是一个小白的话，希望它能够帮助你顺利度过新手期，向着大牛的目标进发。

衷心祝愿大家每天都有所收获。如果还喜欢今天的内容的话，请来一个三连支持吧~（点赞、在看、转发）