?譯者 | 仇凱

審校 | 孫淑娟

除了人工智能，沒有什么比無代碼和低代碼這兩個術(shù)語更讓開發(fā)人員感到恐懼了。DevOps使我們能夠?qū)⒌鞒套詣踊?，以提升軟件開發(fā)效率，但我們并不希望低代碼平臺取代開發(fā)人員！

實際上，就像信息技術(shù)中的大多數(shù)名詞一樣，低代碼平臺這種命名并不高明。尤其是在API領(lǐng)域，低代碼實際上扮演著提升開發(fā)人員生產(chǎn)力和增強系統(tǒng)魯棒性的角色。最重要的是，它使得開發(fā)人員在不改變自身職責(zé)的情況下，更樂于接受自身是創(chuàng)造性知識工作者的角色。開發(fā)人員可以放棄重復(fù)且令人沮喪的工作，專注于真正有價值的事務(wù)！

企業(yè)級的API蔓延問題

IDC預(yù)計，到2022年底，90%的新增數(shù)字服務(wù)是基于API構(gòu)建的。正如RedHat公司Holly Cummins近期的說法，“我們試圖通過微服務(wù)將應(yīng)用系統(tǒng)功能解耦，但有時它們會耦合的更緊密。分布式和解耦是不一樣的概念?！?/p>

事實上，系統(tǒng)分布式的節(jié)點越多，系統(tǒng)架構(gòu)就越龐大，集成和使用的第三方功能就越多，堆棧就越復(fù)雜，系統(tǒng)對人員、數(shù)據(jù)和代碼的依賴程度也越高。開源代碼使用的越多，這種情況就會變得越糟糕。大多數(shù)企業(yè)無法評估當(dāng)前或者未來一段時間內(nèi)自身系統(tǒng)的API蔓延情況，因此他們每季度發(fā)布一次新版本，而不是按天或半月進行發(fā)版。這與客戶對新功能的迫切需求是互相矛盾的。而且這樣做的風(fēng)險很高，因為這樣的更新策略涉及的系統(tǒng)功能、模塊、接口等錯綜復(fù)雜，很可能出現(xiàn)兼容性問題而影響正常發(fā)版，同時出現(xiàn)異常后會更難以回滾至前一個正常版本。很難在出現(xiàn)大面積故障時，將所有相關(guān)人員召集在一起處理問題。

團隊工作和工具廣泛的分工協(xié)作，使得單個問題會涉及非常多的團隊、人員和功能。在這種情況下，企業(yè)決策和處理故障的效率會很低。它犧牲了開發(fā)人員在處理問題時的靈活性和自主權(quán)。

這一切都歸結(jié)在高度細化的團隊、部門和部門之間的職責(zé)劃分，這種職責(zé)劃分使得企業(yè)很難把控全局狀態(tài)并協(xié)調(diào)資源。這會導(dǎo)致嚴重的資源浪費，因為這是在重復(fù)造輪子。

這種開發(fā)人員效率損耗的成本是驚人的。

2021年DevOps年度報告發(fā)現(xiàn)，缺乏足夠的自動化流程來處理重復(fù)任務(wù)，與自助服務(wù)平臺的欠缺，共同限制了系統(tǒng)質(zhì)量、效率和規(guī)模的提升和發(fā)展。2021年，谷歌云API經(jīng)濟狀況報告發(fā)現(xiàn)，集中式API治理的欠缺，直接引發(fā)了企業(yè)對系統(tǒng)穩(wěn)定性、可擴展性、合規(guī)性和安全性的擔(dān)憂。在《Designing Web APIs》一書中，作者表示，API的設(shè)計和實施缺乏一致性，開發(fā)人員的使用體驗糟糕，這兩種情況會嚴重影響開發(fā)人員的工作效率。最令人羞愧的是，每周開發(fā)人員在調(diào)試和重構(gòu)不一致的代碼上的時間消耗至少是17個小時。所有這一切最終會導(dǎo)致每年約3000億美元的經(jīng)濟損失！

低代碼類似于自動更正

這種松耦合的現(xiàn)狀不僅會使發(fā)布周期變長，同時還意味著開發(fā)人員在大量重復(fù)性工作中浪費時間。一項針對600名工程師的調(diào)查讓他們陷入沉思，開始思考可以在哪些方面可以避免時間浪費，提升工作效率：

• 人工測試更改/編寫腳本：37%
• 重構(gòu)舊代碼：35%
• 實現(xiàn)新功能或特性：33%

這些工作中只有一項能夠為客戶提供真正的商業(yè)價值。企業(yè)正面臨著巨大的人才成本及龐雜的配套工具堆棧，同時很多團隊之間的溝通和協(xié)作出現(xiàn)脫節(jié)，成為決策和發(fā)版的障礙和瓶頸。從腳本一直到不穩(wěn)定的版本，這些是人工操作和高度定制的流程。企業(yè)正在通過冗長且昂貴的招聘流程來補充不良代碼帶來的問題，而不是在改善流程和協(xié)作方式上投入資源。

在人員流失嚴重的時候，這將成為一個棘手的問題。作為開發(fā)人員，我們總是喜歡迎接新的挑戰(zhàn)。我們是創(chuàng)意工作者，需要新的問題、工具和應(yīng)用場景來展現(xiàn)我們的特長。我們渴望與商業(yè)價值建立更緊密的聯(lián)系。實現(xiàn)這一目標的唯一方法是盡可能的將重復(fù)性工作自動化，使我們更專注于創(chuàng)造性的任務(wù)。

通過采用集中式的API治理方式，你可以為企業(yè)中相似的應(yīng)用場景創(chuàng)建能夠 重復(fù)使用的模塊化API，僅在必要時對API進行自定義、新增或擴展。這會在企業(yè)中實現(xiàn)系統(tǒng)的一致性和可預(yù)測性——從字段一直到響應(yīng)代碼。不要在同一個地方被絆倒兩次。通過由規(guī)范驅(qū)動的API開發(fā)來實現(xiàn)不同級別的自動化流程，這意味著高效且優(yōu)質(zhì)的文檔——不會在文檔中迷失，或關(guān)聯(lián)到與目標不相符的API！

通過低代碼API開發(fā)，你可以在整個API生命周期內(nèi)自動踐行最佳實踐。它還可以實現(xiàn)更多跨職能、跨組織的協(xié)作，讓每個人的體驗都保持一致，從而更輕松地將技術(shù)改進與業(yè)務(wù)目標聯(lián)系起來。在不斷的發(fā)展過程中，企業(yè)對單個交互節(jié)點的關(guān)注程度和安全性需求是持續(xù)變化和增長的，低代碼平臺能夠盡可能的滿足企業(yè)的這些需求——自動化平臺可以確保只有滿足質(zhì)量和安全級別要求的API能夠正常發(fā)布。

如果你要在系統(tǒng)堆棧中開始自動化的旅程，那么從API開始是好的辦法。向集中式API治理的轉(zhuǎn)變已經(jīng)平均提升了開發(fā)人員65%的工作效率。

總體而言，集中式API管理方法通過標準化、可靠性、復(fù)用性和自動化縮短了產(chǎn)品的發(fā)布周期。最重要的是，它提升了開發(fā)人員的滿意度。

通過API平臺來建立規(guī)范

正如WriteOps創(chuàng)始人Chris Cooney最近在DZone上所寫的那樣，“DevOps是否有成效并沒有定論，但低代碼或許是提高生產(chǎn)力、提升專注領(lǐng)域并交付價值的重大改變”。

前面提到的IDC報告還預(yù)測，未來兩年內(nèi)，70%的企業(yè)將通過在低代碼平臺中投入資源，來降低定制企業(yè)系統(tǒng)的成本和復(fù)雜度。通過這兩個觀點，顯而易見的是：未來是低代碼和平臺驅(qū)動的。

想象一下，為不斷重復(fù)的問題浪費時間和精力，缺乏專業(yè)的知識儲備，以及日益復(fù)雜的需求和問題。這些場景一直在阻礙企業(yè)的發(fā)展，而API管理平臺正在逐步成為這些場景的最佳解決方案。單一平臺將復(fù)雜問題抽象化，使得開發(fā)人員不必在數(shù)量眾多的工具中反復(fù)切換，也不必勞心與不同的團隊進行溝通和協(xié)作。通過恰當(dāng)?shù)腁PI管理工具，你或者一個團隊可以創(chuàng)建專門用于構(gòu)建的工作流或?qū)⒛阆矚g用的工具集成到平臺中。

對于大多數(shù)企業(yè)而言，基于平臺的API方法意味著良好的一致性和可見性——這是治理、風(fēng)險、合規(guī)和安全團隊特別喜歡看到的。而且，開發(fā)人員仍然擁有工具選擇權(quán)和發(fā)布自主權(quán)，同時又能夠致力于解決重大而有趣的問題。通過這種方式，低代碼不再是工作被自動化代替的預(yù)兆，而是一種讓你的工作輕松擺脫枯燥乏味的方式。

譯者介紹

仇凱，51CTO社區(qū)編輯，目前就職于北京宅急送快運股份有限公司，職位為信息安全工程師。

原文標題：??How a Low-Code API Platform Delivers Developer Productivity???，作者：Rakshith Rao?