从注释说起...
不爱写注释应该是程序员的通病，所以不要为不写注释或写不好注释而感到羞愧。
那为什么项目总是要求我们要写注释，并且有些项目还需要有一定的注释率呢，可能有以下几点原因：
- 应付检查：记得刚毕业做过的岛国项目要求注释和代码比率是1:1，满屏看上去都是绿色的注释。作为上线前一项检查的硬指标，不达标是不能上线的。
- 更容易理解：这应该是注释的初衷，通过容易理解的注释能够帮助我们理解代码的意图。
- 防止自己忘记：其实这点和第二点差不多，我们经常连一周前自己写的代码都不认识了，写个注释可能帮助我们回忆。
既然注释有很多的好处，那我们为什么不爱写注释呢。原因也很简单，因为代码变化的太频繁了。试想一下，需求的变化、bug的修复、代码的重构，每次代码变更我们都要关注一下注释是否正确，注释俨然成为了程序员的又一份文档，而程序员更不爱写文档。
那有没有什么办法来改进程序的可读性呢，可以从以下几个角度进行考虑：
- 规范的命名（包括变量、方法、类...）
- 短小的方法
- 简洁的类
规范的命名
变量的命名：使用有意义的名称来命名变量， name比x要好，而userName比name要好，名称歧义性越小越好（user和userInfo就容易产生混淆）。
方法的命名：使用动词或动词短语命名方法；方法的命名意义越明确越好（saveUserData比saveData好）
类的命名： 类是对象的模板，既然用来命名对象的模板，用名词则显得再合适不过。同样，名称也是越具体越好（Apple肯定比Fruit好）
当然命名可以讨论的内容不仅仅是这些，例如减少那些容易产生混淆的方法命名（saveUserInfo和saveUserData就容易让人摸不着头脑）。当项目越来越复杂的时候，命名就成为了一项头疼的工作，但是为命名花点时间是值得的，这样可以让代码看起来没有那么的痛苦。
短小的方法
如何理解短小的方法（就是一个方法只做一件事）
什么是只做一件事呢，就是方法内的操作应该在一个抽象层面上，这里举个栗子：
方法：买菜1{
if(有芹菜){
买芹菜；
现金付款，
找零
}else if(有茄子){
买茄子；
微信付款；
if(钱不够){
跟媳妇申请买菜钱；
继续付款；
}
}
...继续买肉
}
方法：买菜2{
买青菜;
买肉;
}
买菜1和买菜2那个更清晰呢，很明显是方法2，而且买青菜和买肉是统一抽象层级上的东西，如果把如何买菜和如何买肉的逻辑也加到大方法里面的话，写起来可能很爽，但看起来就会有点头大。
简洁的类
经常看到许多庞大的类，里面的变量和方法包罗万象，就像变形金刚那些能合体的机器人一样，看起来非常的强大。但是一旦某个部分出现了bug，就容易引起整体的崩溃。
那么这些庞大的类是如何形成的呢，我想一大部分原因是修改方便，看着只改几行代码就可以加一个功能，更多人是不会思考如何重构或者创建新的类来完成工作的，到最后就变成了一个巨无霸类。而一旦出现比较大的变更，修改可能是灾难性的。
所以我们要时常警惕类的大小以及功能的单一性，既然是面向对象编程，不能让我们构造的对象最后变成了四不像。
至于至于如何提高类的内聚性，这里就不再详述了。
上述所列的都是为了增加代码的可读性，如果可读性大大的提高了，那代码其实也就具有了自注释的特性，也能够帮助程序员减轻写注释的负担。当然，写不写注释还是要看项目组的总体要求，但是要记得时常修改程序的注释，不要在注释上留坑。
