周末的晚上，百無聊賴，于是我擺弄起 JetBrains 的 Projector。IntelliJ 是一款非常強大的 IDE，而 Projector 就是安裝在遠程服務器上、能夠通過瀏覽器訪問的 IntelliJ。

　　我想試試看，如果將一些繁重的計算任務（比如訓練和評估大型機器學習模型）從本地轉移到遠程服務器上，會不會影響編程用戶的體驗。

　　項目的設置非常容易，從點擊 AWS 上的“創(chuàng)建實例”，到我的 iPad Pro 上運行一個成熟的 AI 項目，前后花了不到一個小時。

　　感覺一切都很神奇。

　　將開發(fā)環(huán)境從本地機器上移動到遠程服務器，這個概念大膽而新穎。這種方式可以有效地將工作流集中到大型服務器上。那么，此時的 localhost 是什么呢？

　　當然，這個想法并不是 JetBrains 獨有的。微軟的 Visual Studio Code 也在朝著相同的方向發(fā)展，不僅已有了在線服務，而且所有 GitHub 代碼庫現在都支持在線的 VSCode。Replit 之類的小公司也在嘗試將 IDE 轉變?yōu)槎嗳梭w驗。

　　在自己的服務器上編程也不再意味著必須依賴本地設備了，因為這種方式本質上是將編寫代碼的機器與實際運行代碼的機器相分離。

　　這個想法打開了新的機遇與大門。

　　軟件與硬件的獨立

　　從軟件方面來說，完全遠程的環(huán)境可以讓開發(fā)人員不再受雙啟動、驅動不兼容等問題的煩擾，開發(fā)環(huán)境就在 Ubuntu 服務器上，所有工具的使用都會變得更加容易。同時，我還可以本地 macOS機器上保留 Lightroom、Cinema 4D 和 Photoshop。理論上你甚至可以將部分 Adobe CreativeCloud 打包成 Docker，但是否合法就未可知了（畢竟聽上去這種想法不太正常）。

　　更有趣的是硬件的獨立。將計算全權委托給專業(yè)的供應商，我們就可以獲得巨大的靈活性，同時也不必再糾結一些權衡利弊，例如 CPU 與電池、硬盤與價格、電池與重量等。

　　我可以在小巧的 iPad 上寫代碼，配備 XHDR 顯示器，電池壽命更長，內部驅動器相對較小，同時我仍然在 Linux 環(huán)境中工作，不僅有 CUDA 驅動程序，而且還可以訪問 Nvidia GPU 或 Google TPU。如果臨時需要更多 RAM 來訓練大型模型，則可以擴展我所消費的服務，完成之后再收縮。

　　因此，非常經濟實惠。

　　如果我的遠程實例24小時全年無休地運行，則每月大約需要支付 35 美元。但是，我可以在周末（甚至晚上）關閉實例。這樣就可以節(jié)省35%～50%的成本。另一方面，成熟的MacBook Pro 以每月 50 美元的速度貶值，因此算下來成本反而增加了 40%～50%。這些節(jié)省下來的成本可以投資購買屏幕更大、重量更輕、電池壽命更長的客戶端設備。

　　此外，遠程開發(fā)環(huán)境的擴展性也很好，團隊越大，遠程開發(fā)服務器的效率就越高。數據科學等大型團隊已經采用了這種方式：在遠程實例上運行 Jupyter notebook 是很常見的做法，團隊可以遠程連接到服務器，然后迭代AI 模型。隨著支持多人協作的成熟云 IDE（比如JetBrains 的 Code With Me、VisualStudio 的 Live Share）的發(fā)展，從理論上說，這一概念可應用于不同的開發(fā)團隊，從而大幅削減成本。

　　我并不是第一個有這種想法的人。

　　例如，MightyApp 將 Chrome 虛擬化，他們的目標是用戶無需購買昂貴的硬件，將運行現代網絡應用所需的計算能力外包給他們，這樣既能享受高性能，同時也能節(jié)省維護的成本。

　　然而，隱私方面的影響也是深遠的。這就是為什么雖然 Replit 和微軟希望我們朝著這個方向邁進，但我不認為專有云 IDE 將成為現代軟件開發(fā)的未來的原因之一。如果開發(fā)人員輸入的每一個字符都會被記錄或匯總成報告，那么他們就不太可能會冒險，不論這種方式有多么合適，他們也不會調整自己的工作安排。如此一來，開發(fā)人員學習和工作的速度都會受阻，他們的表現可能會回歸到團隊的平均水平。而這絕不是我們希望看到的局面。

　　但隱私只是一個方面。大多數遠程開發(fā)服務器的優(yōu)勢都在于擁有對整個技術棧的控制，尤其是服務器本身。

　　你不需要再關心底層的機器，也不再需要旁門左道，而且還能獲得更多的微觀管理機會。云 IDE 最吸引用戶的地方莫過于外包原始的計算能力，同時保持對底層硬件的控制。

　　這是編程的未來嗎？

　　說實話，我也不確定。

　　盡管我非常喜歡在 iPad 上運行 Tensorflow，但我也有兩個疑慮。

　　首先，蘋果 M1 芯片的成本效益帶來的沖擊很大。有些人報告說他們的開發(fā)速度有了數量級的提升。如果能夠擁有如此強大且廉價的本地機器，又何必使用開發(fā)服務器呢？隨著計算能力需求的不斷增長，PC 的性能也在持續(xù)提升。這種趨勢與需要在瀏覽器中運行的 IDE 截然相反，而且這種趨勢不會輕易消亡。

　　其次，事實證明，跨平臺移動開發(fā)只是一個破碎的美夢（蘋果和 Google 為此付出了太多努力）。原生客戶端的表現更佳，它們的速度更快，延遲更低，并且可以更好地與本地機器交互（比如快捷鍵就是個很大的問題）。移動應用的問題不僅限于計算能力，現代手機芯片很強大，但與原生應用相比，React Native 簡直不堪一擊。在瀏覽器中運行的 IDE 能夠提供與原生本地實例相同的用戶體驗嗎？

　　我有點矛盾。

　　我希望能夠將開發(fā)環(huán)境轉移到遠程服務器，同時研發(fā)更好的本地設備，與客戶端更好的交互，而不是更快的機器來運行代碼。

　　但目前我們還沒有發(fā)展到這個水平。

　　Chromebook在朝著正確的方向發(fā)展，這絕非偶然。Google 試圖實現“一切皆云”的宏偉愿景。但是，我覺得 Chromebook 不適合編程：糟糕的鍵盤、糟糕的屏幕、糟糕的 shell 體驗。

　　我們需要將這個概念提升到一個新的水平：讓遠程服務器完成所有繁重的工作，同時投資硬件和軟件工具，改善開發(fā)人員的體驗。

　　我很好奇，能否有人打開新局面，并徹底地改變我們與機器的交互方式。