編譯 | 伊風
出品 | 51CTO技術棧（微信号：blog51cto）
編者按：資深開發者詹姆斯·拉米雷茲長文分享，講述了他使用ChatGPT學習Go語言，導航Kolide API并建構複雜的Steampipe插件的經驗。在這個過程中，他深化了對AI輔助程式設計的認識。
開發者（包括我自己在内）更喜歡邊做邊學。這是我與LLM合作的指導原則之一，也可以說是最重要的一項：因為你在面向任務的教學時刻中擷取知識，學習不是前瞻性的——它是即時的和可觸摸的。
當一位經驗豐富的開發者與LLM合作時，它的機器智能支援和增強了你的人類智能。
對我來說，好處是顯而易見的。在LLM時代為Steampipe編寫ODBC插件感覺比我之前沒有這種幫助時要容易得多。但這顯然是一個主觀評價，是以我在尋找一個機會與另一位插件開發者比較筆記時，詹姆斯·拉米雷茲在我們社群的Slack中宣布為Kolide API建構了一個新插件。
我邀請他告訴我他建構插件的經驗，他很慷慨地和我一起進行了一次長時間的與ChatGPT的對話，他在對話中熟悉了三個新的技術知識領域：Kolide API、Go語言和Steampipe插件架構。
作為一個額外的挑戰：雖然插件開發者通常會為他們的插件目标API找到合适的Go SDK，但這裡并非如此。是以，需要為Kolide API建立一個Go包裝器，然後将其內建到插件中。
1、測試ChatGPT的Go能力
詹姆斯開始進行一些熱身練習。首先，為了測試ChatGPT的Go能力，他提供了一對他編寫的調用相關API /devices/ 和 /devices/ID 的Go函數，并要求對其進行重構，以隔離在兩者之間共享邏輯。
接下來，他探索了使用簡單的可變參數與更複雜的函數選項模式來處理函數的可選參數，并确定簡單的方法——使用一個Search結構的切片來封裝Kolide的查詢參數的字段/運算符/值樣式——就足夠了。他要求一個函數來将該Search結構的切片序列化為一個REST URL，然後完善了ChatGPT提出的版本，建立了一個最終的serializeSearches，增加了對将友好名稱映射到參數并使用字元串建構器的支援。
其中一些改進，，包括使用字元串建構器，都是由一個名為CodeRabbit的AI驅動的機器人提出的，它提供了有用的代碼審查。他說，這種回報有助于你和你的團隊專注于大局，因為它處理了細節，并經常（雖然不總是）提供可送出的建議。
它還采取了更廣泛的視角來總結拉取請求，并評估關閉的PR是否解決了其連結問題中陳述的目标。
2、映射運算符
詹姆斯繼續探讨如何将Steampipe運算符（如QualOperatorEqual）映射到Kolide運算符（如Equals）。在這裡，ChatGPT建議的方法也被證明是一種應該丢棄的方法，完全可以采用一個更幹淨簡單的方法。
但正如詹姆斯在我們的采訪中确認的那樣，由于你最終會對可抛棄的版本進行疊代，是以能夠生成合理的疊代而不是手工編寫它們會很有幫助。在這個過程中，他正在學習基本的Go習慣用法。
詹姆斯：
Go中有do-while循環嗎？
ChatGPT：
沒有，但是……
詹姆斯：
Go中有三元運算符嗎？
ChatGPT：
沒有，但是……
詹姆斯：
如何将内容附加到map[string]string？
ChatGPT：
像這樣……
3、通過反射增強的通路者模式
在消化了基礎知識并為Kolide API開發了一個Go用戶端之後，詹姆斯準備着手處理插件開發的真正工作：定義表，将從API包裝器傳回的Go類型映射到管理對這些表的SQL查詢的Steampipe模式。
像所有的插件開發者一樣，他從一個可以列出一組資源的表開始，然後通過添加過濾器和分頁來增強它。在添加了第二個表之後，是時候考慮如何抽象出常見的模式和行為了。最終的結果是對通路者模式的一種優雅實作。這裡是對應于表kolide_device和kolide_issue的Steampipe List函數。
圖檔
這是所有插件表都使用的通用listAnything函數。
圖檔
通過這種設定，向插件添加一個新表幾乎完全是聲明性的：你隻需要定義模式，以及形成在SQL查詢中的where（或join）子句和API級别過濾器之間的橋梁的KeyColumns和相關運算符。
然後，你編寫一個小的List函數，定義一個通路者，并将其傳遞給通用的listAnything函數，該函數封裝了查詢參數的編組、連接配接到API用戶端、調用API、将響應解包成一個集合，并對集合進行疊代以将項目流式傳輸到Steampipe的外部資料包裝器。
詹姆斯使用ChatGPT啟動了Go中通路者模式的習慣實作。這意味着學習如何為通路者函數定義一個類型，然後聲明一個函數來滿足該類型。
每個表的通路者封裝了對API用戶端的調用，并傳回一個接口。這都相當通用，但是通路者的響應是特定于包裝的API響應的Go類型，這意味着必須為每個表編寫一個不同的List函數。如何避免這種情況？詹姆斯問道：“res變量上的字段引用需要是在執行時指定的可變類型。你能提出一個方法嗎？”
ChatGPT的建議是使用反射，以便像listAnything(ctx, d, h, “kolide_device.listDevices”, visitor, “Devices”)這樣的調用可以傳遞一個名稱（“Devices”），該名稱使listAnything能夠以一種與類型無關的方式通路響應結構的字段，例如這裡的Devices字段。詹姆斯接受了這個建議。
圖檔
有了這個，listAnything終于名副其實地成為了一個完全通用的Steampipe List函數。這個解決方案節省了反射的使用，并保留了Go在API層和Steampipe層中的強類型檢查。
4、LLM協助到底意味着什麼？
這絕對不意味着一個LLM在回答類似“請為Kolide API建立Steampipe插件”這樣的提示時編寫了一個展現複雜設計模式的插件。
對我來說，以及對詹姆斯來說，大模型輔助程式設計意味着更有趣的事情：“讓我們讨論一下為Kolide API編寫插件的過程。”這就像與一個橡皮鴨交談，以便大聲思考需求和政策（編者注：“橡皮鴨”（Rubber Duck Debugging）是一個流行的術語，它指的是一種調試技術，其中開發者通過向一個假想的聽衆（在這個比喻中是一隻橡皮鴨）解釋他們的代碼來解決問題）。LLM正是一個會回答的橡皮鴨。
有時候，回答是直接适用的，有時候不是，但無論如何，它們通常可以幫助你更清晰地思考。
作為一名具有廣泛經驗的進階軟體工程師，詹姆斯本來可以自己解決這個問題，但這可能需要更長的時間。他本來會花費大量的時間閱讀文章和文檔，而不是通過實踐學習。而且可能沒有那麼多的時間！正如我現在從許多其他人那裡聽到的，LLM提供的加速往往是有了一個想法和能夠執行它之間的差異。
詹姆斯還提到了一個我沒有考慮過的開源角度。在LLM之前，他不會完全以公開方式進行這項工作。“我會一直保持私密，直到我感覺更自信，”他說，“但這一次從一開始就是公開的，我很高興它能夠公開。”這使得與Turbot團隊更早地而不是更晚地進行接觸成為可能。
這不是一個自動化的故事，而是一個增強的故事。當像詹姆斯·拉米雷茲這樣經驗豐富的開發者與LLM合作時，它的機器智能支援和增強了他的人類智能。兩者共同努力——不僅僅是為了編寫代碼，更重要的是為了思考架構和設計。
來源： 51CTO技術棧