写程序不愿意写注释的问题

注释的目的在于提高代码的后期维护性，也就是说花费了当前的工作时间换取以后节约更多的时间。

一次性代码、以后不需要维护的代码实际上不需要写注释。
结构清晰简单、很容易维护的代码可以少写甚至不写注释，写多了注释反而会降低工作效率。
代码越复杂越不容易维护，维护的人越是参差不齐，越是需要认真写注释。
判断注释、文档写的够不够其实很容易验证。如果代码将来也还是自己维护，那就找找几年前自己的代码，看看是不是很容易看明白，思考一下如果想改点什么功能是不是比较容易。我看过自己10年前的代码，除了有些地方当时水平低写的乱之外，都还比较容易看明白。如果代码会有别的同事维护，就需要有制度互相验证注释、代码是否清晰明白。

工程实践总是复杂的。生活中我们遇到的问题实际上还要麻烦很多。

首先就是个人太短视，看不到或者是看轻注释对未来的意义，或者是过于相信自己的理解能力，自己就不愿意写注释。这种倾向比较难纠正，让他多维护几次很久以前写的代码可能有点帮助。
再就是因为将来维护的程序员并不是自己，那么写注释就变成了降低自己的成绩提高他人的成绩，这种事情要圣贤才能做好，我们普通人主动做这个实在是痛苦，只能借助考核制度来辅助。这种考核制度并不容易实施，因为注释、文档的效果很难量化，不太可能被领导理解，也不太可能被业务、产品等其他部门同事理解，所以除非确定未来的收益归于本团队，否则团队自己并没有动力在当前约束自己。
如果底层程序员变动频繁，那就需要小组长一级对注释情况进行管理，如果小组长自己也变化频繁，那就需要更高一级管理者来约束。这样推导下去，如果某一级管理层不够稳定，无法获取注释带来的未来的好处，而他的上一级领导又没有合适的制度感知、补偿这一部分注释带来的工作量的话，注释这个工作就肯定搞不好了。
其实日常管理之中比较容易提升的也就是这一部分，根据具体情况，制订合适的管理制度，这一部分是可以控制好的。

另外还有更糟糕的不愿意写注释、文档的理由，有人会故意让代码只有自己看的明白，别人很难看懂，这样有助于提高自己的地位。这种人还是争取早点发现，早点清除吧。