公司通过统计 gitlab 提交代码行数来判断工作饱和度

把用到的包自己复制修改一下

第一次听到这个的时候，作为程序员第一反应是不好，这岂不是会朝着代码灌水的方向发展。但后来领导问，那如果不用这个，你有其他可量化、可考核的指标来衡量程序员的产出么。想了好一会，只能承认这种方式也不能说是完全不合理，只是需要一些补充信息来尽量完善这种考核吧，比如楼上提到的需要代码走查、解决 bug 时的代码行数可引入 bug 难度来综合考虑等

以后不用注解了
每个 bean 多写点字段

可能快黄了，公司领导已经没事干了

我们就在用。老板不懂可以原谅，技术负责人不跟老板解释清楚统计这玩意没有用，不可原谅

@besto 华为那代码质量做案例也太不合适了。

至于这个做 kpi 基本是蠢的没边了。一是想把代码写短是很难的，想把代码写的清晰漂亮更难，但是这些基本都和这个 kpi 背道而驰。二是 test 想写几百行几千行真的和玩一样，你 reviewer 难道还能让我少写几个 test case ？

我这也有，但是是偷偷搞得，统计脚本是我写的（🐶）

我有一个简单的办法，以遵循 Google 代码风格指南为理由，每周把一行字数限制逐渐下调，直到 80 为止。逐渐调整的理由是可以减少每次影响的行数，避免影响其他同事工作。也可以和同事分工，每周换个人调。

到了 80 以后，找个同事说说 80 换行太频繁了，影响代码阅读，再逐渐上调至 200 。

到了 200 再说行太宽了，并排 code review 屏幕放不下，还是 Google 有先见之明，再逐渐改到 80 。

希望这个时候傻逼政策已经取消了。

想起一个好玩的事情。早些年玩花指令的时候，把一行汇编代码扩充成几十几百甚至无数条汇编代码。

gcc -E

利好前端呀

多封装些用不到两三次次的函数，问就是层次结构清晰。
下班前查查今天的行数，不够就抄几个工具类🎉

感觉你们公司要黄了……

这是冲着倒闭踩死油门。。

挺合理的，我可以一个月写几万行垃圾代码

现在就去一个一个把 lambda 拆了

请像一个大四实习生一样装出懵懂无知，不要使用框架了，自己手搓，不要使用装饰器这些简洁高效的东西，要手搓每一个功能的数据库、缓存、内存的连接和释放，自己想办法写一个废话文学版本的代码生成器，慢慢地放弃使用中间件这些东西，重写每一个第三方依赖包，问就是在审核依赖包安全，自己手搓这代码量不是质的飞跃？

没东西写就写单元测试啊