今天延續做天的腳本聊點坑、聊點背後的原理。

在腳本的某一個部分，我在一個 condion 後面寫下了：

JQL Branch 是找不到自己的；
所以若是本體，直接索取本體的 Rank 值，
若不是本體，再透過 JQL Branch 去賦值。

會這樣寫是因為，我原本是想說一開始就透過 JQL 搜尋分隔線的名稱，取得他的資料與 rank code，但會發現如果觸發的 issue 就是分隔線本人，那麼就會找不到這個 issue，當時覺得很莫名其妙，儘管是現在也仍然覺得奇怪，但就是一個坑。所以我才會先在一開始專門檢查觸發的 issue 是不是符合分隔線本人，然後直接做相關的 action，如果不是本人，再另外透過 JQL 取得分隔線 issue 本體。

另外有一段腳本是執行 Send Slack message

{{initiator.displayName}} 移動了某 Item，基準線序號為 "{{RankBaseline}}"

除了方便我 Debug，也可以讓我透過 Slack 得知有人調整了 Priority，我就可以去檢視。這便其實可以進一步去擴展，比如說當某個 Item 被脫衣到 ?　以上是 SP1 時 PO 期望範圍線 之上，我就可以傳訊息到 Slack 説 PO 將這個 Item 拉到下次 SP1 的預期範圍，如果很希望收到類似通知的話，可以這麼做。

最後來聊聊 Jira 的 rank 機制吧！不知道你們有沒有想過，要製作像是 Product Backlog 這樣的功能，系統是怎麼去記錄他們的排序的？不可能是用 1, 2, 3, 4, 5, ...，不然我把一個在 99 的 Item 拉到第一位，就要更改 99 個 Item 的 rank 值。

在 Jira，rank 的值是長得像 2|i019s3 ，其中第一個數字是 bucket，在 Jira 目前會有 0, 1, 2 三個 bucket，如果 | 後的排名觸發某個條件導致他要重新計算排名時，Jira 會將新排名存在 0，等到完成平衡後再統一使用 0|i019s3 的值。最重要的是後面是依照數字與英文字母組成的排序，通常相鄰的 issue 之間不會是連號，而是有空數個值的，比如説 2|i019qp 和 2|i019s3，那我如果拖曳一個 item 到兩者中間，我就在兩者之間選一個值即可，大概是這樣的概念。

對於 rank 想進一步暸解的話，可以參考：
Jira's ranking system explained - TMC Application Lifecycle Management

對我來說，這其實和卡片盒筆記法的序號系統有異曲同工之妙。 XD