Welcome everyone

打工人代码锤炼

编码 汪明鑫 60浏览 0评论

命名的力量

【有意义的命名】

代码即文档,一切尊崇可读性优先,都够明显的表达开发者的意图!

无法想出一个合适的命名随便胡乱凑一个变量名、方法名、甚至类名,短期是爽了自己,

长期来看加大了代码的维护成本和学习成本,大家应该在工作中深有体会有些代码的命名简直不忍直视,还不加注释…

不要因为简单的命名而产生了代码“怀味道”。

 

变量的命名能够正确的描述业务,充分表达含义,保持一致性,不要这里叫userName, 另一个地方就简单叫name了。【小驼峰】

函数名,命名要具体,不要空泛和没有意义的命名,表达出函数具体要做的事情。【小驼峰】

类名,类是一组数据和操作的封装,良好的类的命名能让代码读着更舒爽,光看类名就能大概知道这个类能干什么。 【大驼峰】

 

辅助注释

如果你自信你的代码不加注释别人能完全看得懂,而且你几个月回头过来还能看的懂,那就大胆不加。

但是如果没那个实力,代码本身逻辑复杂,自己编码水平够呛,那还是在必要的地方加上一些注释,几个月后你会感谢当时加的注释,其他人阅读到这部分代码也能够明白。

当然注释不是简单的记流水账,简单的堆文字描述功能,而是对这部分逻辑的核心、容易出问题的地方进行解释,或者对复杂逻辑进行说明,或者说为什么要这么做。

有时候我们也可能会见到一部分代码很多垃圾注释,看起来很费劲,这种情况也是需要避免的。

因此良好的注释,不宜泛滥,也不能完全没有。

 

适当空行

代码中合适的空行能让阅读和理解代码的速度有所提示,当然这个能提示多少我就不乱飙了,

不空行的代码看着会非常难受,特别是对我这种强迫症而言,但是太多的空行就等于没有空行,极端情况下就是每行代码后面都有空行。。。

 

逻辑强相关的代码或处于同一层次的代码之间不空行,将概念相关的代码放在一起,其他情况可适当空行。有点类似抽函数的感觉。

 

老生常谈-日志

我们经常讨论的都是日志不要泛滥,会淹没关键性日志。

现在大多公司都有自己的日志平台,到还好。

 

日志等级揭秘:

1、ERROR  (严重等级 *****

需要立即被处理的线上错误。

对于这个级别的日志要打出关键信息。

值得注意的是,一定不要滥用ERROR,正常的ERROR会把真正的ERROR淹没。

2、WARN

比如说参数校验不通过,没有权限,或者说正常业务逻辑导致的异常case。

可以设置指定时间段超过多少次WARN日志进行报警。

3、INFO

功能正常运行日志,常用来再测试环境排查和定位问题使用。

可以指定只在测试环境打INFO日志。

4、 DEBUG

开发环境下的调试信息。

 

技术栈是要还的

系统和代码出了问题,一定不要置之不理,有问题要及时修补, “千里之堤,溃于蚁穴”。

面对杂乱无章的系统和代码,开发人员只会往里写更多烂代码,在一次次需求迭代过程中就像打补丁一样,

技术栈堆的越来越多,代码越来越多。

 

设计原则

设计模式七大原则:

 

Rule of Three :

1、第一次用到某个功能时,写一个特定的解决方法。

2、第二次又用到的时候,复制上一次的代码。

3、第三次出现的时候,才着手“抽象化”,写出通用的解决方法。

 

KISS:

keep  it simple and stupid

好的代码不是越复杂越好,而是越简单越好。

 

POLA:

principle of astonishment 最小惊奇原则

写代码不要时不时给个 Surprise。。。

惊奇度越高,复杂性越大。

 

转载请注明:汪明鑫的个人博客 » 打工人代码锤炼

喜欢 (0)

说点什么

您将是第一位评论人!

提醒
avatar
wpDiscuz