PRolice
v0.0.1 -
ooooooooo. ooooooooo. oooo o8o
`888 `Y88. `888 `Y88. `888 `"'
888 .d88' 888 .d88' .ooooo. 888 oooo .ooooo. .ooooo.
888ooo88P' 888ooo88P' d88' `88b 888 `888 d88' `"Y8 d88' `88b
888 888`88b. 888 888 888 888 888 888ooo888
888 888 `88b. 888 888 888 888 888 .o8 888 .o
o888o o888o o888o `Y8bod8P' o888o o888o `Y8bod8P' `Y8bod8P'
------------ What you gonna do when they come for you -------------
ProLice （ PR警察的收缩）是一种工程管理工具，用于取消和测量GitHub存储库中的请求数据。
向Sourcelevel及其关于指标的出色博客大喊（其大多数由此应用程序实施）：
作为开发工作流程的一部分，许多工程经理促进拉力请求。这是一种合并的做法，带来了很多好处。它包括将分支的更改与存储库的基本分支（常规称为主）进行比较。
拉请求提供有用且可操作的指标。但是，遵循错误的指标会导致扭曲，并带来比利益更多的缺点。经理可以使用拉动请求指标来理解团队动态，并在事情脱离轨道之前适当地采取行动以纠正行为。
Prolice旨在从目标存储库中收集拉动请求样本并分析它们，以便洞悉集体项目的工作流程。
再次大喊到Sourcelevel的博客文章（认真地，如果您还没有，请阅读）：
在进入指标之前，我想发出免责声明：不要使用这些数字来比较个人。
有时，一个难以找到的错误需要修复单行代码，而单线需要一周的工作。在我的职业生涯中，我已经见证了很多次。
我还目睹了工程经理，鼓励开发人员开放提取请求，并进行太多的更改，以至于审查是不可行的。他们通常会强调，通过告诉每个人，这些开发人员都有生产力，当其他人拿最简单的开发人员时，他们正在做艰苦的工作。
通过拉动请求衡量个人甚至可能不公平。致力于维护旧版代码库的开发人员往往比另一个适用于Greenfield项目的开发人员要慢。
这就是为什么测量拉力请求很棘手的原因。工程经理不能将拉力请求数据用于评估个人。如果您确实提取请求，则希望您的团队合作。在这种实践中，协作是核心价值。开发人员的努力不能仅仅通过打开或合并多少个拉力请求来衡量。甚至最糟糕的是，努力并不代表其大小。
首先，您将必须创建个人访问令牌。这是一次性的要求，不应花费几分钟。
代币将需要阅读对存储库的访问并提取请求，以便进行Prolice工作。这样的事情：
有了您的个人访问令牌，并从发行版的部分下载了二进制文件后，请在您最喜欢的首选终端中调用Prolice -Linux和MacOS（Darwin）得到了支持：
prolice --owner < owner > --repository < repository > --github-token < github-token >例如，如果我们想衡量Rust的官方存储库指标（注意：默认为100个PRS的样本）：
prolice --owner rust-lang --repository rust --github-token < github-token >个人公关指标也得到了支持：
prolice --owner rust-lang --repository rust --pr-number 32000 --github-token < github-token > Prolice的S有几个标志和可选参数，可用于调整其冗长和样本大小：
prolice --helpUSAGE:
prolice [FLAGS] [OPTIONS] --owner < owner > --repository < repository > --sample-size < sample-size > --github-token < github-token >
FLAGS:
-h, --help Prints help information
-m, --include-merge-prs Marks merge-PRs as valid targets for analysis (by default these are
excluded). Valid only for whole Repository analysis ; for individual
PR analysis this flag is ignored
-l, --print-legends Prints the metrics ' legends before sending the operation results to
stdout.
-s, --silent-mode Marks the operation as silent, which turns off all logging and
printing to stdout, with the sole exception of the analysis results.
This makes it useful for piping just the results, without the added
' noise ' . (NOTE: piping is automatically detected, which activates
silent-mode without having to explicitly add the flag to the command)
-V, --version Prints version information
OPTIONS:
-G, --github-token <github-token>
Sets the personal access token under which to perform the PR analysis
-L, --log-level <log-level>
Overrides the logging verbosity for the whole application [default: INFO] [possible
values: INFO, DEBUG, TRACE, WARN, ERROR, OFF]
-O, --owner <owner> The owner of the repository under scrutiny
-P, --pr-number <pr-number>
A specific pull-request to be selected as target for the analysis.
-R, --repository <repository> The repository under scrutiny
-S, --sample-size <sample-size>
The amount of PRs that will be fetched as sample for the analysis (unless a specific PR
number is selected as individual target) [default: 100]ProLice的结果可以将其管道输送到文件。应用程序会自动检测到管道（或任何缺乏TTY），即使用户不提供这些标志作为命令的一部分，也会关闭所有日志和消息。这对于获取可能被馈入另一个过程的原始结果很有用。
例如：
prolice --owner rust-lang --repository rust --github-token < github-token > >> results.json将产生一个results.json文件带有以下内容（在编写此读数时）：
{
"score" : [
{
"AmountOfParticipants" : 4
},
{
"AmountOfReviewers" : 1
},
{
"Attachments" : 1
},
{
"AuthorCommentaryToChangesRatio" : 31.138690476190472
},
{
"PullRequestsDiscussionSize" : 4065
},
{
"PullRequestFlowRatio" : 1.9121686296350902
},
{
"PullRequestLeadTime" : 1
},
{
"PullRequestSize" : 255
},
{
"TestToCodeRatio" : 0.42988095238095236
},
{
"TimeToMerge" : 4
}
]
}每个度量的“含义”（又称为何要测量的价值）可以通过传递--print-legends标志来打印为分析结果的一部分。尽管如此，这可能会以过多的冗长污染终端。因此，作为参考，这些都是度量标准的含义：
AmountOfParticipants参与公关讨论的非作战人数的数量。更大的参与可能会丰富讨论并产生更高质量的代码。
AmountOfReviewers通过批准或要求进行更改，对公关结果取得立场的非授权人数的数量。这衡量了有效决定公关命运的参与者的数量。
Attachments附件可以是从添加的屏幕截图到嵌入式PDF文件的任何内容。对于那些具有与之相关的视觉组件的PR特别有用。
AuthorCommentaryToChangesRatio良好的代码应该是不言自明的；但是，良好的公关还可能包括有关其目标实现的目标，如何做到以及/或为何以选择的方式进行的额外评论。
纤细的评论可能会使PR模棱两可，将理解负担转移到审稿人身上，并从中消耗额外的时间。另一方面，太多的评论可能会污染不需要的噪音的PR，并产生同样的效果。
PullRequestsDiscussionSize与作者评论与变化比率类似，它衡量了公关中评论的总数，但无论其来自谁。与社交媒体帖子相反，参与拉动请求过多会导致效率低下。测量每个拉的请求的评论和反应数量，可以使团队如何合作。协作很棒，它的认可是必需的。但是，经过一定层次，讨论放慢了发展。
变得太大的讨论可能表明了错误的事情：也许团队不一致，或者软件要求还不够精确。无论如何，讨论中的错位不是协作。他们是浪费时间。在相反的情况下，几乎零参与度意味着代码审查不是团队习惯的一部分。
总而言之，该指标必须根据团队的规模和分配达到“理想数字”。它不能太多，也不能太少。
PullRequestFlowRatio拉的请求流量比是一天中开放的拉请请求的总和除以当天的封闭请求之和。该指标显示了团队是否在健康的比例中工作。合并拉的请求并部署到生产是一件好事，因为它为最终用户增加了价值。但是，当团队关闭拉动请求比打开的更多时，很快就会拉动请求队列饥饿，这意味着交货中可能会有中断。理想情况下，最好确保团队合并以与他们打开的比例达到比例。接近1：1，越好。
PullRequestLeadTime销售时间指标想到要合并或关闭的拉动请求多少次（通常是在几天内）。要查找此数字，打开时每个拉的请求的日期和时间需要合并。公式很容易：对于日期差的简单平均值。在组织中的所有存储库中计算此指标可以使团队对其动态有更清晰的了解。
PullRequestSize每个公关的大量变化对审稿人施加了压力，审稿人的注意力对细节的关注减少了变更越大的变化。具有讽刺意味的是，开发人员往往比较短的请求更快地合并拉更长的请求，因为在发生太多事情时，进行彻底的评论更加困难。无论评论的透彻程度如何，大公关都会使时间合并上升，质量下降。
TestToCodeRatio根据经验，至少应尽可能将PR的一半由测试组成。
TimeToMerge通常，拉动请求正在开放，其中一些正在进行的工作，这意味着测量拉的提示时间并不能说明整个故事。合并的时间是分支机构到达目标分支的第一个提交花费的时间。在实践中，数学很简单：这是分支最古老的提交的时间戳，减去合并订单的时间戳。
与拉的请求提示时间相比，合并的时间通常很有用。以以下示例：
- 拉请提示时间= 3天
- 合并的时间= 15天
在上述情况下，拉动请求平均需要3天的时间合并（这非常好）；但是合并的时间是15天。这意味着开发人员在打开拉动请求之前平均工作12天（15 - 3）。
注意：如果开发人员在将所有更改压入单个提交中，该指标在将后来用作PR的基础之前就在WIP分支上工作有些过时（这将使时间有效合并等于拉的请求提前时间）。但是，该指标对于合并PRS仍然非常有用（例如，合并成长）：说PRS将有一个很短的拉力请求提前时间（它们不会得到彻底的重新评估），但是对第一个提交日期（合并的时间）进行测量将使功能要多长时间，以使功能积累到一个有足够的里程碑中，有足够的Morestone Morestone Morestone Moresto，成为“大型分支机构”。
cargo编译刺激物Prolice用生锈写。在主机平台中汇编用于使用的应用程序与使用普通的cargo build一样容易：
cargo build --releasecargo-make （Linux至MacOS）进行交叉编译刺激让我们首先从这个很棒的博客文章中的一些序言开始本节：
我讨厌十字架编译
有数百万的方法可以破坏您正在进行的操作系统，而交叉编译就是其中之一。通常，它从无辜的想法开始，即您需要一个构建链，您需要一个小程序才能在Linksys WRT 1900 ACS上运行（OpenWRT和ARMV7）。
挖掘您在Reddit上找到几个不同的片段或GitHub项目中的某些问题，其中一个随机的人发布了几行Bash，就像您需要的那些丢失的信息一样。
然后，运行bash可能会导致以下内容之一：
- 创建一个工作的构建链（非常不可能）
- 创建一个构建链，该链将在80％的构建后失败
- 添加当地的比特币矿工，同时假装实际创建一个工作构建链
在个人层面上感觉到这些痛苦后，该项目的货物货运cargo-makefile.toml中定义的目标在相对无痛的水平上提供了交叉补偿。
当然，如果仅为主机机器编译，则坚持使用纯老cargo build始终是首选。但是，假设目标是从头开始从Linux到MacOS（Darwin），除了正常的锈工具链外，您还需要安装cargo-make ：
cargo install --force cargo-make之后，通过调用汇编步骤完全照顾您：
cargo make --makefile cargo-makefile.toml release-darwin这将创建和放置，在过程完成后，压缩的二进制文件AT：
<your_dir>/target/release/out/prolice_x86_64-apple-darwin.zip
但是，考虑到跨编译Linux-to-Darwin需要Docker，因此，您可以再次通过调用普通的旧cargo build来为您的主机机器构建二进制文件，从而再次节省几个MB。
