你打開一個代碼合并請求,本意是想搞清楚這次改了什么。對于中小規模的變更,一切正常運轉:代碼清晰可讀,文件一目了然,你上下翻動、添加審閱意見,整個過程相當順暢。
可一旦遇上大場面,情況就急轉直下。也許是某個自動化程序一口氣生成了實現代碼、測試用例、固定數據和快照文件;也許是這個分支碰過的文件遠超預期。不管哪種情況,審查界面都開始打折扣——可能一次只讓你看一個文件,也可能每個文件都得先加載好才能閱讀,甚至基礎操作都會卡得讓人難受。部分問題確實是硬骨頭,做一些妥協可以理解,但代價真實存在:審查者會感受到工具的邊界,而產品團隊則必須為這些邊界造各種補救措施。
差異渲染這件事本身很重要,但對大多數工具來說,它并不是最終產品。真正的產品是圍繞代碼發生的種種——審查流程、自動化機制、程序輸出、持續集成結果、團隊協作。代碼審查工具理應為這些工作提供支撐,而不是淪為每個團隊都得從零搭建的基礎設施。
大約半年前,我們發布了 Diffs 組件,目標就是讓代碼和差異的渲染本身“能用就行”,好讓團隊把精力花在圍繞它的產品上。最初上線時只有最基礎的 File 組件和 FileDiff 組件,很快就收到了性能方面的反饋。于是我們緊接著推了一個簡易虛擬化方案,讓視口之外的代碼不必渲染,同時提供了一套接口,把語法高亮轉移到后臺線程執行。這個簡易虛擬化確實有改善,但終究只是權宜之計——復雜度仍然是 O(n×m) 級別,內存占用居高不下,虛擬化過程還會出現空白閃爍。
真正的缺口,是一個能管住整塊審查界面的高階組件,由它來處理規模帶來的難題。于是 CodeView 應運而生:一個虛擬化優先、專為審查代碼與差異而設計的組件。我們給它定下了一個近乎不可能的目標——任何差異,拿過來就應該能直接渲染。當然,這只是理想。瀏覽器有物理極限,算力和內存也不是無限的。但就實際體驗來說,我認為我們已經非常接近了。
特別聲明:以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布,本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.