对代码递交数量进行度量的思考

评价程序员工作的度量有哪些?

程序员的工作量评估天然就困难，虽然现在程序员的工作随着各种框架的越来越成熟，越来越接近于搬砖，但是无可否认的是程序员还是一个重度思考的行业，一个优秀的程序员，肯定能够又快又好，代码又少，速度又快的完成工作，但是现实没有那么理想，作为管理者其实是很难对程序员的工作进行检查的，很多公司因此采用了粗暴的方式，只考虑程序员的上班时长，拼命加班，这显然是不好的，所以本文提出了一种对程序员工作的代码递交数量进行考核的方法，它肯定不完美，但至少也是一个方式，所以写了本文进行探讨。

基于上班时长的度量

程序员每天耕地码字，一天12个小时，996，最后不到40岁就身体不行了，提前退休。这就是近10年互联网黄金年代（2012～2022）的常态。从程序员角度看，第一批这样做的人已经财务自由了，所以这个方式显然是不错的，但是由于互联网进入了白银时代，甚至AI自动时代，所以这个方式不可持续。天天996的结果往往是开发效率的降低，一群年轻程序员上班摸鱼，看上去公司灯火通明，但是效率并没有提高。

随着程序员的总体平均年龄增大，越来越多的程序员也难以996，所以提倡上班时长作为唯一度量，会导致损失一部分优秀大龄程序员，所以急需一种补充的度量方式。

基于代码行数的度量

Bill Gates 曾经说过，按照代码行数评价软件就像按照重量评价飞机，它固然是一个指标，但是绝对不是一个好的指标。一系列的实践也表明，片面追求代码行数反而会导致开发的软件质量的下降。

基于递交数量的度量

递交数量的问题会比代码行数好一点，毕竟当你一个个递交点进去的时候，一些明显毫无意义的递交就暴露了，递交需要写递交目的，一个盲目的递交绝对是无法通过同行评审的，所以更加客观一点。开源软件的实践也表明，基于Pull Request和Merge Request的同行审议评审递交制度有利于软件的质量提高。

基于用户评价的度量

用户满意，用户是上帝是对的。但用户作为一个群体，是内在不同的，有的人腼腆，有的人没耐心，有的人还喜欢动不动就以苹果原生软件的标准要求其他没有那么多开发预算的软件。而且由于程序员开发系统的不同，实际上无法用同一批用户对各个系统分别打分，或者说如果这样的打分存在，就是变成业务价值的度量了。

基于业务价值的度量

这是我能想到的最客观评价，也是黄金时代互联网对程序员的最好回馈，很多程序员通过拿互联网公司的股票期权，几年后抛售股票期权达到了财务自由。但业务价值是需要市场评价的，而且评价的速度较为缓慢，难以作为一种短期的评价指标使用。公司内部开发软件等一系列软件并没有简单方式评估业务价值。

针对递交数量的度量的应对

所以综上，基于递交数量的评价再加上上班时长度量，笔者认为可以较为合理的评价程序员的工作量，所以接下来就针对这个评价政策，谈谈程序员如何应对。

如何拆出尽量多的度量

既然数量重要，当然要尽量拆一点出来，所幸的是，这也是也是好的开发习惯。

重构递交

在软件开发中，程序员看起来改的是代码，但是我们都知道，代码其实是一棵抽象语法树，通过函数调用让程序的执行流再一棵棵树中穿梭。所以软件开发中，调整代码的结构实际上是一种重要工作，在新加一个功能的时候，往往代码中是没有地方放这个新功能的，这时候就需要调整代码的结构，所以显然代码结构的调整，也就是重构，完全可以作为一次递交。

数据库的schema架构更改递交

应用开发本质上再操作数据库，所以任何开发工作开始前，肯定要对数据库做一定的更改，这也完全可以作为独立的递交。

实际功能的递交

实际新功能的UI，功能推荐在一起递交，但是UI的结构调整其实也可以作为独立递交，这样拆出来以后，新功能就有两次递交了。

实际功能的异常处理

新功能显然还要考虑各种边界条件，各种约束，发生各种异常的处理，这部分也能作为单独的递交。

Bug修正的递交

这部分递交要慎重，如果Bug修正的递交过多，只能说明程序员的水平较差，但是显然我们没有任何理由将这些递交放弃，修bug显然可以作为一次递交。

一些Typo和Style修正

这部分递交最好还是一次性的，reviewer的智商都是在线的，先打错几个字，几个空格，然后再修正，这种行为太low了，还是要尊重程序员彼此的智商，这类递交要完全避免。

如何避免长时间的单行递交的度量

除了刷递交，长时间的单行递交是很亏的，尤其是你工作了一周，只有一行修正递交的情况下，所以我们可以尽量讲修正这行的思路写在一个PR的message中，通过记录自己的思考过程，检查系统的数据细节罗列来体现工作量，要相信code reviewer的智商。

如何避免无法用代码递交体现的工作

一些运维工作的确无法体现在代码中，所以我们尽量要写出免运维，也就是用户不需要培训或者咨询相关人士，就能使用的软件。

常见问题

下班前需要递交吗？

尽量按照上面的原子单元方式递交，不过如果你一天都在查bug，那就写点message，如果你在探索新的API用法，就写点message，在gitlab的activity 中，这些动作一样会被记录的。

一行行的递交这个主意如何？

我个人的感觉，这个主意很差。我建议不要做傻事，也不要假定别人是傻瓜。当然如果你很擅长当傻瓜，那也许可以尝试，并将对方拖入自己的擅长领域打败他。