有人说，代码即注释，也就是通过你的代码就能看得懂你的代码逻辑是什么。但是对于大多数人来说，这有些不切实际，每个公司的研发团队成员的能力是不一样的，有的能力强，有的能力弱，能力强的体现在能解决若干问题，但是在编码规范方面却有待提高，能力弱的，有的能力弱的在代码规范方面却比所谓的能力强的要好得多，这里的”能力强”并不是指两个人的聪明才智差异很大，而是指特定领域的积累，有的积累得多，经验丰富，有的积累的少，经验不那么丰富。但因为是一个团队，就必须要有一定的约束，不仅仅是对能力强的，能力差也一样，一视同仁，团队不能搞单兵作战，那样就失去了团队的意义。
近来我不断思考一件事情，如何将代码注释写的更好，过去待了好几家公司，我写代码对于注释的态度如下:
- (1)有时间就写，没时间后面再说(实际等于不写任何注释)；
- (2)针对特定接口、类、方法写一些概要注释(也就是解释该接口、类、方法是做什么的)；
- (3)针对复杂的逻辑，写注释，自上而下。
但是最终做的最多的还是(1)，哪怕有的时候工作中有一定的空闲时间，我所想的并不是如何将以往没写注释的补充一下注释，而是了解研究现在的新技术(流行的编程语言或Java相关的框架组件等)。
这样做的最后结果是，代码可读性越来越差，可读性差导致的扩展性也就越来越差，可读性跟可扩展性有一定的相关性。
举个例子:
在开发时间紧迫的时候，面对新的功能，看到以往有类似的功能，通常我们的做法是将其复制过来，改了一些，测试了一下，功能输出结果，符合预期，然后就不管了，下次再遇到类似的功能，仍然采取该做法。突然某一天，经理说这个新的功能里面要加一些附加小功能，并同时跟这个类似的都全部加上，由于我们之前习惯了复制黏贴，这时对于我们无疑是毁灭性打击，只能拼命加班加点弄了(从这一刻，我明白了码农是如何养成的)。
假设我们有这样一个习惯，面对重复两次或三次以上的功能代码，我们可将其抽取成一个通用方法(针对类似的功能)，一方面，代码可重用性增强，另一方面减少不必要的代码量，最后一方面，未来如果需要加扩展，我们只需改动这一个方法即可，同时我们写注释，将这一方法写清楚即可。最近我迫使自己养成这样的一个习惯，面对好几个功能模块，我发现轻松了很多，工作效率也大大提升。
一、回归正题，从我的理解上，注释该怎么写？
- (1)复杂的逻辑应有一个流程图(可以是visor图、也可以是txt或word、思维导图等)，按照流程图在对应的代码上写下注释；
- (2)接口、类、方法都需要写注释(这个注释通常包含作者、时间、描述等通用，可通过IDEA模板实现)，针对特定的方法，最好使用多行注释，按照数字顺序进行列举；
- (3)参考开源项目是如何写注释的(如Java、Spring全家桶相关的框架等)；
- (4)方法内部逻辑上，尽量减少注释，如果方法内部逻辑太长，一大堆注释，像写作文似的，改一个地方，需要整体看一遍，结合(1)和(2)或(2)。
二、那么从阿里巴巴Java开发手册上对于注释又是怎么描述的？
1.【强制】类、类属性、类方法的注释必须使用 Javadoc 规范，使用/*内容/格式，不得使用// xxx 方式。
说明：在 IDE 编辑窗口中，Javadoc 方式会提示相关注释，生成 Javadoc 可以正确输出相应注释；在 IDE 中，工程调用方法时，不进入方法即可悬浮提示方法、参数、返回值的意义，提高
阅读效率。
2. 【强制】所有的抽象方法（包括接口中的方法）必须要用 Javadoc 注释、除了返回值、参数、异常说明外，还必须指出该方法做什么事情，实现什么功能。
说明：对子类的实现要求，或者调用注意事项，请一并说明。
3. 【强制】所有的类都必须添加创建者和创建日期。
4. 【强制】方法内部单行注释，在被注释语句上方另起一行，使用//注释。方法内部多行注释使用/ /注释，注意与代码对齐。
5. 【强制】所有的枚举类型字段必须要有注释，说明每个数据项的用途。
6. 【推荐】与其“半吊子”英文来注释，不如用中文注释把问题说清楚。专有名词与关键字保持英文原文即可。
反例：“TCP 连接超时”解释成“传输控制协议连接超时”，理解反而费脑筋。
7. 【推荐】代码修改的同时，注释也要进行相应的修改，尤其是参数、返回值、异常、核心逻辑等的修改。
说明：代码与注释更新不同步，就像路网与导航软件更新不同步一样，如果导航软件严重滞后，就失去了导航的意义。
8. 【参考】谨慎注释掉代码。在上方详细说明，而不是简单地注释掉。如果无用，则删除。
说明：代码被注释掉有两种可能性：1）后续会恢复此段代码逻辑。2）永久不用。前者如果没有备注信息，难以知晓注释动机。后者建议直接删掉（代码仓库保存了历史代码）。