低程式碼平臺能提升開發效率嗎?
譯者 | 仇凱
審校 | 孫淑娟
除了人工智慧,沒有什麼比無程式碼和低程式碼這兩個術語更讓開發人員感到恐懼了。DevOps使我們能夠將迭代流程自動化,以提升軟體開發效率,但我們並不希望低程式碼平臺取代開發人員!
實際上,就像資訊科技中的大多數名詞一樣,低程式碼平臺這種命名並不高明。尤其是在API領域,低程式碼實際上扮演著提升開發人員生產力和增強系統魯棒性的角色。最重要的是,它使得開發人員在不改變自身職責的情況下,更樂於接受自身是創造性知識工作者的角色。開發人員可以放棄重複且令人沮喪的工作,專注於真正有價值的事務!
企業級的API蔓延問題
IDC預計,到2022年底,90%的新增數字服務是基於API構建的。正如RedHat公司Holly Cummins近期的說法,“我們試圖通過微服務將應用系統功能解耦,但有時它們會耦合的更緊密。分散式和解耦是不一樣的概念。”
事實上,系統分散式的節點越多,系統架構就越龐大,整合和使用的第三方功能就越多,堆疊就越複雜,系統對人員、資料和程式碼的依賴程度也越高。開原始碼使用的越多,這種情況就會變得越糟糕。大多數企業無法評估當前或者未來一段時間內自身系統的API蔓延情況,因此他們每季度釋出一次新版本,而不是按天或半月進行發版。這與客戶對新功能的迫切需求是互相矛盾的。而且這樣做的風險很高,因為這樣的更新策略涉及的系統功能、模組、介面等錯綜複雜,很可能出現相容性問題而影響正常發版,同時出現異常後會更難以回滾至前一個正常版本。很難在出現大面積故障時,將所有相關人員召集在一起處理問題。
團隊工作和工具廣泛的分工協作,使得單個問題會涉及非常多的團隊、人員和功能。在這種情況下,企業決策和處理故障的效率會很低。它犧牲了開發人員在處理問題時的靈活性和自主權。
這一切都歸結在高度細化的團隊、部門和部門之間的職責劃分,這種職責劃分使得企業很難把控全域性狀態並協調資源。這會導致嚴重的資源浪費,因為這是在重複造輪子。
這種開發人員效率損耗的成本是驚人的。
2021年DevOps年度報告發現,缺乏足夠的自動化流程來處理重複任務,與自助服務平臺的欠缺,共同限制了系統質量、效率和規模的提升和發展。2021年,谷歌雲API經濟狀況報告發現,集中式API治理的欠缺,直接引發了企業對系統穩定性、可擴充套件性、合規性和安全性的擔憂。在《Designing Web APIs》一書中,作者表示,API的設計和實施缺乏一致性,開發人員的使用體驗糟糕,這兩種情況會嚴重影響開發人員的工作效率。最令人羞愧的是,每週開發人員在除錯和重構不一致的程式碼上的時間消耗至少是17個小時。所有這一切最終會導致每年約3000億美元的經濟損失!
低程式碼類似於自動更正
這種松耦合的現狀不僅會使釋出週期變長,同時還意味著開發人員在大量重複性工作中浪費時間。一項針對600名工程師的調查讓他們陷入沉思,開始思考可以在哪些方面可以避免時間浪費,提升工作效率:
- 人工測試更改/編寫指令碼:37%
- 重構舊程式碼:35%
- 實現新功能或特性:33%
這些工作中只有一項能夠為客戶提供真正的商業價值。企業正面臨著巨大的人才成本及龐雜的配套工具堆疊,同時很多團隊之間的溝通和協作出現脫節,成為決策和發版的障礙和瓶頸。從指令碼一直到不穩定的版本,這些是人工操作和高度定製的流程。企業正在通過冗長且昂貴的招聘流程來補充不良程式碼帶來的問題,而不是在改善流程和協作方式上投入資源。
在人員流失嚴重的時候,這將成為一個棘手的問題。作為開發人員,我們總是喜歡迎接新的挑戰。我們是創意工作者,需要新的問題、工具和應用場景來展現我們的特長。我們渴望與商業價值建立更緊密的聯絡。實現這一目標的唯一方法是儘可能的將重複性工作自動化,使我們更專注於創造性的任務。
通過採用集中式的API治理方式,你可以為企業中相似的應用場景建立能夠 重複使用的模組化API,僅在必要時對API進行自定義、新增或擴充套件。這會在企業中實現系統的一致性和可預測性——從欄位一直到響應程式碼。不要在同一個地方被絆倒兩次。通過由規範驅動的API開發來實現不同級別的自動化流程,這意味著高效且優質的文件——不會在文件中迷失,或關聯到與目標不相符的API!
通過低程式碼API開發,你可以在整個API生命週期內自動踐行最佳實踐。它還可以實現更多跨職能、跨組織的協作,讓每個人的體驗都保持一致,從而更輕鬆地將技術改進與業務目標聯絡起來。在不斷的發展過程中,企業對單個互動節點的關注程度和安全性需求是持續變化和增長的,低程式碼平臺能夠儘可能的滿足企業的這些需求——自動化平臺可以確保只有滿足質量和安全級別要求的API能夠正常釋出。
如果你要在系統堆疊中開始自動化的旅程,那麼從API開始是好的辦法。向集中式API治理的轉變已經平均提升了開發人員65%的工作效率。
總體而言,集中式API管理方法通過標準化、可靠性、複用性和自動化縮短了產品的釋出週期。最重要的是,它提升了開發人員的滿意度。
通過API平臺來建立規範
正如WriteOps創始人Chris Cooney最近在DZone上所寫的那樣,“DevOps是否有成效並沒有定論,但低程式碼或許是提高生產力、提升專注領域並交付價值的重大改變”。
前面提到的IDC報告還預測,未來兩年內,70%的企業將通過在低程式碼平臺中投入資源,來降低定製企業系統的成本和複雜度。通過這兩個觀點,顯而易見的是:未來是低程式碼和平臺驅動的。
想象一下,為不斷重複的問題浪費時間和精力,缺乏專業的知識儲備,以及日益複雜的需求和問題。這些場景一直在阻礙企業的發展,而API管理平臺正在逐步成為這些場景的最佳解決方案。單一平臺將複雜問題抽象化,使得開發人員不必在數量眾多的工具中反覆切換,也不必勞心與不同的團隊進行溝通和協作。通過恰當的API管理工具,你或者一個團隊可以建立專門用於構建的工作流或將你喜歡用的工具整合到平臺中。
對於大多數企業而言,基於平臺的API方法意味著良好的一致性和可見性——這是治理、風險、合規和安全團隊特別喜歡看到的。而且,開發人員仍然擁有工具選擇權和釋出自主權,同時又能夠致力於解決重大而有趣的問題。通過這種方式,低程式碼不再是工作被自動化代替的預兆,而是一種讓你的工作輕鬆擺脫枯燥乏味的方式。
譯者介紹
仇凱,51CTO社群編輯,目前就職於北京宅急送快運股份有限公司,職位為資訊保安工程師。
原文標題: How a Low-Code API Platform Delivers Developer Productivity ,作者:Rakshith Rao
- Spring中實現非同步呼叫的方式有哪些?
- 帶引數的全型別 Python 裝飾器
- 整理了幾個Python正則表示式,拿走就能用!
- SOLID:開閉原則Go程式碼實戰
- React中如何引入CSS呢
- 一個新視角:前端框架們都卷錯方向了?
- 編碼中的Adapter,不僅是一種設計模式,更是一種架構理念與解決方案
- 手寫程式語言-遞迴函式是如何實現的?
- 一文搞懂模糊匹配:定義、過程與技術
- 新來個阿里 P7,僅花 2 小時,做出一個多執行緒永動任務,看完直接跪了
- Puzzlescript,一種開發H5益智遊戲的引擎
- @Autowired和@Resource到底什麼區別,你明白了嗎?
- CSS transition 小技巧!如何保留 hover 的狀態?
- React如此受歡迎離不開這4個主要原則
- LeCun再炮轟Marcus: 他是心理學家,不是搞AI的
- Java保證執行緒安全的方式有哪些?
- 19個殺手級 JavaScript 單行程式碼,讓你看起來像專業人士
- Python 的"self"引數是什麼?
- 別整一坨 CSS 程式碼了,試試這幾個實用函式
- 再有人問你什麼是MVCC,就把這篇文章發給他!