目录
命名的力量
【有意义的命名】
代码即文档，一切尊崇可读性优先，都够明显的表达开发者的意图！
无法想出一个合适的命名随便胡乱凑一个变量名、方法名、甚至类名，短期是爽了自己，
长期来看加大了代码的维护成本和学习成本，大家应该在工作中深有体会有些代码的命名简直不忍直视，还不加注释…
不要因为简单的命名而产生了代码“怀味道”。
变量的命名能够正确的描述业务，充分表达含义，保持一致性，不要这里叫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。。。
惊奇度越高，复杂性越大。
说点什么
您将是第一位评论人！