初级程序员必犯10大错误！这些错你真的没有犯过吗……
身为程序员，难免会犯错，小错不可怕，怕的是有错不改，形成了不好的习惯。今儿个咱们就来聊聊初级程序员必犯的10大错误，说是必犯，多少有些夸张，但是确实是我在教学工作中，发现的一些问题。在此总结提出，以飨读者。
1 命名不规范
2 日志不规范
3 拒绝写接口和假数据
4 不写单元测试
5 盲目集成
6 逻辑不清
7 不做方案
8 不关注性能
9 害怕重构
10 做出来就好，不考虑优雅的方案
一 命名不规范
命名很随意，当时写代码特别High，什么奇奇怪怪的命名都有的：xiaonaigou,xxxx,j1,jl,llst.
完全意识不到全名规范的价值和意义。
二 日志不规范
日志？那是什么鬼东西，能吃么？
曾经有一个从文思海辉出来的小伙伴，三年后端工程师经验，出了问题不知道怎么解决。
只好重启。
找我来协助，问他，怎么错了？
不知道。
日志呢？
没有。
晕，那怎么解决问题，神仙也搞不定啊。
后来才知道，他们解决问题都是本地改代码然后直接部署，重新访问看错误消失没，没有消失就继续在本地改源码。
三 拒绝写接口和假数据
一个菜鸡不可怕，可怕的是菜鸡遇到菜鸡。曾经有一个项目中的两个菜鸡，一个前端一个后端，他们很欢快的调接口，根本不写文档 ，两个人效率特别高。
直到有一天，发现项目可能做不完了，需要另外两个前端菜鸡协助一下。
新来的两个菜鸡要获取后端的数据，不知道接口的Url地址，不知道Get还是Post，不知道发送的参数和返回值。就这样写！
我压根没想到可以这么写代码，两个菜鸡很开心！拍手称快：通了，通了，通了！
我说你们通什么呢？他们说接口终于通了！原来他们两个参考之间的页面，硬生生的一次一次不停的尝试，就这样把接口猜出来了！
这就是编程的乐趣吗？
还有不写假数据。曾经有一个马姓小哥，对赵姓小哥信誓旦旦的说：3天，给我3天时间 ，我把真数据给你。
于是赵姓小哥信以为真。就这样，3天又3天，3天又3天，3天又3天，3天又3天，3天又3天。
整整一个半月，赵姓小哥都没有拿到全部的数据！
四 不写单元测试
确切来说，是不按TDD的方式开发。在现在IDE这么强大的情况下，先写单元测试的习惯，不仅仅是代码的严谨性，也是效率的代名词啊。
可是很多菜鸡理解不了单元测试的价值，没关系，等到代码重构，需求变更的时候，就哭都哭不出来了！
好的单元测试，你的逻辑必然会清楚。
五 先集成，再测试，再放弃。
很多时候，菜鸡在引入第三方的库，框架，接口或者是服务的时候，最喜欢的事情就是直接和自己原有的代码集成在一起。
结果 是什么呢？突然间不能用了，跑不起来了，不知道问题出在哪了，根本分不清倒底是第三方的问题还是自己的问题。
好的方法是什么？先跑通官方提供的Demo，再想办法一点一点加上自己的业务。
六 理不清楚逻辑，边做边猜
前端在这里的问题特别多，做支付，不清楚支付的流程，分不清楚定义，总以为前端就是接口处理好数据展示好拉倒。
很多菜鸡都会有这种习惯，这样不好，先把逻辑处理好，弄清楚流程，再去动手才好。
七 不做方案
不做方案代表什么含义呢？就是完全凭直觉行走啊。
跟闭上眼逛窑子一样。
写代码的好习惯应该是先在脑袋里把所有的需求细节过一遍，实现细节拿出来。
上个月就有一个张姓小菜鸡，做一个匿名评论的功能。
基本上没有什么经验，脑子也不好使，给出的方式是什么你们猜得到么？
用户刷新一次就往用户表里插入一条数据，密码默认昵称随机。
不多说了都是泪，我见过太多让人目瞪狗呆的方案了，看着满屏的代码，你怎么帮他调错调优，最好的方式就是全部重写。
做方案的好处太多了。
8 不关注性能
不关注性能也是新人很容易犯的错。什么是性能呢。对后端来说就是TPS和响应时间，对前端来说就是响应时间。
很多新人程序员的习惯就是把东西做出来，然后再优化。
最后就是东西做出来了，优化留给别人了。
对性能的关注也是晋升中级程序员最关键的技能点。在写代码的时候，有经验的工程师已经知道了这个方法这个函数这个功能点的性能怎么样，瓶颈在哪里。
9 害怕重构
“程序员最大的勇气就是看自己三个月之前写的代码。”
其实重构并不应该是在几个月之后重构，最好的方式是实时重构。写一天代码，70%的时间都放到重构上都不过份。
而新人呢，磕磕跘跘的完成一个功能，就跟多米诺骨牌做成的大黄蜂一样，你敢动一下他的代码试试？他会跟你拼命。
你让他自己动一行代码试试？
不重构在某种程度上也意味着你的代码实现无法重塑。
10 做出来就好，不考虑优雅的方案
有个词叫做最佳实践，其实编码规范和最佳实践，是编程功底的重要体现。
优雅方案可以认为是最佳实践的升级版，它和上面说到的不断的重构是相辅相成的。
不好的方案是什么呢？硬编码居多，没有可扩展性，用很丑陋的方式完成了功能。
上次他们去做了一个关于试听课的方案，一个人能试听多少节课，正常的逻辑应该是在用户的表里加一个字段来表示。
需求是写着邀请几个人，可以试听多少节课，所以他们判断试听多少节课就直接在通过邀请人的表里查询去做。
完全没考虑到以后如果我变换了试听课的判断条件怎么办？
实际上这是应该拆解成两部分，一个是试听课的产生条件，这是一个独立的模块，加一个是试听课的确认。
像这种例子太多了，也和不做方案，不考虑扩展性有关系，结果就是无法应对任何稍微大一点的变化。
