14道初级程序员进阶中高级的必经环节

Time will tell.

本章节就和你说一说从初级晋级为高级程序员的必经之路，同时也反思一下自己还有哪些不足之处。

1、 命名的规范

我们在学习编程的时候，老师都或多或少地有提到过命名的问题。但命名随意起来时，真的是什么奇奇怪怪的命名都有的：xiaonaigou,xxx,j1,jl,llst.

可能没完全习惯过来，也可能是没意识到命名规范的价值和意义。这些问题尤其是会出在年纪偏小的程序员身上。

2、日志，日志的规范

曾经有一个3年后端经验的小伙伴，出了问题不知道怎么解决，只好重启，找我来协助，问他：“怎么错了？”

“不知道。”

“日志呢？”

“没有。”

这怎么解决嘛…

到后来才知道，他们解决问题都是本地改代码然后直接部署，重新访问看错误消失没，没有消失就继续在本地改源码。

3 、不写接口和假数据

一个菜鸡不可怕，可怕的是菜鸡遇到菜鸡。

曾经有一个项目中有两个菜鸡，一个前端的一个后端的，他们很欢快地调接口，根本不写文档 ，两个人效率特别高。

直到有一天，发现项目可能做不完了，需要另外两个前端菜鸡协助一下。新来的两个菜鸡要获取后端的数据，不知道接口的 Url 地址，不知道Get 还是Post ，不知道发送的参数和返回值。就这样写！

我压根没想过可以这么写代码，两个菜鸡很开心！拍手称快：“通了，通了！”

我说你们通什么呢？他们说接口终于通了！原来他们两个参考之间的页面，硬生生的一次一次不停的尝试，就这样把接口猜出来了！

这就是编程的乐趣吗？

还有不写假数据。

曾有一位马姓小哥，对赵姓小哥信誓旦旦地说：“3天，给我3天时间 ，我把真数据给你。”

赵姓小哥信以为真。就这样3天又3天，如此往复 …

一个半月后，我们仍未见到那天说的全部数据！

4、不写单元测试

确切来说是不按 TDD 的方式开发。在现在 IDE 这么强大的情况下，先写单元测试的习惯，不仅仅是代码的严谨性，也是效率的代名词啊。

很多菜鸡理解不了单元测试的价值，没关系，等到代码重构，需求变更的时候，哭都哭不出来！

好的单元测试，你的逻辑必然会清楚。

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

很多时候，菜鸡在引入第三方的库、框架、接口或者是服务时，最喜欢的事情就是直接和自己原有的代码集成在一起。

结果是什么呢？突然间不能用了，跑不起来，不知道问题出在哪了，根本分不清倒底是第三方的问题还是自己的问题。

好的方法是先跑通官方提供的 Demo，再想办法一点一点加上自己的业务。

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

前端在这里的问题特别多，做支付，不清楚支付的流程，分不清楚定义，总以为前端就是接口处理好数据展示好拉倒。

很多菜鸡都会有这种习惯，这样不好，先把逻辑处理好，弄清楚流程，再去动手才好。

7 、不做方案

不做方案代表什么含义呢？完全就是凭直觉走位。

写代码的好习惯应该是先在脑袋里把所有的需求细节过一遍，实现细节拿出来。

上个月就有一个张姓小哥，做一个匿名评论功能。基本上没有经验，脑子也有些Ennn，给出的方式是什么你们能猜到么？

用户刷新一次就往用户表里插入一条数据，密码默认昵称随机。

说多了都是泪，见过太多让人目瞪狗呆的方案了，看着满屏的代码，你怎么帮他调错调优，最好的方式就是全部重写。

做了方案的好处太多了。

8、不关注性能

不关注性能也是新人很容易犯的错。什么是性能？对后端来说就是 TPS 和响应时间，对前端来说就是响应时间。

很多新人程序员的习惯就是把东西做出来，然后再优化。最后就是东西做出来了，优化留给别人了。

对性能的关注也是晋升中级程序员最关键的技能点。在写代码的时候，有经验的工程师已经知道了这个方法这个函数这个功能点的性能怎么样，瓶颈在哪里。

9、 害怕重构

“程序员最大的勇气就是看自己三个月前写的代码。”

其实重构并不应该是在几个月之后重构，最好的方式是实时重构。写一天代码，70%的时间都放到重构上都不过份。

而新人磕磕跘跘地完成一个功能，就跟多米诺骨牌做成的大黄蜂一样，你敢动一下他的代码，他会跟你拼命。

不重构在某种程度上也意味着你的代码实现无法重塑。

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

有个词叫做最佳实践，其实编码规范和最佳实践，是编程功底的重要体现。优雅方案可以认为是最佳实践的升级版，它和上面说到的不断的重构是相辅相成的。

不好的方案是什么呢？

硬编码居多，没有可扩展性，用很丑陋的方式完成了功能。

上次他们去做一个关于试听课的方案，一个人能试听多少节课，正常的逻辑应该是在用户的表里加一个字段来表示。需求是写着邀请几个人，可以试听多少节课，所以他们判断试听多少节课就直接在通过邀请人的表里查询去做。完全没考虑到以后如果我变换了试听课的判断条件怎么办？

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

这种例子太多了，也和不做方案、不考虑扩展性有关系。

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

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

• 面向功能编程

• 面向性能编程

• 面向未来编程

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

• 哪些需求是我之前完成过的

• 哪些需求是有可能变化的

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

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

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

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

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

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

1. 寻找正确的代码

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

3. 重现错误

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

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

   …

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

13、不会写伪代码

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

所以你只要用自然语言来描述出来，先做什么，再做什么，什么时候循环，什么时候判断，代码写出来的问题就不大。

这是一个先写伪代码再写细节的过程。你不要上来就开始平铺写代码。平铺代码是最菜的方式，好的代码是有结构的，有不同的抽像层级。

第一步干嘛，

第二步干嘛，

第三步该干嘛。

先把这个列清楚，这是伪代码的第一级。然后变成注释，这是第二级。删掉注释变成函数名，这是第三级。

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

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

14、不做数据量的预估

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

写代码只注重功能，没有一个关于数据量的概念。这个地方其实还和性能是一致的，在性能上，前后端并没有太大的差别。

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

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

好啦，以上内容就到这里，如果你对Python自动化软件测试、面试题等更多内容感兴趣的话可以加入我们175317069。群里会有各项测试学习资源发放，更有行业深潜多年的技术人分析讲解。期待你的加入！

欢迎【点赞】、【评论】、【关注】~

Time will tell.（时间会说明一切）