如何把代码写的优雅一些

一、背景

      写这篇博客的背景是因为今晚因为一些代码风格的原因，被主管教育了一顿，代码的好坏，影响的是整个公司的开发效率，还会影响找bug的速度，同时，对我们自身的成长也会起到阻碍作用。所以是时候规范下自己的代码了。

二、一些代码规范

1、变量名的命名

1）如果是多个单词的变量，一定要采用驼峰式的命名，即：aaBb

解释：作为一个phper，这个是从一开始就要注意的，算是一种统一的命名规范。

2）定义一些查询出来的变量的时候，不要用$arr,$arr1,$arr2

解释：因为在我们自己看代码的时候，我们可以清晰的分辨出不同的数组是从哪里查出来的。但是对于我们的同事呢？特别是新来的同事，让他们观看这种代码简直是一种折磨。所以在命名的时候，一定要尽量贴近它所代表的意思。
比如：
//物品查出来的数组
$goods
//用户查出来的数组
$users

3)关于新建数据库

标准：让别人看到你的表名，就知道你这个代表的是哪个表

解释：这个标准也是主管告诉我的。特别是在项目逐渐增大的时候，表名的创建就显得尤为重要。也许表名建的不好并不能影响代码的正确性，但是不直观的表名对同事来说，始终是不友好的。想要成为一名高级程序员，必须要写出让任何码农一眼就能看懂的代码，于无声处听惊雷。
例如：

//窗帘的操作表。首先是属于goods设备，所以前缀为goods，其次是窗帘相关的，所以第二个是curtain。最后的handle代表的操作。这样的命名就显得一目了然许多。
goods_curtain_handle

4）同一个方法中，不要出现相同名字的变量。

解释：此处和上面第2条类似。主要就是怕弄混代码，也是为了方便其他的技术人员阅读我们的代码。

5）方法的封装

标准：通一个方法，当被连续调用两次的时候，就要考虑封装起来。
解释：方法的封装，也是我们自身水平的提升。刚开始都是一步一步的面向过程编程。但这始终是落了下风，而且代码也会变得冗余不堪。方法的封装，也是我们变强的第一步。

三、拿到新需求

1、站在用户角度使用

      在这一步，我们需要参考其他成熟的软件，如果有类似的功能的话，就去点一点，了解每个操作。此时的我们是处于用户的角度，了解用户需求，知道新功能的基本流程是哪些。如果需要自己建立数据库的话，数据库该怎么建，都需要哪些字段等等。这一步一定要老老实实的，把每个流程都走一遍。

2、站在技术角度

      要思考自己上一步都做了些什么。每个功能的要点在哪里。实现的难点在哪里。可能会发生什么样的情况，类似于if…else方式的思考。这一步，我们作为技术，考虑的是如何实现

3、具体实现

1）可以用写注释的方式，把每个步骤的注释都提前写好，然后开始撸码

2）使用百度脑图，把这个功能从头捋一遍。

      经过以上两个过程，我们基本上就能考虑到所有可能发生的情况。这样写出的代码，逻辑性强，bug少。听说谷歌的工程师，他们的竞争就是“一遍写出新功能，并且毫无bug”。我相信，他们肯定是经过严密的思考，把所有情况都在脑子里面走了一遍才动笔写的。很值得我们学习。

四、接手同事的代码

1、先去体验下具体的功能。就比如上面所说的，站在用户的角度去体验功能。

2、体验之后，不要急着看同事的代码。此时，我们作为开发人员，我们自己对于这个功能有自己的理解。此时应该把自己的实现过程写下来。

3、怀揣自己的想法去看他人的代码。抱着批判性的态度，心里就认为同事的代码一定是有BUG的。站在这个角度，我们去阅读同事的代码，更有利于我们看懂并且找到其中的bug。因为对于这部分的功能和实现过程，我们早就了然于胸。

五、总结

真正大牛的代码，厉害之处不是用的方法有多吊，用的技术有多先进，而是他们的代码可读性非常高。注释，逻辑丝毫不差，晋入返璞归真的行列。我等还需努力啊。

end