公司统计代码行数的逆天逻辑

[sqfphoenix]

之前发了个帖子吐槽公司统计代码行数 前情提要

经过我两个月的奋斗，各种水行数，甚至突破自己底线贴工具类到代码里面，发现怎么都比不过别人的代码行数，今天才发现，原来公司统计是会把 merge 提交的行数也全部计算进去，而我每次拉代码都用的 rebase ，怪不得我比不过别人啊，合着我写的代码全都算到别人的数据里面去了

从今天开始，继续突破自己底线，每次提交必选 merge ，反正 git 提交历史已经是一个粪坑了

[Yuanlaoer]

@nevin47 我说 gitignore 那个是开玩笑讲的。
像你讲的，“千行缺陷密度”，如果能把这三个名词定义清楚并在公司内达成共识，那这肯定是一个非常高质量的指标。

来吐槽的人，显然所处的团队的统计方式有很多不合理的地方，都不用说 `.git` 和 `.gitignore` 了，像是`node_module` 或是其他包管理可能都没做特殊处理，还可以用各种 lint 来操作。而行数统计就是直接粗暴叠加每个 commit 中的行数。

一句话总结：某人把一个连名字都没搞明白的理论直接搬到团队里，实际应用时一塌糊涂

[xinshoushanglu]

哈哈经典套路

[nevin47]

@Yuanlaoer #81 我觉得你说的是正确的，但是如果千行缺陷密度都应用不好的公司，那流程上可以称为是“小作坊”，应用任何质量管理工具都会出现各种乱象……

[Yuanlaoer]

@nevin47 嗯，听起来你在这方面很厉害，或比较幸运，接触到的人都是专业性很强的。很羡慕。

我体验过牛逼老板领导，即使对每一个 commit message 都有极其苛刻的要求。这种工作氛围下，即使被批评，我也觉得是良性的，会让我更想多工作。但，如果你体验过外行来领导的话，那这种“千行 BUG”的统计就变成噩梦了。