衡量开发人员的工作量一直是让很多管理者头疼的问题，开发工作的不易量化让对于开发人员个体的工作变得难以评估。这时许多管理者为了图方便，直接只用代码行数来评估开发人员的工作量，这让很多开发人员都苦不堪言。

在开发工作中，代码行数体现的数据最直观，这点我们不能否认，它一定是一个可以参考的维度。但是如果仅用代码行数来评估开发人员的工作量，甚至以代码行数来设定 KPI ，这无疑是非常错误的行为，其带来的后果也是非常严重的。

首先这并不是一种非常专业且科学的评估方式，甚至会让制定该规则的人显得有些「业余」。亲自有过项目经验的开发者和技术管理人员应该都知道，一个项目中真正耗费精力的地方是框架搭建、功能需求分解，以及后续的功能测试，真正去写代码的时间占比其实并没有多少。



其次，如果仅用代码行数来评估开发工作量的话，团队所面临的最大难题便是垃圾代码的增加。团队成员为了完成 KPI ，在本就能 20 行写完的功能上加入各种注释和无用的函数，甚至直接往项目里面贴源码，而不去考虑代码的耦合性、可读性、可维护性、重用性等。虽然 KPI 完成了，但开发人员逐渐降低的效率、延误越来越久的项目、质量越来越低的代码，团队在进行着完全没有必要的内耗，会让整个项目越来越艰难，和最初的目的背道而驰。



比尔盖茨曾经总结过这么一句话，“用代码行数来衡量编程的进度，就如同用重量来衡量飞机的制造进度”。没错的，代码数量并不等于代码质量，一味的追求写了多少行代码没有多大本质意义，关键在于是不是真的解决了实际问题。而只用代码行数来评估工作量，无疑是管理方式落后的表现。不客气的讲，这样的管理者思想仍旧停留在农耕时代，高产出=高价值，这样的等式在软件研发领域是不成立的。

那么，一个合格的管理者到底应该如何科学的评估开发人员的工作量呢？

目前比较常见的方法是基于 WBS（Work Breakdown Structure）的工作量估算，也称作自下而上法。通常的估算步骤如下：

寻找类似的历史项目，进行项目的类比分析，根据历史项目的工作量凭经验估计本项目的总工作量；
	
进行 WBS 分解，力所能及地将整个项目的任务进行分解；
	
参考类似项目的数据，采用类比法或专家法，估计 WBS 中每类活动的工作量；
	
汇总得到项目的总工作量；
	
与第1步的结果进行印证分析，根据分析结果，确定估计结果。
此外，也有 Putnam 模型、 COCOMOⅡ模型、IBM 模型等科学的估算方法，虽然看起来比较复杂，但比「一刀切」式的只看代码行数的评估方法要有效的多。

始终追求高效开发协作的 Gitee 企业版也在和大家一起探索更科学、合理、公正的工作量评估体系，Gitee 企业版刚上线不久的「统计」模块将多维度可视化的指标独立出来，让管理者更全面、直观、立体地了解项目进度级团队情况。



「统计」模块在未来仍将会是 Gitee 企业版的重点，后续我们会对该模块持续改进，提高大家的效率是我们不变的目标。

 

    

                    

                    

                    
                    
                    
王二是一个非常优秀的程序员，别人100行代码才能完成的事儿，他往往10行搞定，别人一星期才能搞定的任务，他往往半天做完。王二不想揽那么多事情，就总是在每周快结束的时候才工作，其他时间都想办法娱乐。
领导很是看王二不惯，可又没什么办法。后来领导一统计，这王二的代码量是整个团队最少的。于是，有一天，领导就颁布了一条规定：要按代码行评估绩效，每周统计大家的代码行数，平均前三加绩效，年中和年底根据绩效发奖金。
王二一听，心里明白怎么回事儿。不过他也不生气，很快想到办法：把一行代码能完成的功能，写成 10 行。比如一个给定两点计算矩形面积的函数，原本他写成下面这样一行代码：
新规定颁布后，他会写成这样：
一行变40行！
王二心想，娘希匹，看哪个龟孙的代码行数能超过老子！
果然，年中一算绩效，我的天呐，王二拿的奖金最高！
领导一看，不对呀，以往王二的代码量最少。于是，他就来查代码。这一查，勃然大怒，看出其中蹊跷，就取消了王二的奖金，还罚了王二几百块钱。
领导出了口气，不想和王二计较了，可又不想随便废掉新政，觉得那样太下不来台，就左思右想，琢磨改进的事儿。
终于，给他想到一个绝妙的办法，于是颁布了一个新规定：还是按代码行数评估绩效，规则更改为，在完成工作任务的同时，谁的代码行数最少，谁的绩效最高；谁的代码行数最多，谁的绩效最低。
这下，很多程序员傻眼了，没办法，还得适应新龟腚呀，就开始改变，每天都猛琢磨，怎么把原本200行代码可以实现的功能用一行来完成。
结果呢，整个团队，全变成了思考者，很多人一个月也不写一行代码，一年写不了10行。王二更绝，一年就写一行！
最后，大家任务都没完成，谁也没拿到奖金。
这下，领导又发飙了！
于是，苦思冥想一昼夜，颁布了一个新规定：还是按代码行数评估绩效，规则更改为，在完成任务的前提下，代码行数量越靠近均位数，拿的奖金越多。
这个法令一出，大家死活想不到办法，整日里愁眉苦脸。
要说还是王二聪明，熬了一夜，抽掉13包长沙后，写出来一个代码行归一工具：只要你输入一个数字，这个工具就能把你的代码拆成那么多行。比如你输入300，它就可以把你的一行代码拆成300行，还不影响功能。
王二乐于助人，编译了一个写死300行的工具发给大家使用。这样，每个人提交代码前，都用这个工具跑一下，工具自动完成折行、加空行等操作，把代码行数调整到300行。这样，大家每周代码行数量都变成了300行，半年下来，都有望拿到最高奖金。
然而，领导狂飙啦！天底下就不该有这种事啊！
于是，领导就又来查代码，结果发现，每个人的代码都跟加过扰似，根本读不懂！
最后，领导两天两夜没睡觉，第三天早上，发布了新规定：废除按代码行数评估绩效。
大家一听，都心安了。
然后好景不长，第四天，领导颁布了一条新规定：从今天开始，大家的绩效，按每千行代码bug数来计算，bug越多，绩效越低，bug越少，绩效越高。
王二一听，哇呀，这下难了，可他心高气傲，心想老子还能想不出办法来？于是每日里别事不干，就琢磨怎么降低每千行代码bug数……
一晃半年过去，王二一行代码没写，结果却发生了意料不到的事情：他的每千行代码bug数为0，最低，绩效最高！
王二大笑三声，跑去找领导要奖金，领导难以承受巨大的冲击，狂喷三分钟鲜血，被120接走了……

这是我在知乎回答的一个问题，感兴趣的可以戳阅读原文，看这个回答后面各种有趣的留言。

◇
最近相关文章：
股权和更高的薪资应该选择哪个？
程序员职业规划的3个锦囊
  

最近做一些批量化的改造，需要预估团队整体工作量。因为按业务本身复杂度来统计需要熟悉所有代码，执行上很难操作，因此用代码行数来评估工作量
研究了几种工具和方法

python的line包

直接安装pip install line-counter，以goredis目录为例子

wjcdeMacBook-Pro-2:redis wujingci$ line
Search in /Users/wujingci/go/src/github.com/go-redis/redis/
file count: 68
line count: 17776
wjcdeMacBook-Pro-2:redis wujingci$ line -d
Search in /Users/wujingci/go/src/github.com/go-redis/redis/
LICENSE                                                    25
Makefile                                                   20
README.md                                                 143
bench_test.go                                             220
cluster.go                                               1439
cluster_commands.go                                        22
cluster_test.go                                           880
command.go                                               1048
command_test.go                                            60
commands.go                                              2175
commands_test.go                                         3290
doc.go                                                      4

缺点在于只能统计总文件，肯定会有一些配置文件，会导致估算不准确

CLOC工具：https://www.npmjs.com/package/cloc

安装nodejs后直接安装即可。直接可以统计各种语言的行数，以goredis的目录为例子

xxxMacBook-Pro-2:redis wujingci$ git ls-files| xargs cloc
      70 text files.
      70 unique files.
       3 files ignored.

github.com/AlDanial/cloc v 1.85  T=0.14 s (466.1 files/s, 123562.4 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
Go                              64           2899            594          14085
Markdown                         1             31              0            112
YAML                             1              4              0             16
make                             1              5              0             15
-------------------------------------------------------------------------------
SUM:                            67           2939            594          14228
-------------------------------------------------------------------------------

这个方法可以较快统计出内容甚至把编程语言也给明确了。缺点在于统计不够定制化。比如go服务引入了govendor，那实际有效代码行数很有可能被误统计进去

自己写bash代码

去注释：find . -name "*.go"|xargs cat|grep -v -e ^$ -e ^\s*\/\/.*$|wc -l

去vendor find . -name "*.go| grep -v vendor"|xargs cat|grep -v -e ^$ -e ^\s*\/\/.*$|wc -l

改动更自由，需求更定制化

代码量的直观体现
虽然代码行并不能说明工作量，但是，大致的评估还是有一定的作用的

今天需要统计VB.net项目的代码的行数，顾专门做个记录~

open Solution 以后，我们运行查找和替换 --快捷键是 ctrl + shift + f
查找项  输入

^b*[^:b#/]+.*$


查找範圍是整個solution
然后选择正则表达式  具体如图所示



在find result 的窗口  我们可以看到  在最后一行有了统计结果 ：


哇 好多行代码啊~、
─=≡Σ(((つ•̀ω•́)つ