都 2020 年了，还在用代码行数评估开发工作量吗？

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

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

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

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

比尔盖茨曾经总结过这么一句话，“用代码行数来衡量编程的进度，就如同用重量来衡量