考核和代码量统计

前不久看到一个G家升值相关的帖子提及代码量。 我想问下大家在各自的部门考核中都有用到什么代码统计的工具。之前用过gerrit自带了些功能，现在公司用github。 我还是打算在组内用代码量和一些提交细节做个数据参照来观察组员的engage程度，效率和churn。

开源的工具我是不知道，但大公司内部有一些工具会显示: number of diffs, number of significant lines, days to close, number of comments etc. 我个人觉得这个是可以作为qualitative的指标，而不是非常精确的硬性排名。举个例子，很少或者很多代码量的outlier可以单独对待，不仅要看代码量，也要看iteration的次数，每个diff本身在干什么，summary里写了什么，test plan写了什么，如果有人能这么去gaming system，那他一定在这方面得花很多功夫。说到底，是tooling设计的有多好，考虑的因素是不是仅仅只是单一的diff数量或者代码行数。

yuqinlear 发表于 2020-10-16 09:06
代码量固然不能作为指标，但是是少数可以持久量化的依据。 当然我的目的更多是让大家有点pressure，这wfh时 ...

如果每个项目在计划的时候有costing就可以避免划水然后夸大自己做的
如果光看代码量，有很多办法可以game the system其实...比如写一个script auto generate一堆没什么用的refactor

3a1pball 发表于 2020-10-16 04:52
follow-up问哪些metrics最重要，如果不看代码量的话。按照公司的维度比如people，direction这些都比较玄乎 ...

官方说法是perf是没有公式的，我的理解是这是一个判例体系。metric或者别的故事用来支持“xx dimension达到下个level”（一般这个calibration的时候找个level n+1的例子就好）或“xx dimension非常outlier”（一般这里比较多会用metric，我见过的例子一般N至少是2，大多情况是3），以此决定最后的rating
我个人的经验是ic4是最后一个还看代码量的level，之后就代码量再多也不算多，代码量奇少无比可能是问题，但是一般不用看代码量看impact（ie项目有没有deliver，具体谁做的哪部分）也能看出来

我司内部有一些tool
. .и但是至少manager training说的是performance review不应该看代码量，除非代码量非常的outlier（是average的N倍或average的1/N）

hxtang 发表于 2020-10-15 13:32:58
我司内部有一些tool
但是至少manager training说的是performance review不应该看代码量，除非代码量非常的outlier（是average的N倍或average的1/

follow-up问哪些metrics最重要，如果不看代码量的话。按照公司的维度比如people，direction这些都比较玄乎，怎么评价两个不同project对组织的贡献程度？这里的N怎么算，多大算outlier？

[quote][url=forum.php?mod=redirect&goto=findpost&pid=13680817&ptid=678589]3a1pball

代码量固然不能作为指标，但是是少数可以持久量化的依据。 当然我的目的更多是让大家有点pressure，这wfh时间长了组里面划水的情况显现，他/她给你说这个refactor那个决定比较耗时，我也不可能逐一去反驳。 适当的peer pressure让大家mindset有个正向的调整。

如果所有已项目计划作为依据， 在agile环境中我作为lead会丧失灵活性。每天的临时任务和优先级微调也频繁，这完全需要组员自身ownership来保证有效交付。  如果game system，明确量化环境下肯定比做项目预算更难game。  当然一方面我也避免扯下脸去争执你这个5point ticket怎么做了一周半。

yuqinlear 发表于 2020-10-17 00:32
如果所有已项目计划作为依据， 在agile环境中我作为lead会丧失灵活性。每天的临时任务和优先级微调也频繁， ...

如果组员对整个项目有ownership的话不用因为临时调整去调costing的，总会有的部分估多了有的部分估少了，但大体差不多就行，如果明显划水也不是这一点点误差会影响的。项目的costing（包括如果因为变故需要改变costing）我组里是managers和tl会参加做的，不是一个ic能随便game的。

但如果你组里组员做的都是零散任务，没有ownership，确实比较难从costing来度量。但从另一方面讲，如果是这种情况，假如我是mgr我会更担心没有组员ownership导致的难以motivate people/hold people accountable，而不是因为wfh缺乏监督导致的问题。其实就算不wfh的时候好了，一般也不会盯着组里的人有没有在干活的。只要最后能deliver就算组员天天在我边上看游戏直播（我是真的有同事这样..）我也无所谓。交不出结果就算时时刻刻在coding，写了几万行代码也没用啊。

补充内容 (2020-10-17 03:41):
我其实不反对manager用各种代码量相关指标来identify一些outlier，但是不是就把代码量拿出来说话，而是深入进去看一下具体是什么情况，有人划水还是有blocker再具体处理

代码量（行数，或者commit数），都不要作为perf的量化标准，或者不要公开提出来是。很容易被abuse, 变成注水提交代码。这个很容易做到。
做项目最重要的还是项目本身的impact.
但是manager可以把提交代码的活跃度，作为自己考核的标准。没有硬性的量化指标。但是需要保持一定的活跃度。