代码注释费力不讨好，是否应减少投入？

AI

要是编码久了就会发觉，多数时候，大部分注释不过是把函数名和参数名汉译后再写一遍，费力还不讨好。其实我们根本不缺函数注释。就算把函数功能、参数说明、返回值都解释得清清楚楚，大部分不会用的人还是不会用。就算是自己写的代码，长时间不用的话，自己很可能都不会用了。而且现在AI写注释的准确率已经很高了，只要函数和参数命名规范，准确率估计能达到80 - 90%以上。

没想到这个问题这么热闹，那就稍微更新一下吧。@五小同志的回答我很认可。在项目实践特别是后期维护中，设计架构文档的重要性远超代码细节里的注释。其实我是坚定的代码与文档分离支持者，代码是代码，文档是文档，二者合在一起既不利于阅读，还可能产生诸多问题。

代码细节中的注释是零散的，对于某个功能而言，局部注释难以推断出模块间的顺序与耦合关系。因此，多数情况下代码里的注释具有教学学习或者备忘提醒的作用，改小bug时可能有点帮助，但从局部注释很难知晓整个项目框架，对项目功能的增删改查依旧十分困难。当然，代码带有详细注释是个好习惯。有良好注释的人可能是非常优秀的程序员，这些代码或许很关键，可能影响数以万计的设备，甚至左右整个项目的技术走向。不过多数情况下，编写详细的代码内注释相当耗时（当然，现在有AI辅助会快很多，但AI能推导出来的内容往往表明直接阅读代码来理解功能并不会比看注释慢多少）。一个有责任心的程序员，未必就是优秀的项目领导者。项目管理要更多地关注投入的时间与产出。在大多数项目里，写这些注释只是一种负责的态度，但做的项目多了就会知道，世上没有太多纯粹的优点或者缺点。多数时候，代码旁边的注释性价比不高，而且写注释花费的时间常常比写代码的时间还长，很可能会拖慢整体进度。有些同志觉得我的项目简单，就认为我不写内部注释（其实关键部分还是会写几句的）。但实际上，复杂的功能逻辑很难用简短文字解释清楚。就像我在某个功能模块里用了db小波，还用了波动方程的一个特解，以及一系列常量。我没办法在代码里详细说明为什么用db小波，这个特解的初值边值条件是怎么来的，用了什么算法做计算逼近。我不是在做教程，整个求解算法可能涉及五六篇论文，我没法解读，更不能在注释里帮人复习数字信号处理和数学物理方程。懂这块内容的人自然懂，不懂的人写两千字注释也没用。我得在有限时间推进整个项目，不能在这儿当老师。来点消极的东西。干的时间长了就知道，根本没什么办法能不让项目变成屎山。项目只要规模变大、时间变长，最后都会变成屎山。早点接受这个现实，就能早点成长。要是能在屎山上把功能稳定运行，让项目晚些被淘汰，让兄弟们多拿一天工资，就很成功了。最后再强调一次，我不是程序员，很讨厌被人这么叫。但这不是说多数程序员的码龄、码量、项目成果与失误会多于我。