北京
你打開一個代碼合并請求，本意是想搞清楚這次改了什么。對于中小規模的變更，一切正常運轉：代碼清晰可讀，文件一目了然，你上下翻動、添加審閱意見，整個過程相當順暢。
可一旦遇上大場面，情況就急轉直下。也許是某個自動化程序一口氣生成了實現代碼、測試用例、固定數據和快照文件；也許是這個分支碰過的文件遠超預期。不管哪種情況，審查界面都開始打折扣——可能一次只讓你看一個文件，也可能每個文件都得先加載好才能閱讀，甚至基礎操作都會卡得讓人難受。部分問題確實是硬骨頭，做一些妥協可以理解，但代價真實存在：審查者會感受到工具的邊界，而產品團隊則必須為這些邊界造各種補救措施。
差異渲染這件事本身很重要，但對大多數工具來說，它并不是最終產品。真正的產品是圍繞代碼發生的種種——審查流程、自動化機制、程序輸出、持續集成結果、團隊協作。代碼審查工具理應為這些工作提供支撐，而不是淪為每個團隊都得從零搭建的基礎設施。
大約半年前，我們發布了 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.
