概念驗證：Jira 是圖靈完備的

多年來，工程界一直流傳著一個說法：Jira——Atlassian ubiquitous 的專案追蹤工具——是圖靈完備的。雖然許多人曾含糊地將其自動化功能作為證據，但很少有人提供正式的歸約（reduction）來證明這一點。

Nicolas Seriot 最近的研究將這一傳說轉化為正式證明。透過證明 Jira 可以實現一個 Minsky 暫存器機（Minsky register machine），Seriot 證明了 Jira 不僅僅是一個追蹤工單（ticket）的工具，而是一個計算通用的系統，只要有足夠的記憶體（在這種情況下是足夠的 issue），它就能執行任何標準電腦可以進行的計算。

計算模型：Minsky 機

為了證明圖靈完備性，Seriot 利用了 Minsky 暫存器機。這個模型在計算上與圖靈機等價，但將其映射到商業工具上要簡單得多。Minsky 機只需要兩個無界計數器（暫存器）和一組標記指令集：

  1. 遞增 (INC r; goto S): 增加暫存器 r 的值並移動到狀態 S。
  2. 遞減/分支 (DEC r; if r == 0 goto S else goto S'): 減少暫存器 r 的值。如果暫存器已經是零，則移動到狀態 S；否則，移動到狀態 S'。

如果一個系統可以實現這兩個操作並維持一個狀態（程式計數器），它就是圖靈完備的。

將 Minsky 映射到 Jira

Seriot 的證明將 Minsky 機的抽象組件直接映射到 Jira 的核心實體：

Minsky 機組件 Jira 實現方式
Register A Bug 類型的連結 issue 數量
Register B Task 類型的連結 issue 數量
Program Counter 單個 Epic issue 的狀態
Dispatch Table Jira Automation 規則（每個指令狀態一個）
Clock 自動化觸發的轉換或外部重新觸發

在此架構中，Epic 的狀態代表當前的指令。Jira Automation 規則會監控這些狀態變化。當狀態改變時，對應的規則會執行，檢查連結 issue 的數量（暫存器），並決定下一個狀態轉換（下一個指令）。

實際實現：兩個數字相加

為了在實踐中演示這一點，Seriot 使用一個 Epic 和兩種類型的連結 issue 來實現了一個簡單的加法程式 (A + B)。

邏輯

  • 狀態 TODO (遞減 A): 如果至少存在一個連結的 Bug，則刪除一個 Bug 並將 Epic 轉換為 DEV。如果不存在 Bug，則則轉換為 PROD (停止)。
  • 狀態 DEV (遞增 B): 建立一個新的 Task，將其連結到 Epic，並轉換回 TODO。

執行追蹤

從 2 個 Bug (A=2) 與 3 個 Task (B=3) 開始，機器會透過以下轉換進行連鎖反應： (2,3) TODO $\rightarrow$ (1,3) DEV $\rightarrow$ (1,4) TODO $\rightarrow$ (0,4) DEV $\rightarrow$ (0,5) TODO $\rightarrow$ (0,5) PROD。

結果是 0 個 Bug 與 5 個 Task，有效地計算了 2 + 3 = 5。

規模擴展：Fibonacci 與「圖靈泥潭」

雖然加法證明了這一點，但 Seriot 展示了 Jira 的 Convert Issue Type 功能可以作為捷徑，允許執行更複雜的程式，例如 Fibonacci 數列。透過使用三個暫存器（Bugs, Tasks, 和 Stories）以及三個狀態 (TODO, QA, DEV)，可以透過在不同 issue 類型之間來回轉換來生成 Fibonacci 數列，這比原始的 INC 和 DEC 操作更有效率。

然而，這種效率是相對的。正如社群觀察到的，在 Jira 中實現即使是簡單的邏輯也是一種挫折感十足的體驗。一位評論者觀察到，該系統是一個「圖靈泥潭」（Turing tarpit）——一個任何事情都可能發生，但沒有任何事情都很容易的地方。

技術限制與現實

在真實世界的雲端環境中，Jira impose 了一個「鏈結深度上限」（chain-depth cap，通常為 10 個觸發器）以防止無限迴圈導致伺服器崩潰。雖然這在技術上限制了機器的執行，但 Seriot 認為這並不反駁圖靈完備性，因為所有物理電腦都具有有限的記憶體與時間限制。人類操作員可以簡單地重新觸發 Epic 的狀態，以提供下一個「時鐘滴答」，讓計算繼續進行。

社群觀點

Jira 是圖靈完備的這一發現揭示了開發者之間混合了有趣與恐怖的感覺。雖然有些人將其視為一個迷人的學術練習，但其他人則將其視為為什麼該工具經常感覺如此笨重。

"That explains why it's impossible to tell whether any given Jira operation is going to halt or not。"

其他人也指出使用這種系統來處理實際邏輯的荒謬性，指出 Jira 的自動化感覺起來像是「用組合語言進行程式設計」來完成基本任務。不滿的開發者們的共識是，該工具的複雜度已達到了一個需要專屬諮詢文化來管理的點，這通常是軟體系統變得過於臃腫-bloat 的跡象。

最終，證明證實了許多人的懷疑：如果複雜的 Jira 自動化感覺起來像是在寫程式，那是因為它們實際上就是在寫程式。

Sources