程序员最多见错误集锦

做为程序猿的咱们常常容易犯各类错误，把这些错误改正了，就离高级码农们不远了。

 

总结一下初级程序员常常犯的错误：

1 命名不规范

2 日志不规范

3 拒绝写接口和假数据

4 不写单元测试

5 盲目集成

6 逻辑不清

7 不作方案

8 不关注性能

9 惧怕重构

10 作出来就好，不考虑优雅的方案

11 不考虑将来需求的变化

12 遇到问题的时候不会试错

13 不会写伪代码

14 不作数据量的预估

15 提交代码不规范

16 不喜欢打Tag

17 不遵照发布流程

18 不知道Bug修复的优先级

19 总喜欢手动修改线上代码

20 不作数据备份

21 不作自测

22 不尽力模仿真实数据，测试数据很随意

23 不抽取公共代码

24 不认真听需求讲解

25 不看验收标准

26 不主动推动项目进度

27 遇到难题不主动反馈

 

 

 

一 命名不规范

命名很随意，当时写代码特别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 作出来就好，不考虑优雅的方案

有个词叫作最佳实践，其实编码规范和最佳实践，是编程功底的重要体现。

优雅方案能够认为是最佳实践的升级版，它和上面说到的不断的重构是相辅相成的。

 

很差的方案是什么呢？硬编码居多，没有可扩展性，用很丑陋的方式完成了功能。

上次他们去作了一个关于试听课的方案，一我的能试听多少节课，正常的逻辑应该是在用户的表里加一个字段来表示。

需求是写着邀请几我的，能够试听多少节课，因此他们判断试听多少节课就直接在经过邀请人的表里查询去作。

 

彻底没考虑到之后若是我变换了试听课的判断条件怎么办？

实际上这是应该拆解成两部分，一个是试听课的产生条件，这是一个独立的模块，加一个是试听课的确认。

像这种例子太多了，也和不作方案，不考虑扩展性有关系。就是接下来要说的。

 

 

11 不考虑将来需求的变化

工程师的水准，其实能够分红如下几个阶段（马丹我找不到以前在哪一个答案里写过了）：

面向功能编程

面向性能编程

面向将来编程

 

工程师拿到需求的第一件事，应该汇集在如下几个问题：

第一 哪些需求是我以前完成过的

第二 哪些需求是有可能变化的

第三 有几种方案，分别支持什么样的需求变化

 

可是差一点的程序员就考虑不到那么远，一个是对业务不熟悉，判断不出来哪些需求可能会产生变化，一个是对可选的方案掌握的很少，根本就没有什么可选的余地，还有就是没有这种思惟习惯，分不清楚哪些是如今要完成的，哪些是将来可能会支持或者是变更的。

 

12 遇到问题的时候不会试错

这也是新手常见的问题。不少时候新人会遇到问题，解决不了，去找一个有经验的工程师，这个有经验的工程师呢，大概也不曾遇到这种状况，可是他解决问题的思路清楚啊。

一下子试试这个，一下子删删那段代码，很快就跑通了。

 

解决问题是一个很见功底的技术点，并且是有不少方法论的，以前总结过一些，简单列举过来：

1.寻找正确的代码

2.理清楚正确的执行顺序

3.重现错误

4.最小化错误产生的场景

5.修改代码到一个已知的错误类型

 

等等等。

解决问题就是一个分析推理的过程，而在这里呢，背后的功底就是你知道不少哪些是确定不会错的小公理，而后再挨个去定位可能产生错误的环节，分解流程是最基础的工做。

13 不会写伪代码

 

伪代码是什么呢？就是天然语言啊。其实编程只有三种逻辑控制块，顺序，循环，判断。

因此你只要用天然语言来描述出来，先作什么，再作什么，何时循环，何时判断，

代码写出来的问题就不大。

这是一个先写伪代码再写细节的过程。你不要上来就开始平铺写代码（我以前讲过优雅代码之道，有兴趣的能够加群听一下，重点讲了怎么写出来优雅代码）。

平铺代码是最菜的方式，好的代码是有结构的，有不一样的抽像层级。

 

第一步，干吗。

第二步，干吗。

第三步，干吗。

 

先把这个列清楚，这是伪代码的第一级。

而后变成注释，这是第二级。

删掉注释变成函数名，这是第三级。

 

 

因此说，好的程序员写代码是不须要注释的，不是说让你把注释删掉，而是让你完成这三步升华的过程。

写的好的代码，命名规范，你看到的真的是一首诗， 是一种编程语言，是在用语言来描述一件功能的完成，这种编程艺术的工业感很爽快，你看那些不爽的代码，简直了。。

 

14 不作数据量的预估

后端工程师在前期常常会忽视数据量的大小，没有影成一个好的习惯。

写代码只注重功能，没有一个关于数据量的概念。

这个地方其实还和性能是一致的，在性能上，先后端并无太大的差异。

 

推荐的作法是，程序员要对数据很敏感，后端要知道每个表的规模可能会有多大，当前的系统能支持的数据库表的大小是多大，而先后端都须要知道每个操做，都分红了哪几个步骤，每个步骤花费的时间是多少，大概占用的内存是什么样的。

 

作到这一点其实并不难，难的是养成这种习惯，初级工程师眼里看的是功能和代码，中级工程师眼里看到的是数据和时间。

 

 

欢迎你们补充~