新手写代码常见的错误示例

新手写代码常见的错误示例

每个程序员都要经历写代码从不规范到规范的过程，下面总结了一些新手写代码常见的错误示例，看看有没有你吧~

1、命名不规范

命名很随意，想到什么名字写什么，意识不到命名规范的意义，等到过几天在看的时候完全一团懵。

2、日志不规范

日志？那是什么鬼东西，能吃么？ 曾经有一个从文思海辉出来的小伙伴，三年后端工程师经验，出了问题不知道怎么解决，只好重启。然后找我来协助，问他怎么错了，日志呢 ？答：不知道，没有。晕，那怎么解决问题，神仙也搞不定啊。后来才知道，他们解决问题都是本地改代码然后直接部署，重新访问看错误消失没，没有消失就继续在本地改源码。

3、拒绝写接口和假数据

曾经有一个项目中的两个菜鸡，一个前端一个后端，他们很欢快的调接口，根本不写文档 ，两个人效率特别高。直到有一天，发现项目可能做不完了，需要另外两个前端菜鸡协助一下。新来的两个菜鸡要获取后端的数据，不知道接口的Url地址，不知道Get还是Post，不知道发送的参数和返回值。就这样写！我压根没想到可以这么写代码，两个菜鸡很开心！拍手称快：通了，通了，通了！我说你们通什么呢？他们说接口终于通了！原来他们两个参考之间的页面，硬生生的一次一次不停的尝试，就这样把接口猜出来了！这就是编程的乐趣吗？还有不写假数据。曾经有一个马姓小哥，对赵姓小哥信誓旦旦的说：3天，给我3天时间 ，我把真数据给你。于是赵姓小哥信以为真。就这样，3天又3天，3天又3天，3天又3天，3天又3天，3天又3天。整整一个半月，赵姓小哥都没有拿到全部的数据！

4、不写单元测试

确切来说，是不按TDD的方式开发。在现在IDE这么强大的情况下，先写单元测试的习惯，不仅仅是代码的严谨性，也是效率的代名词啊。可是很多菜鸡理解不了单元测试的价值，没关系，等到代码重构，需求变更的时候，就哭都哭不出来了！好的单元测试，你的逻辑必然会清楚。

5、先集成，再测试，再放弃

很多时候，在引入第三方的库，框架，接口或者是服务的时候，最喜欢的事情就是直接和自己原有的代码集成在一起。结果 是什么呢？突然间不能用了，跑不起来了，不知道问题出在哪了，根本分不清倒底是第三方的问题还是自己的问题。 好的方法是什么？先跑通官方提供的Demo，再想办法一点一点加上自己的业务。

6、理不清楚逻辑，边做边猜

前端在这里的问题比较多，不清楚流程，总以为前端就是接口处理好数据展示好拉倒。这样不好，先把逻辑处理好，弄清楚流程，再去动手才好。

7、不做方案

不做方案代表什么含义呢？就是完全凭直觉行走啊。写代码的好习惯应该是先在脑袋里把所有的需求细节过一遍，实现细节拿出来。

8、不关注性能

不关注性能也是新人很容易犯的错。什么是性能呢。对后端来说就是TPS和响应时间，对前端来说就是响应时间。在写代码的时候，有经验的工程师已经知道了这个方法这个函数这个功能点的性能怎么样，瓶颈在哪里。

9、害怕重构

“程序员最大的勇气就是看自己三个月之前写的代码。”其实重构并不应该是在几个月之后重构，最好的方式是实时重构。写一天代码，70%的时间都放到重构上都不过份。而新人呢，磕磕跘跘的完成一个功能，就跟多米诺骨牌做成的大黄蜂一样，你敢动一下他的代码试试？他会跟你拼命。你让他自己动一行代码试试？不重构在某种程度上也意味着你的代码实现无法重塑。

10、不考虑未来需求的变化

工程师的水准，其实可以分成以下几个阶段：

· 面向功能编程

· 面向性能编程

· 面向未来编程

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

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

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

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

但是差一点的程序员就考虑不到那么远，一个是对业务不熟悉，判断不出来哪些需求可能会产生变化，一个是对可选的方案掌握的不多，根本就没有什么可选的余地，还有就是没有这种思维习惯，分不清楚哪些是现在要完成的，哪些是未来可能会支持或者是变动的。学会规范写代码，再勤加练习，相信你离大(tu)佬(tou)程序员不远了！