建構 CLI 功能通常可以歸結為：
每一步都需要之前的一步，哎呀我們已經重新發明了瀑布專案管理。你會被痛苦所折磨，試圖優雅地彌補錯誤，直到你一瘸一拐地恢復正常，但在出色之前就退出了。並且不要讓我開始維護由此產生的臨時“修復”和缺陷集群。
去過那裡，做過那件事。我們知道我們需要超越瀑布式的方法。
這是我們如何實現這一目標的故事，以及一路上提供幫助的一些工具。
我們想要廉價、快速的迭代，直到我們理解了該功能，然後才致力於昂貴的實施和長期支援。作為一個小團隊，我經常從頭到尾完成這個過程，並希望依次關注每個部分。我們想要偽造實現部件，直到我們有足夠的信心來製作它。
回到流程，首先是提出功能。我們想要擺脫抽象，但如果這意味著不成熟的實現，我們就不想這樣做。受到 Github 此處描述的 Google Docs CLI 草圖方法的啟發，我們用「草圖」偽造了它。
不幸的是，靜態草圖並沒有提供我們想要的回饋。我們的 CLI 隨著時間的推移改變輸出，更像是動畫而不是繪圖。為了實現更高的保真度，我編寫了一些 Ruby 程式來獲取基本輸入並透過列印適當的預設響應來進行回應。
從那時起，我們找到了一種更好的方法來捕捉動畫 CLI 輸出，但要解釋這一點需要繞一些彎路。
當我們開始充實 CLI 時，我們也想測試邊緣情況並檢測回歸。我調查了基於 Cobra/bubbletea 的公共 CLI 來尋找想法，但令人沮喪的是，測試很少。然後我們偶然發現了 Charm 的 Teatest，這給了我們一個起點。
Teatest 專注於黃金測試，捕捉已知的良好輸出，然後斷言未來的輸出繼續匹配它。這讓我們再次回到了動畫 CLI 輸出的高保真捕獲。 Teatest 為我們提供了基於框架的解決方案的好主意，例如翻頁書，我們以此為基礎：
這個簡化的範例顯示了基本授權指令的黃金輸出可能會是什麼樣子。水平線描繪了框架，並帶有指示活動模型的標籤。綜上所述，即使新增、刪除或替換線路，我們也能獲得高保真度的輸出捕獲。
我們在測試套件中使用一個標誌來更新具有黃金輸出的文件，否則如果輸出與文件不匹配，測試就會失敗。這使我們能夠了解輸出的變化，並透過讓我們了解輸出應該是什麼樣子以及它是否發生變化來促進公關審查。我們非常喜歡它，因此計劃將我們的草圖程式替換為 Github 風格Google文件中的金色風格輸出，這樣我們就可以捕捉動畫和風格創意。
有了我們曾經和未來的草圖，讓我們回到開始使用新的 API 端點。
我們同時處理 API 和 CLI，因為這些的最佳設計源自於緊密整合。我們能夠做到這一點，同時仍然避免瀑布的危險，透過在更便宜的環境中迭代設計並等待直到需求固化為止。對於我們的 API，這意味著使用 OpenAPI 繪製草圖：
這個簡化的範例顯示了基本授權指令的架構可能會是什麼樣子。我們使用 Spectrum linter 來簡化這些文件的處理。
有了草圖，我們就可以在實作 CLI 時使用 prism 作為模擬 API 伺服器。當我們不可避免地意識到犯了錯誤時，我們可以調整規範並返回 CLI 迭代。在這個高水準上工作使我們能夠一起發展 API 和 CLI，並推遲昂貴的實施，直到我們有更好的知識。
我們也依賴 OpenAPI 規範，以便在使用委員會的實施過程中保持誠實。 assert_schema_conform 測試對齊情況，中間件會通知我們任何即時差異。這些結合起來允許紅綠實施，同時保護我們免受回歸。
To round things out, our test suite uses flags to run prism in either mock or proxy mode. By using flags we can focus on writing just one kind of test, though it does mean we skip some tests in one mode or the other. We use mock tests for their speed and on Windows and macOS where our full stack doesn't run in CI. Our proxy tests let us run tests against our entire stack just by adding a flag, making it easy to run end to end testing whenever we deem it necessary.
Sketches and specs help us iterate past the abstract without having to get bogged down in implementation. Then mocks and proxies help us ensure the implementations match the sketches. By continuing to iterate our process, each feature causes less pain, which we have deeply appreciated while building the teams experience we will deliver later this month.
We will keep iterating on our process, I hope you learned something from it and I would love to learn from you. What have you tried, where are you proud and what remains frustrating?
以上是開發 CLI的詳細內容。更多資訊請關注PHP中文網其他相關文章！
