提高代码可维护性（1）---代码注释

    今天调试代码，突然发现几天前写的代码读不懂了。为了赶进度，拼命写代码，忽视了代码的注释和打印代码，结果为后面维护照成了很大的困难。

    痛定思痛，补上所有注释和打印信息。算是亡羊补牢，尤未晚也。

    开始写代码的时候，想的是业务应该不会太复杂，规模不会太大，结果，后面不知不觉中就膨胀了。

    下面说说代码注释，为了让自己和别人很好的理解你的代码，良好的注释特别重要。

    注释方面，网上有各种各样的指导或者经验之谈。说得也很好。但是感觉条条框框太多了，往往就不好执行。条条框框太多，反而让人陷入了复杂的条例中去了。

我理解的注释，不管你用什么语言，写什么内容代码，都应该有一些相通的原理。

    首先，注释应该需要精心设计的，而是滥竽充数。

    注释需要设计，不知道这个有没有人提过。

    谈注释也需要设计。程序是设计出来的，这很多人能赞同，但是注释需要设计，恐怕就有人提不同的意见。首先，注释比程序在某种程度上比程序难写。程序就是用某种语言实现你的业务。在一定程度上，业务就决定了你的程序长什么样，程序相对发挥的空间比较少。也许很多人会提，好代码会有更好的效率之类的。我不否认这些，但其实业务固定了，程序能发挥的空间相对是有限的。但是注释就不一样了，怎样写注释让一个不懂代码的或者不看代码的人也能看得懂，知道你在干什么。那这个注释才算是成功的。要做到这样的成功，说注释是需要设计的一点也不为过。

    其次，注释需要分层次，不能抽象。

    注释就是说明文，不是文言文，更不是散文。分层次，层层递进才是好的注释风格。有些人可能写代码注释很详细，但是写的注释却让人看不懂。为什么，就是因为没有层次，没有递进关系。要想到，大多数情况下，其它人不愿意，仔细的阅读所有的代码，没有精力，如果系统庞大爷也不现实。所以注释也立意高远。也轻重有序。

     第三，业务逻辑和关键算法，一定要注释清楚。

    自己写的代码不一定是自己维护，所以要想到自己的代码传递给别人维护的时候遇到的问题。读代码最难懂的就是代码中隐晦的业务逻辑。现在部门200多人一起维护几百万行代码。系统太复杂，以致，大家没有办法从全局来看通所有代码，所以对一个简单的变量，局部看起来没有作用，但是带上了业务逻辑之后，随便一改就出大事故了，可能整个系统都起不来。所以附带上业务逻辑和关键算法的一定要不惜文字注释清楚。

    第四，注释也实时更新。

    这个在多人共同开发的时候显得尤为重要。不实时更新，那注释可能不但不帮忙，反而误导代码阅读者。所以一定要做到实时更新自己的注视。要把注释的维护放到代码维护同样的高度。

    一点点感悟，大家一起共勉。让我们一起为写漂亮的代码努力！