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

[jeremylai]

以前接手别人写的代码，到老员工代码，一个注释都没有，运气好的话，有人给你解释以前的业务逻辑，或者给你看以前的文档。要是运气不好的话，只能自己慢慢琢磨了。

后面写注释，命名规范，代码规范，写文档。开发也花了更多的时间。

后面想想，代码的可读性越强，你的可替代性不也是越强吗？花更多的时间，优化自己。

[Fule]

这种“人工混淆”是全局杀伤，包括几个月之后的你自己。几个月之后如果你需要改代码，也不比别人有多少“优势”，除非你记忆力超强。而且改代码也会更耗费时间，以前“省”下的时间在改代码的时候都会补上，而且每改一次就补一回。如果组里大家都这样，想想每个人都释放全局杀伤的场面，我觉得属于互相伤害。我觉得老代码那些问题，部分属于能力问题，部分属于赶工期原因，为了你说的理由而那么做的话，我觉得是得不偿失，除非是抱着跑路心态。

[zpxshl]

之前有个前同事面我现在的部门，领导问我对这个前同事了解吗，我想起了他的代码水平...

[8355]

可预期的被喷了
有些事懂了就懂了 但你说出来就不好了，分明是大家排期紧工作忙忘记写了🤪，你这样说就成了恶意乱写。
每个公司有自己的工作方式，懂的自然懂。

[xiaoxiaoming01]

@ZSeptember
还是要看写烂代码是 [故意的] 还是 [不小心的] 🤭🤭

[superedlimited]

jetbrains 家的 ide 写代码的话，推荐一个插件，private note ，只能自己看到的注释 ：）

[misaka20]

大部分人蜜汁自信。
我觉得以国内复杂的需求，该写注释还是写注释，大部分人没那么能力写读性高的代码，还是老老实实地注释吧。

[wqhui]

哪怕变量、方法自认为命名的很好，注释也是有帮助的，毕竟中国人母语不是英文，看纯英文可能 get 到的意思有点不一样。而且命名一般也不会很长，几个单词就能解释清楚做了什么吗。给的开发时间充裕写详细一点，时间紧就简单写一些特别重要的

[charlie21]

今日谬论 1/1

[UIXX]

老生常谈，程序员付出了更多时间跟精力无法获得实质回报...

我一般将这类问题归为，系统性管理问题。之前的帖子有讨论过。

[Raven762]

就我们这测试都省了，每天一个变更还有不知道哪来的鬼点子，这周要的功能下周就又改了，还写个🔨注释呢

[zmqking]

当头棒喝……悟了

[tkHello]

恭喜进阶

[tkHello]

队伍壮大了一点点。 一点点 一点点 一点点 一点点 ... ... ...

[cangcang]

@changnet #29 这些道理建立在一个大前提上。公司给员工的涨薪幅度能追得上跳槽的涨薪

[Aixtuz]

目标是作品，那我怎么完美怎么来~
目标是收入，那你考核什么，我重视什么。

[mrzx]

@changnet 首先，非常认可你的说法。任何人都是可以被替代的。

但是~~~~~~替代的难度是不一样。我宁愿给你加难度或者我走了你得重构。重构得花资源，得多花钱，哪怕对于老板来说是九牛一毛。我开兴就行。

而且很多时候不是不加注释，是肯定要加注释的，良好得编码习惯很重要。要对得起自己，并且自己会整理出来一套文档，但就是不给公司罢了

要说我这样的，你们公司不要，无所谓，我们还没沦落到去你们这样的公司。。。而且现在开发工作细化，每个人就负责那么一小块部分，明显就是资本家为了开发效率和提高替代性衍生出来的产物。那真的就是码农了

要知道以前像运营商级别的业务系统，很多就只有 1~2 个人开发出来的，正因为如此，很早的程序员技术不错，因为被逼的什么都要接触，前端，后端，数据库，操作系统，内核等等。。。到现在乙方公司还不敢动他们。除非等这套系统在运营商彻底淘汰。

现在的程序员。。哎。。一言难尽。。

[pkoukk]

我觉得我代码写的像诗，不需要注释
我的同事觉得我的代码写的像屎，太过抽象无法理解
就算是诗，也有鉴赏等级的，很多经典意象和引经据典的东西，没学过他就是读不懂

所以，工期赶得不紧的时候我还是会写注释的
为了兼容水平参差不齐的同事们

[nothingistrue]

1 ，过时的注释 /文档，比没有注释 /文档更可怕。2 ，要想注释 /文档不过时，成本非常大。认不清上面这两点的程序员，要么不够老，要么是人来经验不来，要么是假技术实管理（尤其是没编码几年就混上总监的）

[v135ex]

说真的有些特殊判断加注释我可以理解，普通函数，每行代码都加就没有必要了吧。拿函数名来举例，正常来说，你函数名起的够有概括性，代码拆分够好的话，都不用写注释，直接看函数名字不知道行了

[Mandelo]

只要给时间,都好说.
没人喜欢免费下班写文档