之前从前说过关于更新本钱较大，之后假如有一些只是思考而不是落地实践后验证的产品的话更新或许会快一点，因此有了本期——今后就叫「瞎逼逼」系列了。
「瞎逼逼」系列不谨慎，只是个人的一些简略粗犷学习后的粗浅的看法，请注意。
故事开始：工时计件制
众所周知，程序员不是一个计件工种，但程序员的薪酬又高，因此，老板们总得有一个查核办法，能够让牛马们心服口服的承受自己的作业效果。
最低端的不明白技能的老板，会像工厂组长那样，研究一个程序员每天的打卡时刻：这个公式或许是「下班时刻 – 上班时刻 – 午休时刻 = 作业时长 = 你对作业的上心程度」，假如粒度更细的话，能够计算你每次进出门的打卡记载差值，也能够在厕所装上计时器，再完美的扣除「带薪拉屎」的时刻。
其实我自己也装过类似于 Timing 之类的用于记载电脑使用阶段前台应用的使用时刻，也便是说公司只要乐意统计，彻底能够再看看，你多少时刻在上网冲浪挂机，多少时刻写代码。乃至老板也能够像考场里的监考老师那样四处巡视，看看谁不在工位上。
最终毫无疑问，老板能够得到一个量化数据——你的有用作业时长是多少。但归根结底这也便是个乐子，你肯定不服啊——咱们多少页算得上是个脑力劳动吧，这个量化方法太像工厂拧螺丝的了吧。
强度晋级：代码行数 / 需求数量 与 Bug / 事端率
接下来，稍微上点道的老板会想到一些新的统计方法，比方「统计你一周做了多少需求、写了多少代码」又或者依据你写的「Bug 数」、「事端率」来衡量你的专业水平。
在外行眼里乍一看，这好像满足了「脑力劳动」的衡量规范，但实际上施行后，更容易变成「冲业绩」、「抢着做简略/小的需求」、「遇到作业互相甩锅」。
这个问题咱们很好举出反例：
- 假设我的需求涉及到一个比较杂乱的架构，我花了一周时刻思考边界状况、挑选技能计划、最终用 100 行搞定了这个作业；另一个搭档本着能用就行，随便复制粘贴了一个一千行的完成。
- 我这个需求杂乱度较高，所以需求一周才能做完，而别的搭档才能有限，老板只给他分配了一些边际的小需求，一天就能做完。
- 我由于担任了一个百万 QPS 的中心业务或者一个迭代了好多年的项目，本身保护本钱很高，测试也更细心，更容易发现 Bug；和一个没什么人用的体系，没有组织测试。
这三个场景中，哪个人干了更重、更难的活？但假如基于这些规范量化，哪个人的业绩又更好呢？
并且「工时计件制」实质只是无端内耗，我们浪费时刻。而这个晋级版的查核方法让每个人的作业变得更加消沉——众所周知，程序员不行能不写 Bug，出了问题第一时刻应该想的是怎么样去解决问题，下次不再犯，而不是去追责「究竟谁写的这个 Bug，你年终奖没了」。这样只会让更多的人不乐意承担责任，不乐意主动复盘。
当然，这儿其实还有一些以数量计算，容易造假的内容，比方：「MR 数量」、「Commit 数量」等等。
量化再晋级：函数重复率、与圈杂乱度、代码当量
接下来一些更在行的研制设计出了一些更高端的目标。
以函数重复率为例，上面的一个反例中说到「复制粘贴了一个一千行的完成」，那么我把「复制粘贴」给 ban 了不就行了吗，跟论文查重相同，你得保证你写出来的代码是有质量的，学会代码复用的。
不过，函数重复率更多的也是项目内的一些勘探，假如有些人「歹意引用」其他库中的代码，而不选用包的形式引入，也纷歧定能被检测到。
圈杂乱度也是类似，假设你的代码质量低下，彻底没有考虑杂乱度，属于编码一时爽，保护火葬场，那么相当于你的产出质量其实是不高的，因此有了圈杂乱度这个定义。
圈杂乱度这个概念其实早在 1976 年就现已提出了，概况能够参阅这篇文章，写的很详细：kaelzhang81.github.io/2017/06/18/…。
一个最简略的计算公式是：V(G) = E - N 2
其间，E 表明操控流图中边的数量， N 表明操控流图中节点的数量。
而得到的量化数据值，咱们能够代入表格中在进行打分：
| 圈杂乱度 | 代码状况 | 可测性 | 保护本钱 |
|---|---|---|---|
| 1-10 | 明晰、结构化 | 高 | 低 |
| 10-20 | 杂乱 | 中 | 中 |
| 20-30 | 十分杂乱 | 低 | 高 |
| 30 | 不行读 | 不行测 | 十分高 |
这样看下来就比前两个只考虑数量、不考虑质量的靠谱的多。
相同的，当咱们衡量一次改变杂乱度的时候，也能够不参阅代码行数，而是选用一个叫做「代码当量」的东西。很奇特，这东西其实刚提出没几年，并且是由一家公司提的，但他说的好像又比单纯的代码行数要靠谱一些，关于这个名词能够阅览：「代码当量」目标解读看这一篇就够了 。
这样确实有用避免了注释、Markdown 玩家以及 code style 专家混代码改变行数，能够更好地协助你衡量脑力劳动量。
这就结束了吗？
就算咱们上了强度，想要造假的人依旧能够造假，比方说，我就开个自己的分支，先大刀阔斧的改，跑不跑的起来不管，然后 MR 我合我自己，之后下一个 MR 再把这些都改回来，岂不是双倍的高兴。
关于公司等级的目标来看，这样的问题很难避免，无论是怎么样「科学」的量化目标，都面对道高一尺魔高一丈的应战。
当然，我并不是彻底反量化的，事实上，没有量化数据根底更容易堕入「向上管理优于一切」。在我看来不能以这个冰冷的数字作为一个人作业量的悉数去查核，也不能彻底以 Leader 一个人判别为准，更多的是基于 Leader 对每个人的作业分配辅以他的对应产出来决议，比方：咱们确实不看 Bug / 事端数，但假如一个事端便是人为造成的，十分低端，乃至是由于不合规的操作导致的，那么必定会被追责。但假如一个事端只是由于我们都缺乏相关的经历，那么事后总结，下次注意就够了，不用追责到人。
此外，在上面介绍的查核目标中，咱们还能够发现，好像疏忽了关于「需求调研」、「体系设计」、「代码自测」的评估，乃至有些团队在排期时都纷歧定算上了，而实际上这几点在软件开发过程中乃至比「动手写代码」更为重要。比方我一直倡议技能计划明晰化，要做到「这个计划拿出来，我叫另一个同学依照计划履行，和你自己想的一模相同」，在体系设计阶段就得想到或许存在的问题和落地的计划。
但是在实际作业中，我们往往会忽视这一部分，从某一种视点上来说也是由于这些作业很难被量化价值，每当这种时候，我都会想起扁鹊三兄弟的故事：
魏文侯问神医扁鹊：你们兄弟三人谁医术最好啊？
扁鹊说：大哥最好，二哥次之，我最下。
魏文侯说：为什么这么说？
扁鹊说：我大哥在人家未发病之前就把病根给除了，防患于未然，因此名望连家门口都出不去；我二哥能在人家病况刚起时就给治好，就好像他每次看的都是小病相同，所以他的名声不出当乡本土；我呢，看起大病来，又是在经脉上穿针放血，又是用些猛药贵药，又是开刀做手术，所以人人都觉得我的医术最高明。
总结
「瞎逼逼」系列第一期结束，文章中大部分都以个人 BB 为主，本文其实只是一个很抱负的讨论，由于在实际（从前）带领团队的过程中，即便我着重「不看考勤」和「不看 Bug 率」，大环境如此的状况下，我们的思维习惯也很难改变。（是不是一种「当 Leader 救不了我国码农」）
