衡量开发人员的工作量一直是让很多管理者头疼的问题，开发工作的不易量化让对于开发人员个体的工作变得难以评估。这时许多管理者为了图方便，直接只用代码行数来评估开发人员的工作量，这让很多开发人员都苦不堪言。
 
在开发工作中，代码行数体现的数据最直观，这点我们不能否认，它一定是一个可以参考的维度。但是如果仅用代码行数来评估开发人员的工作量，甚至以代码行数来设定 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
 改动更自由，需求更定制化

作为开发人员，你会听到许多有关“代码行数”的令人难以置信的疯狂理论——不要相信他们！以代码行数作为决策依据是一件非常荒谬的事情。在极少数情况下，代码行数可能还有那么一丁点意义，在绝大数情况下，代码行数什么都代表不了。根据代码行数做决策就好像按照页数评价书籍的水准。
 
有些人可能会认为，应用程序中的代码行越少，就越容易阅读。这句话只有部分正确，我认为代码可读性的度量标准包括：
 
代码应具备一致性
代码应具备自我描述性
代码应具备良好的文档
代码应使用稳定的现代功能
代码不应过于复杂
代码的性能不能有问题（不要故意编写速度过慢的代码）
 
如果减少代码行数会影响到上面任何一条，那么就有问题。实际上，基本上减少代码行数都会影响到上面的标准，因此总会出问题。不过，如果你能够设法满足上述条件，那么代码行数就是完美的，根本用不着统计数量。
 

 语言没有好坏之分
 
除了PHP（开个玩笑）。
 
总是有人会说：
 
“C比X更好，因为C的性能更好。”“Python比X更好，因为Python更简洁。”“Haskell比X更好，因为Haskell是外星语言。”
 一言以蔽之，比较编程语言本身就是无稽之谈。它们是语言，又不是口袋妖怪。
 
别误会，语言之间的确有差异，只不过“一无是处”的语言毕竟是少数（尽管有很多过时的语言）。每种语言都有其独特的优点，从这个角度来说，语言就好像工具箱中的工具。螺丝刀能够胜任锤子做不到的事情，但是你会说螺丝刀比锤子好吗？（显然锤子更好使）。
 
在谈论如何评估语言之前，我想先说明一点。在少数情况下，语言的选择确实很重要，某些语言显然无法处理某些情况。如果你编写前端代码，那么连选择语言的权利都没有。在某些特定的情况下，性能很重要，那么就不能选用X语言了，但这种情况很少见。通常，语言的选择都是项目中最不重要的问题之一。
 
以下是我认为在选择语言时，你应当考虑的核心因素（优先级从高到低）：
 
在线资源的数量（比如StackOverflow上的问题数量）
 
开发速度
出错的概率
软件包生态系统的质量和广度
性能特征
招聘人才的难度（对不起，COBOL）
 
还有一些无法控制的紧密联系。如果你从事数据科学工作，那么就需要使用Python、R或Scala（也许是Java）。如果是一个业余项目，那么就随心所欲选择自己喜欢的。只有一条规则我觉得没有商量的余地：如果遇到的大多数问题都无法通过StackOverflow直接解决，那么我会拒绝使用这种语言。不是说我没有解决问题的能力，而是我觉得不值得花那么多时间。
 
读懂别人的代码是一件难事
 
读懂别人的代码是一件困难的事情。Robert C. Martin在“干净的代码”中谈到了这一点：
 
“实际上，读代码和写代码所花费的时间之比远超过10：1。在编写新代码的时候，我们一直在阅读旧代码。……[因此，]我们的代码应该易于阅读，易于编写。”
 很长一段时间里，我一直以为自己不善于阅读别人的代码。随着时间的流逝，我意识到几乎每个程序员每天都在为阅读别人的代码而苦恼。
 
阅读别人的代码就像学一门外语。即使你很熟悉某种语言，但仍然需要使用别人的不同风格以及体系结构。而且我们一般都会假设写代码的人贯彻了一致性和可靠性，但有时并非如此，这确实是一个很难克服的问题。但是我发现了很多有帮助性的技巧。
 
阅读别人的代码可以极大地提高你阅读代码的能力。在过去的两年中，我查看了很多Github中的PR。每读一个PR，就会觉得阅读别人代码的能力又提高了一点点。Github中的PR特别具有帮助性，原因如下：
 
可以随时练习，只需找到自己想贡献的开源项目即可。
在一定范围内练习阅读别人的代码（功能性的PR或改bug的PR）。
注意所需的细节，努力读懂每一行。
 
还有一种对阅读别人的代码有帮助行的技巧，这种技巧更加独特。我想到的这种技巧可以大幅减少阅读陌生代码库所需的时间。在看到我想阅读的风格的代码后，我首先我会打开vi，然后开始用项目中使用的风格编写代码。这样会减少对代码的陌生感。即使我在Github上浏览随机项目，我也会这样做。一起来试试看吧。
 
你永远无法编写出“完美”的代码
 
在加入团队工作之前，有4年的时间里我这个开发人员都是“独行狼”。在大多数时间里，我会假设每位程序员编写的代码都是完美的。我以为稍加努力和假以时日，我也会编写出“完美”的代码。
 
以前，我曾经常常为此而感到焦虑。在加入团队后，我很快就发现没人能够编写“完美”的代码。但是，进入系统的代码几乎总是“完美”的，为什么会这样呢？答案就在于代码审查。
 
我们团队拥有非常出色的工程师。他们都是最有能力，最有信心的程序员。如果有人建议提交未经审查的代码，那么我们团队中的每个成员（包括我）都会群起而攻之。即使你觉得自己是下一个比尔·盖茨，你也会犯错。甚至都无需上升到逻辑上的错误，就连错字、漏字的问题都无法避免，这些都是你的大脑无暇顾及的问题，所以需要由别人来帮你检查。
 
努力与注重细节并乐于指摘你的代码的人一起工作。虽然刚开始听到批评时，你会觉得很难受，但这是持续改进的唯一方法。尽最大努力避免在代码审查过程中产生抵抗情绪，也不要发表针对个人的评论。努力做到对事不对人。
 
审核代码时，如果代码的作者做出的选择我并不熟悉，那么我会立即通过Google查看他们的选择是否与流行观点不符。我并不是说流行观点永远是对的，只不过流行观点是默认的选择。如果有人决定不采纳流行的观点，那也很好啊，只不过我需要知道这是否合理。在审查代码时，有一点至关重要：你必须了解决策背后的基本原理。另外，用“初学者的头脑”看同样的问题，往往可以发现被这个人抛诸脑后的东西。
 
程序员的工作并不意味着每天要坚持8个小时的编程
 
一般的开发人员或“伟大的”开发人员每天需要做多长时间的编程工作呢？这是一个非常普遍的问题，但是从来没有人给出明确的答案。
 
每天写代码的时间超过4小时的人非常少。
 
不赞同这一点的人要么是个例外，要么公司应该珍惜他们。编程是一项耗费精力的工作，需要精神高度集中。要求程序员每天写5-8小时的代码是不近人情的做法。在极少数情况下，为了按时完成任务或为了加班费，有人会延长工作时间，但这种情况很少见。其实我这里说的“极少数情况”的意思是几乎没有。如果由于公司计划上的问题或招聘的人手不足而导致你加班，那么请不要容忍。
 
坦白来说，每天编写8个小时的代码，对你和公司都没有好处。如果你的老板有这种要求，那么只能说他目光短浅，因为从长期来看，这种高强度的工作对生产力和心理健康都有恶劣的影响。
 
请注意，我并不是建议你每天只工作4个小时。通常，我们应该把剩下的4小时用在如下工作上：
 
研发与工作有关以及无关的主题
与同事讨论工作
帮助其他努力工作的同事
计划未来的工作
代码审核
开会
 
除此之外，我强烈建议你在白天的工作时间里定时休息并锻炼身体（即使只是短暂的锻炼）。事实证明，运动对缓解精神疲劳有很大的帮助。我发现，我在无法集中精力的时候，锻炼特别有帮助。