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

一次性代码、以后不需要维护的代码实际上不需要写注释。
结构清晰简单、很容易维护的代码可以少写甚至不写注释,写多了注释反而会降低工作效率。
代码越复杂越不容易维护,维护的人越是参差不齐,越是需要认真写注释。

判断注释、文档写的够不够其实很容易验证。如果代码将来也还是自己维护,那就找找几年前自己的代码,看看是不是很容易看明白,思考一下如果想改点什么功能是不是比较容易。我看过自己10年前的代码,除了有些地方当时水平低写的乱之外,都还比较容易看明白。如果代码会有别的同事维护,就需要有制度互相验证注释、代码是否清晰明白。

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

首先就是个人太短视,看不到或者是看轻注释对未来的意义,或者是过于相信自己的理解能力,自己就不愿意写注释。这种倾向比较难纠正,让他多维护几次很久以前写的代码可能有点帮助。

再就是因为将来维护的程序员并不是自己,那么写注释就变成了降低自己的成绩提高他人的成绩,这种事情要圣贤才能做好,我们普通人主动做这个实在是痛苦,只能借助考核制度来辅助。这种考核制度并不容易实施,因为注释、文档的效果很难量化,不太可能被领导理解,也不太可能被业务、产品等其他部门同事理解,所以除非确定未来的收益归于本团队,否则团队自己并没有动力在当前约束自己。

如果底层程序员变动频繁,那就需要小组长一级对注释情况进行管理,如果小组长自己也变化频繁,那就需要更高一级管理者来约束。这样推导下去,如果某一级管理层不够稳定,无法获取注释带来的未来的好处,而他的上一级领导又没有合适的制度感知、补偿这一部分注释带来的工作量的话,注释这个工作就肯定搞不好了。
其实日常管理之中比较容易提升的也就是这一部分,根据具体情况,制订合适的管理制度,这一部分是可以控制好的。

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

技术
©2019-2020 Toolsou All rights reserved,
vue项目中对axios的全局封装单个按键控制多种流水灯状态软件测试之BUG描述随机森林篇 R语言实现TP6验证器的使用示例及正确验证数据C语言编程之查找某学号学生成绩一文揭秘阿里、腾讯、百度的薪资职级c语言的5种常用排序方法2021年1月程序员工资统计,平均14915元Bug数能否做为技术人员考核的KPI?