作者分享了他使用 ChatGPT 學習 Go、瀏覽 Kolide API 以及構(gòu)建一個復雜的 Steampipe 插件的經(jīng)驗。

譯自Pairing With AI: A Senior Developer's Journey Building a Plugin，作者 Jon Udell。

雖然改進開發(fā)人員文檔始終有幫助，但許多人（包括我自己）更喜歡在實踐中學習。這是我在七項指導原則中提出的第七項，也是最重要的一項：因為你在面向任務(wù)的可教授時刻獲取知識，所以學習不是前瞻性的，而是直接且切實的。

當經(jīng)驗豐富的開發(fā)人員與 LLM 合作時，其機器智能會支持并增強你的智力。

好處對我來說很明顯。在 LLM 時代編寫Steampipe 的 ODBC 插件比我在沒有此類幫助的情況下編寫插件的體驗容易得多。但那公認是一個主觀評估，所以我一直在尋找一個機會與另一位插件開發(fā)人員比較筆記，當James Ramirez在我們的社區(qū) Slack 中出現(xiàn)并宣布一個新插件用于Kolide API時。我邀請他告訴我他構(gòu)建它的經(jīng)歷，他親切地帶我進行了一次與 ChatGPT 的長時間對話，在此對話中，他熟悉了三個對他來說都是新知識的技術(shù)領(lǐng)域：Kolide API、Go 語言和 Steampipe 插件架構(gòu)。

作為一個額外的挑戰(zhàn)：雖然插件開發(fā)人員通常為其插件針對的 API 找到合適的 Go SDK，但這里并非如此。因此，有必要為 Kolide API 創(chuàng)建一個 Go 封裝，然后將其集成到插件中。

測試 ChatGPT 的 Go 能力

James 從一些熱身練習開始。首先，為了測試 ChatGPT 的 Go 能力，他提供了一對 Go 函數(shù)，他編寫了這些函數(shù)來調(diào)用相關(guān)的 API/devices/和/devices/ID，并要求對它們之間的共享邏輯進行慣用重構(gòu)。

接下來，他使用簡單的可變參數(shù)而不是更復雜的函數(shù)選項模式探索了函數(shù)的可選參數(shù)，并確定了簡單的方法——使用Search結(jié)構(gòu)的切片來封裝 Kolide 的查詢參數(shù)的字段/運算符/值樣式——就足夠了。他要求一個函數(shù)將Search結(jié)構(gòu)的切片序列化為一個 REST URL，然后優(yōu)化 ChatGPT 提出的版本以創(chuàng)建最終的serializeSearches，該版本增加了對將友好名稱映射到參數(shù)的支持并使用字符串構(gòu)建器。

AI 處理吹毛求疵，并經(jīng)常提供可提交的建議。

其中一些優(yōu)化，包括使用字符串構(gòu)建器，是由 AI 驅(qū)動的機器人CodeRabbit提出的，它提供了有用的代碼審查。他說，這是幫助你和你的團隊專注于全局的反饋，因為它處理吹毛求疵，并經(jīng)常（但并非總是）提供可提交的建議。它還采取更廣泛的視角來總結(jié)拉取請求并評估已關(guān)閉的 PR 是否解決了其關(guān)聯(lián)問題中陳述的目標。

映射運算符

他繼續(xù)探索將 Steampipe 運算符（如QualOperatorEqual）映射到 Kolide 運算符（如Equals）的方法。同樣，ChatGPT 提出的方法也變成了一個一次性方案，朝著一個干凈簡單的方案前進。但正如 James 在我們的采訪中證實的那樣，由于你無論如何都會迭代一次性版本，所以能夠生成合理的迭代而不是通過手工更繁瑣地對它們進行編碼是有幫助的。在此過程中，他正在學習基本的 Go 慣用語。

James：

Go 中有 do-while 循環(huán)嗎？

ChatGPT

沒有，但是……

James：

Go 中有三元運算符嗎？

ChatGPT

沒有，但是……

James：

我如何追加到map[string]string？

ChatGPT

像這樣……

使用反射增強的訪問者模式

在理解了基礎(chǔ)知識并為 Kolide API 開發(fā)了一個 Go 客戶端后，James 準備解決插件開發(fā)的實際工作：定義從 API 封裝返回的 Go 類型映射到控制針對這些表的 SQL 查詢的 Steampipe 架構(gòu)的表。

與所有插件開發(fā)者一樣，他從一個可以列出資源集的表開始，然后通過過濾和分頁對其進行增強。在添加第二個表后，是時候考慮如何抽象出公共模式和行為。最終結(jié)果是訪問者模式的優(yōu)雅實現(xiàn)。以下是與表kolide_device和kolide_issue相對應的 SteampipeList函數(shù)。

func listDevices(ctx context.Context, d *plugin.QueryData, h *plugin.HydrateData) (interface{}, error) {
  var visitor ListPredicate = func(client *kolide.Client, cursor string, limit int32, searches ...kolide.Search) (interface{}, error) {
    return client.GetDevices(cursor, limit, searches...)
  }


  return listAnything(ctx, d, h, "kolide_device.listDevices", visitor, "Devices")
}




func listAdminUsers(ctx context.Context, d *plugin.QueryData, h *plugin.HydrateData) (interface{}, error) {
  var visitor ListPredicate = func(client *kolide.Client, cursor string, limit int32, searches ...kolide.Search) (interface{}, error) {
    return client.GetAdminUsers(cursor, limit, searches...)
  }


  return listAnything(ctx, d, h, "kolide_admin_user.listAdminUsers", visitor, "AdminUsers")
}

以下是所有插件表通用的列表清單函數(shù)。

func listAnything(ctx context.Context, d *plugin.QueryData, h *plugin.HydrateData, callee string, visitor ListPredicate, target string) (interface{}, error) {
  // Create a slice to hold search queries
  searches, err := query(ctx, d)
  if err != nil {
    plugin.Logger(ctx).Error(callee, "qualifier_operator_error", err)
    return nil, err
  }


  // Establish connection to Kolide client
  client, err := connect(ctx, d)
  if err != nil {
    plugin.Logger(ctx).Error(callee, "connection_error", err)
    return nil, err
  }


  // Iterate through pagination cursors, with smallest number of pages
  var maxLimit int32 = kolide.MaxPaging
  if d.QueryContext.Limit != nil {
    limit := int32(*d.QueryContext.Limit)
    if limit < maxLimit {
      maxLimit = limit
    }
  }


  cursor := ""


  for {
    // Respect rate limiting
    d.WaitForListRateLimit(ctx)


    res, err := visitor(client, cursor, maxLimit, searches...)
    if err != nil {
      plugin.Logger(ctx).Error(callee, err)
      return nil, err
    }


    // Stream retrieved results
    collection := reflect.ValueOf(res).Elem().FieldByName(target)
    if collection.IsValid() {
      for i := 0; i < collection.Len(); i++ {
        d.StreamListItem(ctx, collection.Index(i).Interface())


        // Context can be cancelled due to manual cancellation or the limit has been hit
        if d.RowsRemaining(ctx) == 0 {
          return nil, nil
        }
      }
    }


    next := reflect.ValueOf(res).Elem().FieldByName("Pagination").FieldByName("NextCursor")
    if next.IsValid() {
      cursor = next.Interface().(string)
    }


    if cursor == "" {
      break
    }
  }


  return nil, nil
}

有了此設(shè)置，向插件添加新表幾乎完全是聲明式的：你僅需定義架構(gòu)及 KeyColumns，以及在 SQL 查詢中的 where（或 join）子句與 API 級過濾器之間形成橋梁的相關(guān)運算符。然后編寫一個微小的 List 函數(shù)，該函數(shù)定義一個訪問器，并將該函數(shù)傳遞到 common listAnything 函數(shù)中，該函數(shù)封裝查詢參數(shù)編組、連接至 API 客戶端、調(diào)用 API、將響應解壓縮到一個集合中以及迭代集合以將數(shù)據(jù)項傳輸?shù)?Steampipe 的外部數(shù)據(jù)包裝器的功能。

James 使用 ChatGPT 來啟動訪問者模式在 Go 中的慣用實現(xiàn)。這包括學習如何為訪問者函數(shù)定義一個類型，然后聲明一個函數(shù)來滿足類型。每個表的訪問者都封裝對 API 客戶端的調(diào)用，并返回一個接口。所有這些都相當通用，但訪問者的響應特定于包裝的 API 響應的 Go 類型，這意味著需要為每個表編寫一個不同的 List 函數(shù)。如何避免這種情況？James 問道：“res 變量上的字段引用需要是可變類型，在執(zhí)行時指定。你能建議一種方法嗎？”

ChatGPT 的建議（他采納了）是使用反射，以便調(diào)用 listAnything（如 listAnything(ctx, d, h, “kolide_device.listDevices”, visitor, “Devices”））可以傳遞一個名稱（"Devices"），使 listAnything 能夠以與類型無關(guān)的方式訪問響應結(jié)構(gòu)的字段，例如，此處的 Devices 字段。

type DeviceListResponse struct {
      Devices    []Device   `json:"data"`
      Pagination Pagination `json:"pagination"`
    }

正因如此，listAnything 終于如其名，成為一個通用的 Steampipe List 函數(shù)。該解決方案很少使用反射，并在 API 層和 Steampipe 層中都保留了 Go 的強類型檢查。

LLM 協(xié)助真正意味著什么？

它肯定不意味著 LLM 根據(jù)以下提示編寫了一個體現(xiàn)復雜設(shè)計模式的插件：“我需要一個用于 Kolide API 的 Steampipe 插件，請創(chuàng)建它。”對我來說，以及對 James 來說，它的含義更有趣：“讓我們討論為 Kolide API 編寫插件的過程。”這就像與一只橡皮鴨交談，以便大聲思考需求和策略。但 LLM 是一只會說話的橡皮鴨。有時響應直接適用，有時不適用，但無論哪種方式，它們通常可以幫助你獲得清晰度。

作為一名經(jīng)驗豐富的軟件工程師，James 本可以想出辦法——但這需要更長的時間。

James 說：“對話要求我對所問的問題非常具體。”雖然他從頭開始使用 Go，但他帶來了豐富的經(jīng)驗，使他能夠快速定位并找出哪些是需要問的正確問題。作為一名經(jīng)驗豐富的軟件工程師，James 本可以自己想出所有這些。但這需要更長的時間，而且他將花費大量時間預先閱讀文章和文檔，而不是通過實踐學習。而且可能沒有時間！正如我現(xiàn)在從許多其他人那里聽到的那樣，LLM 提供的加速通常決定了擁有一個想法和能夠執(zhí)行它之間的區(qū)別。

James 還提到了我未考慮過的開源角度。在 LLM 之前，他不會以完全公開的方式完成這項工作。“我會一直保密，直到我更有信心，”他說，“但這從一開始就在那里，我很高興它在那里。”這使得與 Turbot 團隊的接觸盡早成為可能。

這不是一個自動化故事，而是一個增強故事。當像 James Ramirez 這樣的經(jīng)驗豐富的開發(fā)人員與 LLM 合作時，其機器智能支持并放大了他的智力。兩者協(xié)同工作——不僅編寫代碼，更重要的是，思考架構(gòu)和設(shè)計。