在我最後的 Hacktoberfest 貢獻中，我參與了一個名為 Bytechef 的專案。 Bytechef 是一個低程式碼 API 整合和工作流程自動化平台。它允許您透過 API 與大量受支援的服務進行交互，方法是添加和連接各種元件來創建可以使用 API 回應的控制流。
位元組科技總部
/
比泰切夫
網站 - 文件 - Discord - Twitter
更新：ByteChef 正在積極開發中。我們正處於 alpha 階段，某些功能可能會遺失或停用。
ByteChef 是一個開源、低程式碼、可擴展的 API 整合和工作流程自動化平台。 ByteChef 可以幫助您：
我的任務是為名為 Baserow 的資料庫服務元件新增功能。我必須開發的功能是一個“動作”（即組件的函數），它允許組件更新資料庫中的一行。
Baserow - 更新行操作
第1645章
為 Baserow 元件實現更新行操作，以允許使用者修改 Baserow 資料庫中表格中的特定行。
動作屬性：
輸出：
文件參考：https://baserow.io/api-docs
</div> <div class="gh-btn-container"><a class="gh-btn" href="https://github.com/bytechefhq/bytechef/issues/1645">View on GitHub</a></div>
在註冊此問題之前，我很少使用 Java。我只在學校課程中做過小型 JavaFX 程序，但我一直想了解更多。我在自己的時間裡學習了一些，所以我對套件、存取修飾符、依賴項和 Gradle（專案使用的建置工具）等概念有一定程度的熟悉。了解這些肯定會讓進入這個專案變得不那麼令人生畏。我了解專案結構，因為我了解了 Gradle 專案如何由子專案和子包組成，每個子專案和子包都有不同的建置配置。
我的同學Arina 注意到我們都在同一個專案上工作，她很友善地透過連結到新增元件的開發人員文件以及已經為該元件定義的操作來給我一些指示，這意味著我不必親自查看儲存庫來尋找相關文件/目錄。但如果必須的話，我會使用 git grep、GitHub 的程式碼搜尋或 IntelliJ 的搜尋。我確實使用 git Blame 來檢查我要處理的元件的歷史記錄，發現它都是在一次提交中開發的。
該專案的貢獻文件非常容易理解，並一步一步列出了詳細的說明。但該專案似乎非常年輕 - 我注意到一些自述文件剛剛寫著 // TODO。
在進行更改之前，我嘗試編譯並運行該程式以查看它是如何工作的，但這是一個艱難的過程。下面是我做的筆記：
編譯完成後（花了一個多小時），我運行了它，這樣我就可以檢查現有的元件。我嘗試創建一個帳戶來使用客戶端，但它不允許我這樣做，所以我回到貢獻文檔，發現它帶有一個可用於開發的管理員帳戶，我認為該帳戶是在運行docker 時創建的-撰寫。
登入後，我嘗試製作 Baserow 元件，但客戶端有點慢，所以我不小心複製了一個。當我嘗試刪除它時，客戶端凍結了，所以我點擊刷新，然後開始出現伺服器錯誤並且客戶端逾時。我嘗試重新啟動伺服器和客戶端，但花了很長時間 - 在我看來似乎又要花一個小時。等了大約 16 分鐘後，我就到此為止了，並決定稍後再做。
我害怕回到這個項目，並且不得不處理長達一小時的編譯時間，但隨著 Hacktoberfest 接近結束，我沒有太多選擇。因此，想像一下當專案建置沒有錯誤並且在不到五分鐘的時間內啟動並運行時，我感到多麼驚訝。發生了什麼變化？我不知道。
所以我跳上客戶端並找到了 Baserow 元件。
圖 - Baserow 組件及其上的現有操作
要新增「建立行」操作，我需要查看 Baserow API 文檔，該文檔由維護者連結到我。我必須建立一個 Baserow 帳戶才能查看文檔，我認為這有點奇怪，但也沒什麼大不了的。
所以我測試了現有的操作“創建行”，並遇到了一個錯誤，整個頁面變成了錯誤訊息。我以為我輸入了一個意外的值，但後來我發現這個錯誤已經被一個與我無關的單獨問題追蹤。
在隨後的測試嘗試中，「建立行」操作成功了，因此我認為它是一個很好的學習嘗試並理解操作是如何創建的候選者。我隨後交叉引用了該問題、現有操作和貢獻文件。
我了解到，操作是透過定義所需的輸入參數、輸出模式以及定義操作執行的實際過程的方法來創建的。
在創建行操作中，我看到有一個方法可以獲取表中一行的字段，該方法用於定義輸入參數。我意識到我可以在我的操作中使用它，但它的命名好像它僅用於“創建行”操作。我認為使用它很有意義，所以我繼續使用它並決定讓維護人員知道。
在閱讀 Baserow API 文件時，我了解到要更新行，您需要使用名為「PATCH」的 HTTP 方法，而我甚至不知道該方法的存在。 PATCH 類似於 PUT，但不是替換資源，而是部分更改資源。有趣的東西。
所以我開始實際編寫我的操作，並且我能夠從現有操作中提取幾乎整個程式碼。我只需對其接受的參數（我添加了一個行 ID 來標識要更新的行）、輸出架構及其呼叫的方法（更改了端點和 HTTP 方法）進行了輕微調整。為了允許行 ID，我必須在 Constant/ 子目錄中的檔案中新增一個常數，其中包含與 Baserow 元件相關的所有常數。
我注意到所有現有的原始碼檔案都有一個許可證頭，所以我也將其複製到我的中。我組織了我的導入，格式化了我的程式碼，現在是時候手動測試它了。
此時，我注意到“創建行”操作（已經存在的操作）的描述是錯誤的- 它說它在Baserow 的示例數據庫中創建一行，它通過名稱引用該行，而不僅僅是說您可以建立一行。我也向維護者做了註釋，向維護者提及這一點：
圖 - Create Row 組件的描述不正確
我的操作出現在客戶端中，視覺上一切看起來都很好：
標題與描述出現：
顯示屬性（即輸入參數）：
工作流程成功運行，我收到了成功的回應：
表格已在我的 Baserow 帳戶中更新：
我對自己的更改感到滿意，因此我繼續運行格式化程式和測試，但測試失敗了，因為其中一項測試預計 Baserow 元件僅對其執行一項操作。我更新了測試以適應我的新操作，並運行了一個自動生成組件文件的腳本。重新運行測試時，它們通過了，但我仍然必須為我的操作添加單元測試。我查看了現有組件的單元測試，結果摸不著頭緒。我認為我已經取得了不錯的進展，所以我就到此為止了，打開了一份 PR 草案，並讓維護者知道我注意到的問題。
儘管現有的測試看起來很可怕，但我真的沒有太多選擇，只能為我的操作添加一個，所以我回去並試圖理解現有測試中發生了什麼。我稍微研究了一下所使用的測試庫 - JUnit Jupiter 和 Mockito。我試著一點一點地分解它，並使用法學碩士來幫助我理解每一行發生了什麼。但說實話，我對到底是怎麼回事，還是有模糊的了解。我知道我在嘲笑 Baserow API 並在其上呼叫我的操作方法，但這就是我的理解範圍。
顯然，這已經夠好了。我將我的 PR 標記為可供審核，並且維護者接受了我的更改！他們提供了一些反饋 - 儘管我讀過它們，但我忘記了遵循貢獻流程的某些部分。下次，我應該在創建拉取請求之前查看貢獻文檔。
為 Baserow 元件建立更新行操作
第1656章
修補#1645
我發現初始設定和編寫測試是這個問題中最令人生畏的部分。相比之下，實際上添加該功能是輕而易舉的事。但我發現這個問題真正酷的是，我能夠用我不太了解的語言為專案做出貢獻，這要歸功於他們維護良好的文件和易於理解的程式碼。
這是我在 2024 年 Hacktoberfest 上的最後一個公關！回顧貼文即將推出！
以上是深入研究 Java 項目的詳細內容。更多資訊請關注PHP中文網其他相關文章！
