远程开发 代码提示_VS Code 远程开发和代码评审实践
很多年前的一天,我在 TypeScript 倉庫下創建了一個 issue:微軟打算拿 Monaco 來干嘛?接著第二天微軟就發布了 VS Code。這個巧合我吹了五年還孜孜不倦。
因為已經用上了 TypeScript,我們也順利將當時團隊主要使用地編輯器從 Atom 切換到了 VS Code 0.1,應該是國內最早一批 VS Code 用戶了。
這兩年來,隨著當前項目代碼規模的不斷擴大,我開始尋找利用服務器計算資源的開發方案來改善開發體驗,嘗試了諸如 StackBlitz 這樣的方案,但一直還是希望找到完整的 VS Code 在線部署方案。直到遇到了 code-server,然后微軟就冷不丁發布了 Remote Development。心疼 code-server 三秒鐘。
一周后,我們很快搭建起來了一套簡易的多用戶 VS Code 方案,手動配置 docker compose 文件為同事每人分配了一個容器和 SSH 端口,成了或許是國內第一批使用 VS Code Remote Development 的團隊。
當時我們考慮了一種應用場景,也就是一個分支對應一個遠程工作空間,創建工作空間后自動克隆和初始化項目,完成后釋放遠程工作空間。當然后來的事情大家都知道了,微軟發布了 Visual Studio Online,覆蓋了相似的場景。
為啥要眨眼?因為當時我們已經用上自己折騰出的升級方案 remote-workspace 挺久了,說不定是 Visual Studio Online 團隊以外第一批使用 VS Code Remote Development 按功能分支創建遠程工作空間的團隊。
開發工作流
我們根據開發類型和改動大小其實有幾個不同的開發工作流,以常規開發工作流為例:
常規開發工作流開發
首先,任務開發負責人以任務編號為分支名稱創建遠程工作空間:
我們將常見項目添加到了共用的模板中,簡單選擇就可以完成工作空間配置,支持同時初始化多個項目,方便跨項目的開發任務。
對于我們的主項目,整個初始化大約需要 40 秒。這個過程包含了代碼克隆,包安裝,部分代碼編譯和示例數據生成。我們啟用了跨容器的本地 Git 對象共享,包緩存等以優化初始化時間,對于一些小項目則通常能在幾秒內完成。
聰明的同學可能注意到了上面的“tunnel”。打開某個工作空間時,會自動轉發配置的端口。偶爾我們也會不打開項目,直接 tunnel 其他同事的工作空間,測試或參與調試正在開發中的版本。
代碼評審
完成開發后,同事會進行代碼評審。通常而言,我們會先在 GitLab 中查看 MR;對于有復雜度的改動,則會打開對應任務的遠程工作空間,使用 VS Code 進行查看:畢竟 GitLab 上看 diff 很多時候都只能充當人肉 prettier,檢查下代碼風格。
除了可以使用到完整的語言服務,快速在代碼中導航跳轉以外,還可以更方便地修改、查看效果。同事開發過程中留下的測試數據通常也會方便代碼評審人對功能進行測試。
分支對比我們使用的是 GitLens 提供的 Compare Ancestry with Working Tree:
找到要對比地遠程分支(我們是 origin/master)右鍵遠程分支,選擇 Compare Ancestry with Working Tree交換對比分支代碼重構(修改)
需求是做不完的,為了節約開發和代碼評審人雙方的時間,對于一些直接改比退回去快很多的修改,則不再退回開發節點,而是直接由評審人修改和提交。比如:
交付和收尾
至此,一個遠程工作空間的使命就完成了,任務負責人會刪除遠程空間釋放相關資源。
總結
雖然叫做升級方案,但 remote-workspace 項目定位還是一個快速成型的內部工具,加上 VS Code Remote Development 的客觀特點,整個體驗還是有好有壞。
優點
缺點
Makeflow (makeflow.com) 是以流程為核心的項目管理工具,讓研發團隊能更容易地落地和改善工作流,提升任務流轉體驗及效率。如果你正為了研發流程停留在口頭討論、無法落實而煩惱,Makeflow 或許是一個可以嘗試的選項。如果你認為 Makeflow 缺少了某些必要的特性,或者有任何建議反饋,可以通過 GitHub、語雀或頁面客服與我們建立連接。
總結
以上是生活随笔為你收集整理的远程开发 代码提示_VS Code 远程开发和代码评审实践的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 空值替换为0_「Excel」是零值还是空
- 下一篇: 辽宁直招军官什么时候入伍