以前很难理解老程序员不写注释，不写文档，代码不规范，命名不规范。现在开始懂了。。。

写注释是给自己以后看的，而不是给后面接手人看的，如果自己能看懂，就没必要写注释。代码原则就是没注释能看懂的代码是最好的。

这么做感觉是在糟践自己，把自己往一条下坡路引

这么做感觉是在糟践自己，把自己往一条下坡路引

好的架构是演化出来的，不去演化继续赶工自然就劣化了，再加上你没有前人的上下文，自然就看不懂了，这些甚至不需要可以为之。
而且最近写了些有设计的代码，别人也看不懂，因为代码不够线性（像面条）了

我以前也是老老实实写注释，但是自从来了一个哥们，把注释换一个风格，变量名和函数名换一下并成自己的成果去捞功劳后，我再也不想写注释了，尤其是逻辑越复杂的越不想写，写就写最简单的那种。

注释一般我也不会写的，但不是因为可替代性，而是很多逻辑和业务代码是不需要注释的，我觉得自己的命名规范、逻辑都是不错的，看我代码不会有迷惑的点。除非是那种其他包的参数、特殊值会备注一下地点和作用。
而且代码写的可读性越强，对自己来说长期绝对是利好的，至少技术、逻辑、人品都是展示给所有人看的。
什么不可替代性，都是自己骗自己的，老板要开你，难道还问你领导：这个项目是不是缺他就干不了？

归根到底一句话：萝卜快了不洗泥。

老板又不为这些工作付钱，需求那么多，时间人手就那么些，当然是怎么快怎么来。

比如正常一个需求，完成开发需要时间为 N ，加上文档可能要 2N ，再加测试可能要 3N ，但老板通常只会给你 N/2 的时间，你说怎么办？

@ghostben 加入代码已经发布了，那怎么办，每次 clone 下来还能看到之前的注释吗？

其实变量名命名清晰点 直接 chatgpt 生成注释就很好了

你们没有代码 review 么。。。。

水货程序员整天纠结注释

你就说能不能用吧

除了高精尖的外，其余的基本上一水的 CV ，管你写不写，你就是写的天书，大不了我重新实现一下

又不是不能用.jpg

@ghostben #25 思路不错啊，抓到痛点了

正常开发过程中都写注释的 但是后期迭代快的时候 客户一直改需求的时候 注释就不会写的那么多了

@vagranth 哈哈,之前参加了一个屎山项目,深有体会

你好，理解你的痛苦。接手别人写的代码，一般需要先了解这段代码的业务逻辑，以及原有代码的命名规范和格式。要是运气好的话，有人给你解释以前的业务逻辑，或者给你看以前的文档，要是运气不好的话，只能自己慢慢琢磨了。因此，维护起来也花了更多的时间，比如写注释，命名规范，代码规范，写文档等等。对于你自己的代码也是如此，细心考虑，花点时间看看能不能将可读性提高，让自己的代码更容易维护。可读性越强，你的可替代性不也是越强吗？让你的代码可以带给其他人更多的快乐，也是值得花费点时间的。

@j717273419 说的很对，国外大厂文档真是做得真是好，有时候也在想什么时候写出那么好的文档，但是一看工期每天都赶得不行哪有空写文档，唯一一次写文档还是过年前大家都休息了自己有时间整理思路写文档

你是没见到一句代码没写就要写开发文档的公司，五天的开发时间，一天写文档，一天对文档，一天改文档，一天开发，半天测试，再来半天继续改文档，你以为改的是开发文档，使用详情，其实是不能用 markdown ，要用 word ，xx 标题要用宋体，小四，xx 流程图不能用蓝色，要用红色，1+2 不能直接等于 3 ，需要改成 1+1+1 ，问了一下这文档最后谁看，嗯，就他和大 boss 看，只对内。。。