對於企業來說，效率就是一切。開發效率的工程化建設已經開始被各大企業提到技術管理日程中。而且現階段，無論是框架也好、模板也好，目的都是在爲提升代碼開發效率而努力。隨着雲計算的深入，端+雲的開發模式以及完全雲端化的開發模式都先後上線，這些無疑都是在對傳統 IDE 開發模式的挑戰。雲端 IDE，會是未來的趨勢嗎？
雲時代下，萬物上雲正在影響企業研發效率工程化建設
萬物上雲，可以說已經是不可逆的大趨勢。對於企業來說，只要可以提升業務交易額、降低成本、提升收益，業務是放在本地還是雲端都無所謂。但是在當前快節奏的背景下，效率就是企業的一切，企業更加關注如何更加快速、高效、敏捷地提升企業交付效率與降低運維成本，這也是爲什麼現如今企業研發效率的工程化建設已經被越來越多的企業提上了日程。
業務上雲後，可以顯著提升企業的交付效率並降低運維成本，這是已經被實踐所證明過的。因此當企業從原來的技術架構中切換或建設不同的雲計算服務時，都會對工程效率產生影響，而受這部分影響的最直接人羣就是相關業務線下的一線開發者。理念的變化與架構的調整，都使得這羣開發者感覺越來越“不舒服”。
近年來，DevOps、敏捷交付等旨在提升業務研發效率的體系不斷被更多人所接納。但是理念很好，落地在實踐中卻往往是另一回事。對此，InfoQ採訪了華爲公司主任工程師、持續交付項目總架構師趙彥，從華爲的一系列實踐舉措中，爲大家總結如何實現研發體系的高效化。
趙彥認爲，先進的理念往往需要配套同等理念的工具來並行，這樣才能更好地支撐 DevOps 或敏捷開發的理念落地。同時，因爲現在是一個知識爆炸的時代，對於企業和個人來說都要求站在巨人的肩膀上不斷進行快速創新。那麼能否進行快速創新，實際上已經成爲了決定企業生存的關鍵因素，因此敏捷交付也被越來越多的企業提上了內部體系改造的行動表上。並且在內部體系優化改造的過程中，隨着業務競爭加劇和技術進步，越來越多的企業將研發能力定位爲其核心競爭力之一，開發者作爲研發能力的核心代表，其自然也成爲了受“影響”的對象。
雲時代的大趨勢對於開發者有怎樣的影響？
趙彥認爲，企業業務上雲已經成爲必然的趨勢。在這種趨勢下，對於普通開發者來說，他們的研發方式包括工作習慣都在不經意間產生了很大的變化，總結起來有以下4點：
- 交付對象發生了變化，原來交付的是單體軟件，交付之後的運維是由第三方或者客戶自己來負責。而現在提供給用戶的是一個雲端的服務，表明交付對象由單體軟件變更爲雲端線上服務。
- 服務架構發生了變化，因爲不再是單體軟件，所以目前對於操作系統的依賴不會特別強。但是由於很多應用都是跨平臺的，用戶更多地會依賴移動端或者是通過便攜式設備來訪問服務，因此整個服務架構都在向着雲原生的架構變化。
- 交付頻率發生了變化，以前的交付是大顆粒度且有明確固定的交付日期和規律，然而現在線上的問題會瞬間反饋回來，業務要求後臺必須要加速交付的節奏，因此就要在最短的時間內響應市場的變化，導致交付的上線次數更多、迭代週期更短、要求的質量更高。
- **交付模式發生了變化，現在提供給用戶的不再是一款產品，而是一個服務，這個服務的最終目標就是要讓用戶滿意。用戶在實際使用過程中的需求和任何反饋都是產品不斷進行快速迭代的根本性因素。在這種條件下，現在的交付模式基本上是“定義原型-產品上線-用戶反饋”**這樣的節奏來實現快速的特性迭代。把最受用戶歡迎的功能優先迭代上線，通過運維繫統反饋回來的數據，觀察所交付功能與預期價值是否匹配，反過來再修正商業目標與交付計劃，從而形成一個閉環。如果說原來團隊所走的是從1到100米的直線，那麼現在就是不停的在跑圈，並且每一圈的速度會不斷加快。
改變低效的現狀根源要從 IDE 工具開始
不可能啊，我測試的時候好使啊！
讓我們先回顧一下 IDE 工具的歷史，最早大家寫代碼的時候其實是很簡單的文本編譯器，先把文本寫成代碼文件再拿去構建或編譯，然後再通過輸出日誌來查看結果是否正確。
但是這種方式太過低效，所以就把調試、運行、引入第三方功能等各種各樣的能力集成到編譯器中去，就形成了各種各樣的代碼編譯器。就像最常見的 Visual Studio Code 這種經過多年發展的大型 IDE 環境，其功能已經非常完整，並已經形成了非常成熟的自有開發生態。
但生態的成熟往往會帶來一個問題，就是對於開發者來說這個環境太重了，且非常依賴於本地的資源系統。衆所周知本地 IDE 在運行時會佔用大量的系統資源，對於機器的配置要求較高，且對於移動化辦公非常不友好。
在當前這種要求效率的開發環境下，尤其是在強調“團隊效益”至上的企業文化中，往往需要將個別優秀程序員在業務中的成功實踐當做案例來分享給團隊。但是在這種相對獨立的開發環境，個人的成功很難複製到整個團隊中，很難做到研發分享流程的標準化。並且由於每個人都在獨立的環境下進行代碼編寫，每個人的環境配置都不盡相同，很有可能導致兩邊運行的效果出現較大差異。這也是爲什麼很多程序員都會說：“不可能啊，我測試的時候好使啊！”
在全業務上雲的當下，本地 IDE 環境在對接雲端時往往出現連接縫隙，這是因爲本地到雲端會面臨大量的如鑑權、網絡穩定性等問題，所以在和雲端應用或業務配合開發的時候，無法將本地 IDE 環境的效能與雲端的優勢發揮的最大化。
雲端 IDE 如何改變開發者的使用習慣？
儘管“雲正在吞噬世界”已經喊了很多年了，但開發者仍然是習慣於本地的 IDE 環境，這個多年來的習慣是很難改變的，作爲華爲雲在雲端開發環境的全新探索，CloudIDE 將如何改變用戶的開發習慣呢？
趙彥認爲，想改變這種習慣就要先接納這種習慣。之所以 CloudIDE “長成”現在這個樣子，是經過大量的市場調研後發現 Visual Studio Code 這款工具是最受開發者歡迎的開發工具，所以華爲雲 CloudIDE 在使用體驗、操作體驗方面都選擇向 Visual Studio Code 靠攏。
這種好處就是用戶從現有的本地 IDE 環境遷移到雲端 CloudIDE 後，不會因爲環境的改變而造成學習成本的上升；此外 CloudIDE 內置了標準化的技術棧，比如說開發 Java，半分鐘之內就能得到一個 Java 的開發環境，且裏面已經內置了 Java 所需的 SDK；最後用戶在創建環境的時候，基於 CodeHub 的代碼模板所提供給開發者樣例工程，可以讓開發者的開發不會從0開始，而是通過現有的知識積累，從80%開始自己的創新。
針對本地 IDE 來說，提供移動、跨設備式接入，也就是說不管用的是 PC、筆記本還是 pad，只要有輸入輸出設備，只要能夠連接網絡，都可以接入進來進行開發。
這就是雲端 CloudIDE 目前所做的一些努力。
當然就目前來說，雲端 IDE 相較於本地 IDE 仍存在一些不足
但是這都是可以通過技術發展去彌補的。
相較於本地 IDE 非常豐富的研發生態和極其優質的開發體驗，雲端 IDE 還是存在一些不足的，主要體現在開發體驗層面，主要有以下幾點因素：
- 瀏覽器因素，訪問雲端 IDE 環境是一定要用到瀏覽器的，而瀏覽器本身就是一個應用，自身本就會侵佔部分的快捷方式，可能會屏蔽部分用戶的輸入，從而造成在代碼編寫過程中某些快捷鍵失靈的情況。
- 延遲因素，本地 IDE 編譯器都有相應的代碼補全機制，本地 IDE 只要電腦不卡就可以實現急速響應。但是如果這種機制放在雲端的話就需要前後臺的配合，通過後臺提供服務才能響應，這就會存在一定的延遲。
- 網絡因素，目前雲端 IDE 必須線上才能使用，不支持離線編碼，因爲程序員在進行開發的時候需要雲端容器來分配資源，訪問的時候也需要訪問如插件拓展等大量針對編程語言的特定服務，這個過程中，網絡是必不可少的。
- 安全因素，很多開發者不放心將代碼放到雲上原因之一，很大一部分是擔心雲端的可用性、代碼安全性、斷連後能否恢復等機制是否健全的問題。雲端服務的可用性是最基本要求，如果可用性不高，會降低用戶的安全感，會造成用戶一些諸如“在雲端數據會不會丟失”等顧慮。針對這種情況 CloudIDE 做了很多優化，比如把服務專門遷移到華爲雲 CCE 集羣服務上以此來提升服務的安全性與穩定性；對服務的容器做了嚴格權限控制，把開發者的高階 Root 權限全部回收的同時，爲了保證開發者能夠在這種等級的權限下開展研發活動，後臺做了很多的優化和配置，從而能夠讓開發者在受限的權限內使用容器環境。
所以說，目前用戶不想遷移到 CloudIDE 上，主要是因爲體驗方面的原因。但是從長期來看，這種體驗上的差距會通過不斷的技術創新以及未來的全新的網絡接入方式所慢慢的彌補。
CloudIDE 代表着未來，其已經廣泛應用在了各種創新場景下
移動創新場景，CloudIDE 只是華爲雲 DevCloud 實現雲端全流程開發中的一部分，CloudIDE 通過與 CodeHub 代碼託管服務相結合，在通過 CloudIDE 服務創建共創空間時，可以直接引入 CodeHub 中的代碼模板來直接創建實例，從而讓開發者能夠在極短的時間內形成樣例代碼，加快了開發者嘗試新功能的效率；此外開發者應該都會感同身受，做開發也是需要靈感的，有時候這種靈感稍縱即逝，因此就需要實時的移動化辦公來支持這種需求。通過 CloudIDE 即可通過一臺輕量化的辦公筆記本，甚至一部可以聯網的智能手機就可以實現在雲端的代碼作業（當然，移動端的輸入方式等目前暫不做討論。），真正實現了移動化辦公，不再侷限在辦公區域。
輕量化開發場景，這一塊場景主要針對於微服務和雲原生領域，因爲微服務本身的代碼量較小所以不會出現重載的情況，同時 CloudIDE 提供了多種內置技術棧，正好適應了微服務開發這種強調服務獨立交付、獨立運營的特點，所以用戶在 CloudIDE 上開發微服務之後，可以快速的將應用推送到雲端代碼倉庫，繼續進行自己的微服務交付，保證 DevOps 的交付體驗；此外通過 CloudIDE 服務配合 DevCloud 的其它服務工具鏈，可以讓用戶在開發完服務代碼之後直接推送到雲端倉庫並拉起業務流水線，實現 CI、CD 的持續集成與敏捷交付能力。
教育培訓場景，因爲 CloudIDE 是活躍在雲端的一款 IDE 工具，可以有效支持大規模併發和環境標準化能力，在大規模學生上課、考試的場景下可以通過 CloudIDE 來快速創建課堂或考場。並且在使用完畢後可以實現資源的快速釋放，有效降低教育培訓的成本，提高教育的效率和質量。
速度、成本與可用性對於開發者的重要性
速度、成本和可用性一直都是開發者最關注的三個因素，圍繞這三個因素，也是未來雲端 IDE 的重點發力方向。
- 成本的降低，開發者經常會問到這種開發的收費模式是怎樣的，會與現階段所應用的本地IDE環境成本進行比較。雲端 IDE 環境既然在雲上，其價格同雲計算的收費形式類類似，都是按需收費的彈性制，與本地 IDE 相比的花費成本肯定是更低的。另外趙彥提到，隨着技術的發展，雲端 IDE 基座的穩定，成本只會進一步壓縮，用戶將會以更低廉的價格來體驗雲端代碼服務。
- 秒級啓動，目前 CloudIDE 冷啓動的速度是在40s左右，在特定的場景下可以達到15s。但是這種速度相較於本地 IDE 來說肯定是處於劣勢的。因此未來將會努力實現秒級的冷啓動，使雲端加載速度能夠更快。
- 交付體驗的完善，分別爲急速響應體驗的優化與輸入方式體驗的提升。比如上文所提到的用手機來進行開發，但是對於移動端來說輸入方式一直是個令人頭疼的問題，那麼未來能否通過語音或更好的方式來改善開發者在移動端輸入代碼的體驗，這也將是未來的一個發展方向。
- AI 輔助功能，在使用本地 IDE 環境進行開發時，會經常用到本地 IDE 的代碼補全機制。在雲端開發同樣也要如此且不限於如此。當開發者在開發應用時，很難保證其知識儲備是齊全的。通過人工智能或後臺大數據分析等各種科學的方法，向開發者快速推薦代碼片段甚至是引導開發者使用現有的知識體系來進行開發，這對開發者來說會是一個非常大的助力。
- 插件生態的完善，相較於本地 IDE，雲端 IDE 的插件生態還不是特別完善，且目前能對接到的服務相當有限，尤其是在用戶將業務對接到雲端 IDE 平臺上後，會有大量對接第三方資源庫方面的需求，因此上線及豐富插件市場將會是未來雲端 IDE 的重點發展方向之一。
雲端 IDE 對於企業和開發者，究竟有着怎樣的價值？
古人說過一句話，工慾善其事必先利其器，想要落地先進的理念必須要有相配套的工具。從研發效率提升的角度來看，IDE 環境的變更只是其中的一個環節，從工程效率的提升來說，則是開發者從內心到接受工具變化的整個過程。
具體來說，趙彥老師總結了以下3點：
- 首先具體到每一名開發者，要有開放合作的心態，願意接受先進技術所帶來的有益變化，願意將自己的資源放在雲端，願意通過知識共享來獲得研發效率的提升；
- 其次企業要具備快速創新的能力和意願，因爲企業在競爭中要生存下來，依靠的不僅僅是效率，更是需要在商業層面的快速創新，只有擁有了在特定場景下更好的創新能力，才能實現更快速的創新。因此更需要一套理論結合實踐的工具來做支撐，以保證在業務快速迭代的雲時代下能夠讓研發體系向着敏捷的方向發展。
- 最後從開發者的角度來看，雲端 IDE 能夠讓研發工作始於80%，而不是從0開始。對於開發者來說，最討厭的事情就是“糾結”，但是往往這種情緒是伴隨整個研發過程的。從最開始採用怎樣的語言和框架就已經開始，涉及到業務後這種糾結只會越來越多，整個糾結的過程只會讓研發效率越來越慢。雲端 IDE 通過與雲端實例相連，在 CloudIDE 引入新項目時本身就有很多成功的樣例可以參考，可以直接在前人的基礎上開始做。不用擔心環境配置問題，也不用糾結技術棧框架問題，從而使開發者可以集中精力來進行關鍵功能的開發，這是雲端 IDE 對於開發者來說最主要的價值所在。
寫在最後
雲計算正在吞噬萬物，這並不是一句空話。在 2019 年，傳統企業紛紛上雲，互聯網企業紛紛在雲原生領域開始落地，萬物上雲不再是一個願望，而是一個正在加速實現的現實。從業務上雲到流程上雲到管理上雲，再到如今將最根本的代碼編寫流程搬到雲端，業務全流程上雲已經是不可逆的趨勢，也將是未來發展主流。華爲雲 CloudIDE 將在這條路上積極探索，開拓雲計算時代下的高效研發新方向。