如题。
我想了解下统计团队成员的代码量是不是很常见？如何操作比较合理？
谢谢～
非常不常见，基本上很少会有这种操作。
疫情时期居家办公的时候前司会这样操作。但是我们的操作是增删文件或者代码，很容易就敷衍过去。
2 个赞
我不是程序员，好奇代码量是什么？和字数类似吗？
类似于统计办公文员每天在word里的打字数 
代码的数量好统计但质量怎么评价，有时候100行的代码都不如两三行~
立马想到一千行的 if-else
我虽然不是程序员，但是我是通信专业的，好像大家都追求简洁代码实现功能吧。在这种统计方式下不是吃亏吗。
以前我看過有人問過幾乎一樣的問題
後來他被發現是打算以此作為碼農的績效，愈多代碼愈勤勞之類的
然後就沒有然後了，被噴的老慘了
建議用 行數 取代 代碼量
然後用的行數愈少、效能愈高，編程能力愈出色
做这种事儿的负责人，不是不懂技术，就是蠢。。。
同意
是的。
我们公司的产品可以用来统计「代码当量」（基于语法分析而非代码行数，支持给重复代码、模板代码降权），目前一些客户用我们的系统辅助评估外包员工的工作，还有一部分客户想要对比研发团队跟行业内其他公司的差距。
实际的操作中，还需要结合需求管理软件（比如 Jira、禅道、TAPD 等）、代码质量工具（比如 SonarQube）、VCS（例如 Git）的数据，如果你想了解更多相关的信息，可以在网上搜索「研发效能度量」。
BTW，GitHub 个人首页的贡献热力图受到开发者圈子的欢迎，说明开发者并不反感被度量「代码量」，并且也认同「代码量」能从一定程度上反映他的工作贡献度。那么，你在统计完代码量之后，基于数据来做什么决策，大概率决定了研发团队对「度量代码量」这件事的态度。
我们不统计代码量 统计 jira 评论数量 和 代码提交次数
呵
代码提交次数？那不得写一行代码提交一次
說白了，會有這些現象的發生
就是技術和腦力活被視為了純粹的勞動
既然是勞動就有計件、計量的需求標準
哪個組織這麼不把人當人看，我看還是趕緊離開比較好
讓他們自己去跟GPT聊天
前几天正好在阮老师博客里看到了一段话，摘过来正合适。
正如马丁·福勒（Martin Fowler）所观察到的那样，程序员的编程生产力无法有效地衡量，因为它不存在。
软件开发并不是一项必然会产生任何东西的活动。
假设你有两个开发人员在同一个项目上工作，并且偶然地，他俩在同一天接受了相同的任务。
甲写了一个1000行的框架，完美地解决了这个问题。代码编写良好，并经过充分测试，每一步都有详细记录。
乙则是当天去了公园，一边喂鸽子一边思考问题，然后漫步回到办公室，删除了100行代码，部署了更改…问题就解决了。
请问谁的生产力更高？
回答是，这不重要。重要的是乙解决了问题，同时降低了团队的长期维护成本。甲也解决了这个问题，但是他通过增加代码，增加了维护成本，因此（在其他条件相同的情况下）他的解决方案较差。
我们能说，乙具有更高的生产力吗？显然，很难找到编程生产力的正确衡量指标。
我认为，优秀的软件开发者所做的就是解决问题。但是，生产力的衡量指标，比如代码、文档、数据等等，都只是解决问题的工具，并不是解决问题本身。
2 个赞
不一定，甲的代碼在解決問題這件事上，可能是系統性的
意思是，甲的代碼貢獻可能大幅提高了整體的魯棒(穩健)性
而乙的代碼可能僅僅只是根據當下情況，做出合理的增刪改進而已
維護成本不一定是乙低甲高，甚至有可能是反過來的
不過考慮到甲用了1000行，乙還砍了100行，還是當我沒說吧 