每个程序员都要历经从菜鸡到大牛过程蜕变胡过程。当初大家起点都差不多，工作多年后，有些人依然停留在菜鸡，有些人却已成为大牛，所有的事情，都是一点一滴习惯养成。让我们看看菜鸡程序员是如何写代码的？有可能找到你当初的影子，甚至是现在的影子。
命名很随意，当时写代码特别High，什么奇奇怪怪的命名都有的：xiaonaigou,xxxx,j1,jl,llst.完全意识不到全名规范的价值和意义。
日志？
那是什么鬼东西，能吃么？
曾经有一个从文思海辉出来的小伙伴，三年后端工程师经验，出了问题不知道怎么解决。只好重启。找我来协助，问他，怎么错了？ 不知道。 日志呢？ 没有。
晕，那怎么解决问题，神仙也搞不定啊。
后来才知道，他们解决问题都是本地改代码然后直接部署，重新访问看错误消失没，没有消失就继续在本地改源码。
一个菜鸡不可怕，可怕的是菜鸡遇到菜鸡。曾经有一个项目中的两个菜鸡，一个前端一个后端，他们很欢快的调接口，根本不写文档 ，两个人效率特别高。直到有一天，发现项目可能做不完了，需要另外两个前端菜鸡协助一下。新来的两个菜鸡要获取后端的数据，不知道接口的Url地址，不知道Get还是Post，不知道发送的参数和返回值。就这样写！我压根没想到可以这么写代码，两个菜鸡很开心！拍手称快：通了，通了，通了！我说你们通什么呢？他们说接口终于通了！原来他们两个参考之间的页面，硬生生的一次一次不停的尝试，就这样把接口猜出来了！这就是编程的乐趣吗？ 还有不写假数据。曾经有一个马姓小哥，对赵姓小哥信誓旦旦的说：3天，给我3天时间 ，我把真数据给你。于是赵姓小哥信以为真。就这样，3天又3天，3天又3天，3天又3天，3天又3天，3天又3天。整整一个半月，赵姓小哥都没有拿到全部的数据！
确切来说，是不按TDD的方式开发。在现在IDE这么强大的情况下，先写单元测试的习惯，不仅仅是代码的严谨性，也是效率的代名词啊。可是很多菜鸡理解不了单元测试的价值，没关系，等到代码重构，需求变更的时候，就哭都哭不出来了！好的单元测试，你的逻辑必然会清楚。
很多时候，菜鸡在引入第三方的库，框架，接口或者是服务的时候，最喜欢的事情就是直接和自己原有的代码集成在一起。结果 是什么呢？突然间不能用了，跑不起来了，不知道问题出在哪了，根本分不清倒底是第三方的问题还是自己的问题。 好的方法是什么？先跑通官方提供的Demo，再想办法一点一点加上自己的业务。
前端在这里的问题特别多，做支付，不清楚支付的流程，分不清楚定义，总以为前端就是接口处理好数据展示好拉倒。很多菜鸡都会有这种习惯，这样不好，先把逻辑处理好，弄清楚流程，再去动手才好。
不做方案代表什么含义呢？就是完全凭直觉行走啊。
跟闭上眼逛窑子一样。写代码的好习惯应该是先在脑袋里把所有的需求细节过一遍，实现细节拿出来。上个月就有一个张姓小菜鸡，做一个匿名评论的功能。基本上没有什么经验，脑子也不好使，给出的方式是什么你们猜得到么？用户刷新一次就往用户表里插入一条数据，密码默认昵称随机。不多说了都是泪，我见过太多让人目瞪狗呆的方案了，看着满屏的代码，你怎么帮他调错调优，最好的方式就是全部重写。做方案的好处太多了。
不关注性能也是新人很容易犯的错。什么是性能呢。对后端来说就是TPS和响应时间，对前端来说就是响应时间。很多新人程序员的习惯就是把东西做出来，然后再优化。最后就是东西做出来了，优化留给别人了。对性能的关注也是晋升中级程序员最关键的技能点。在写代码的时候，有经验的工程师已经知道了这个方法这个函数这个功能点的性能怎么样，瓶颈在哪里。
“程序员最大的勇气就是看自己三个月之前写的代码。”其实重构并不应该是在几个月之后重构，最好的方式是实时重构。写一天代码，70%的时间都放到重构上都不过份。而新人呢，磕磕跘跘的完成一个功能，就跟多米诺骨牌做成的大黄蜂一样，你敢动一下他的代码试试？他会跟你拼命。你让他自己动一行代码试试？不重构在某种程度上也意味着你的代码实现无法重塑。
有个词叫做最佳实践，其实编码规范和最佳实践，是编程功底的重要体现。优雅方案可以认为是最佳实践的升级版，它和上面说到的不断的重构是相辅相成的。不好的方案是什么呢？硬编码居多，没有可扩展性，用很丑陋的方式完成了功能。上次他们去做了一个关于试听课的方案，一个人能试听多少节课，正常的逻辑应该是在用户的表里加一个字段来表示。需求是写着邀请几个人，可以试听多少节课，所以他们判断试听多少节课就直接在通过邀请人的表里查询去做。完全没考虑到以后如果我变换了试听课的判断条件怎么办？实际上这是应该拆解成两部分，一个是试听课的产生条件，这是一个独立的模块，加一个是试听课的确认。像这种例子太多了，也和不做方案，不考虑扩展性有关系。就是接下来要说的。
工程师的水准，其实可以分成以下几个阶段：
面向功能编程
面向性能编程
面向未来编程
工程师拿到需求的第一件事，应该聚集在以下几个问题：
第一 哪些需求是我之前完成过的
第二 哪些需求是有可能变化的
第三 有几种方案，分别支持什么样的需求变化
但是差一点的程序员就考虑不到那么远，一个是对业务不熟悉，判断不出来哪些需求可能会产生变化，一个是对可选的方案掌握的不多，根本就没有什么可选的余地，还有就是没有这种思维习惯，分不清楚哪些是现在要完成的，哪些是未来可能会支持或者是变动的。
这也是新手常见的问题。很多时候新人会遇到问题，解决不了，去找一个有经验的工程师，这个有经验的工程师呢，大概也未曾遇到这种情况，但是他解决问题的思路清楚啊。一会儿试试这个，一会儿删删那段代码，很快就跑通了。解决问题是一个很见功底的技术点，而且是有很多方法论的，之前总结过一些，简单列举过来：
1.寻找正确的代码
2.理清楚正确的执行顺序
3.重现错误
4.最小化错误产生的场景
5.修改代码到一个已知的错误类型等等等。
解决问题就是一个分析推理的过程，而在这里呢，背后的功底就是你知道很多哪些是肯定不会错的小公理，然后再挨个去定位可能产生错误的环节，分解流程是最基础的工作。
伪代码是什么呢？就是自然语言啊。其实编程只有三种逻辑控制块，顺序，循环，判断。所以你只要用自然语言来描述出来，先做什么，再做什么，什么时候循环，什么时候判断，代码写出来的问题就不大。这是一个先写伪代码再写细节的过程。你不要上来就开始平铺写代码（我之前讲过优雅代码之道，有兴趣的可以加群听一下，重点讲了怎么写出来优雅代码）。
平铺代码是最菜的方式，好的代码是有结构的，有不同的抽像层级。
第一步，干嘛。
第二步，干嘛。
第三步，干嘛。
先把这个列清楚，这是伪代码的第一级。
然后变成注释，这是第二级。
删掉注释变成函数名，这是第三级。
所以说，好的程序员写代码是不需要注释的，不是说让你把注释删掉，而是让你完成这三步升华的过程。写的好的代码，命名规范，你看到的真的是一首诗， 是一种编程语言，是在用语言来描述一件功能的完成，这种编程艺术的工业感很爽快，你看那些不爽的代码，简直了。
后端工程师在前期经常会忽视数据量的大小，没有影成一个好的习惯。写代码只注重功能，没有一个关于数据量的概念。这个地方其实还和性能是一致的，在性能上，前后端并没有太大的差别。推荐的做法是，程序员要对数据很敏感，后端要知道每一个表的规模可能会有多大，当前的系统能支持的数据库表的大小是多大，而前后端都需要知道每一个操作，都分成了哪几个步骤，每一个步骤花费的时间是多少，大概占用的内存是什么样的。做到这一点其实并不难，难的是养成这种习惯，初级工程师眼里看的是功能和代码，中级工程师眼里看到的是数据和时间。
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
