文档支零破碎代码几乎没有注释是大厂常态吗

model的定义注释比较重要，涉及业务逻辑的核心

某些特定feature的fix和work around需要注释，这些方便后来的人搞清楚你在fix什么问题

其他很多代码不太需要注释，像framework，design pattern，这些依赖自己对这些programming的concepts和flow的熟悉

你好，是meta员工吧，meta产品组的代码是所有公司里最烂的没有之一

有时候没有文档是因为
1. 没时间update
2. 不是当时priority (例如没有正式design review，或是组近期没有要招新人，因此短期不会有人看)

diff by diff小规模的改动可能都能看懂，但累积起来整个codebase那个量，各种堆叠上去的逻辑，看了很费劲
经常只能一一去捞diff history，看当初改动是什么目的...

匿名账號 发表于 2022-08-14 21:03:21
认真讲 如果楼主研读过clean code这本书，书里是不建议加注释的。代码本身从变量名到各种命名，都应该是self explanary。每一个method just does one thing。

年代久远但仍然经典的一本书。只不过并不是条条皆为标准，起码加注释我觉得还挺重要的，命名lines of code restriction和self explanatory是两个冲突的事情，我敢说大部分自认为清晰的命名再给两个月自己都不认识了

匿名用户 发表于 2022-08-15 02:36:47
你好，是meta员工吧，meta产品组的代码是所有公司里最烂的没有之一

meta可以找对应的diff和blame看改动的理由

我们组里的代码就没怎么出现forloop 无论什么 全用lambda

大厂==Meta？

这是一个选择问题，maintain good quality codebase 是有cost，而且很大。并不是大厂没有这个能力。

我一般选组会有意避免这个问题，我在fb选组和换组会看以下这些，

• codebase 写了多久了，
• 每个组员的code review，一般看3个diff，作者是什么货色就清楚了，
• 看每个组员的linkedin profile，
• 尽量做新的project，
• 找到组里代码质量最高的人，准备互相抱团，
• 找出codebase的design flaw，为干仗做准备，
• 找到组里代码质量差的人，这些是PUA的对象，
• 和skip聊一下，委婉的说，codebase质量不行，我很纠结要不要来，先立好牌坊，建立人设。
  

eemmaa 发表于 2022-8-15 20:01
我们组里的代码就没怎么出现forloop 无论什么 全用lambda

这个和质量没有关系，Haskell压根就没有loop。