|
交付高質(zhì)量的軟件產(chǎn)品并不是一件容易的事情，再加上混合工作模式的興起和數(shù)字化的加速發(fā)展需求，推動(dòng)著軟件開發(fā)理念及工具的升級(jí)換代。本文探討了在 2022 年軟件工程開發(fā)重塑過程中將起到主導(dǎo)作者用的軟件開發(fā)趨勢(shì)。
盡管流行著一種說法：“每家公司都是軟件公司。”但是擴(kuò)展和交付高質(zhì)量軟件并不是一件容易的事情。隨著技術(shù)棧的不斷變化和新服務(wù)趨勢(shì)的出現(xiàn)，軟件開發(fā)的復(fù)雜性也阻礙著其自身的發(fā)展速度。此外，市場(chǎng)上也缺少足夠的軟件開發(fā)人員：IDC 的數(shù)據(jù)顯示，2021 年全職工程師的稀缺程度為 140 萬，而在未來 4 年內(nèi)，這一數(shù)字將增加到 400 萬。
與此同時(shí)，混合工作模式的興起和數(shù)字化的加速發(fā)展勢(shì)頭，使很多企業(yè)的開發(fā)團(tuán)隊(duì)業(yè)務(wù)需求激增。最后這兩個(gè)因素的出現(xiàn)可能是最后一根稻草，逼迫著軟件傳統(tǒng)開發(fā)理念的改進(jìn)優(yōu)化。
這一現(xiàn)實(shí)狀況，要求軟件工程管理者們必須審慎評(píng)估他們的 2022 年規(guī)劃，并提出改進(jìn)工程團(tuán)隊(duì)、實(shí)踐理論及開發(fā)工具的建議，以應(yīng)對(duì)軟件工程面臨的四個(gè)核心挑戰(zhàn)：
開發(fā)者體驗(yàn)： 旨在引導(dǎo)降低技術(shù)復(fù)雜性，以便開發(fā)者能夠快速創(chuàng)新。
開發(fā)工作流程自動(dòng)化： 從軟件開發(fā)生命周期的不同階段消除所有平臺(tái)和工具間的不協(xié)調(diào)阻礙，使其集成為一個(gè)整體。
安全性和合規(guī)性： 開發(fā)過程中，開發(fā)者創(chuàng)建、修改、刪除的任何操作都可以被追溯，并能夠恰當(dāng)?shù)募m正發(fā)現(xiàn)的錯(cuò)誤，讓開發(fā)人員更輕松的編寫安全代碼。
部署和運(yùn)營： 專注用戶體驗(yàn)，提高軟件服務(wù)的可靠性和性能。
基于以上挑戰(zhàn)訴求，剖析了 2022 年軟件發(fā)展的七個(gè)趨勢(shì)，這些趨勢(shì)將是 2022 年的關(guān)鍵，軟件工程管理者應(yīng)該評(píng)估改進(jìn)開發(fā)團(tuán)隊(duì)、實(shí)踐理論和開發(fā)工具，以實(shí)現(xiàn)公司目標(biāo):
DevSecOps
API 主導(dǎo)的集成
適用專業(yè)人士的低代碼平臺(tái)
云原生平臺(tái)
DesignOps
通用可觀測(cè)性
PWA-first 方法
01
DevSecOps
安全防護(hù)將繼續(xù)作為 IT 管理人員和軟件工程團(tuán)隊(duì)首要關(guān)注的話題。由于勒索軟件攻擊的持續(xù)增加，組織數(shù)據(jù)缺乏明確的限制邊界，以及民用軟件風(fēng)險(xiǎn)的增加，數(shù)據(jù)隱私和監(jiān)管要求比以往任何時(shí)候都更有必要。這導(dǎo)致了對(duì) DevSecOps 的需求增加，其中安全性和合規(guī)性要求在軟件開發(fā)生命周期的每一步都需要驗(yàn)證。
想要維持持續(xù)的改進(jìn)氛圍，以達(dá)到免受軟件鏈路安全威脅和強(qiáng)化軟件交付通道的目標(biāo)，是非常困難的?？吹?CISO 和 CIO 們?cè)谶x擇開發(fā)新的 web 和移動(dòng)應(yīng)用程序時(shí)，會(huì)傾向于選擇能夠管理每個(gè)新應(yīng)用程序開發(fā)和交付全階段的平臺(tái)，而不再依賴于有著不同實(shí)踐經(jīng)驗(yàn)的開發(fā)人員非系統(tǒng)性的改進(jìn)。
最終目標(biāo)是讓開發(fā)團(tuán)隊(duì)能夠在平臺(tái)上輕松構(gòu)建安全代碼，使用零信任安全模型，而不是依賴于安全測(cè)試方法。市場(chǎng)上有不少 數(shù)字服務(wù)提供商 可以幫助你在現(xiàn)有系統(tǒng)中集成 DevOps。
02
混合集成
根據(jù)《2021 年 SaaS 發(fā)展?fàn)顩r》(The State of SaaS Sprawl)，公司平均擁有 254 個(gè) SaaS 應(yīng)用程序，但平均而言，只有 45% 的企業(yè)的 SaaS 應(yīng)用是有用戶在用的。此外，56% 的應(yīng)用程序都是由 IT 部門開發(fā)的，或者是由 IT 部門管理和使用。這里讓人不可思議的是，這部分已經(jīng)超出了公司核心業(yè)務(wù)軟件的數(shù)量。
目前，業(yè)務(wù)用戶熱衷于在缺乏 API 的舊設(shè)備上部署 RPA，這是對(duì)舊系統(tǒng)改造的簡(jiǎn)單方案，但對(duì)于一直在進(jìn)行迭代的數(shù)字業(yè)務(wù)公司來說并不方便。因此，敏捷公司使用的是低代碼開發(fā)平臺(tái)的即時(shí)應(yīng)用修改，其中最突出的就是包含了這些能力。
最重要的是，現(xiàn)在正處于這樣一個(gè)階段：組織比以往任何時(shí)候都更需要跨多個(gè)數(shù)據(jù)源實(shí)時(shí)連接其數(shù)據(jù)管理、治理和可審計(jì)性，這需要在混合集成中使用更多工具。
優(yōu)秀的軟件開發(fā)平臺(tái)或?qū)Ｓ霉ぞ?，可以將來自不?SaaS 平臺(tái)或原有舊系統(tǒng)的數(shù)據(jù)集成到多個(gè)系統(tǒng)和應(yīng)用程序使用的數(shù)據(jù)結(jié)構(gòu)中，這對(duì)于幫助公司管理人員做出數(shù)據(jù)驅(qū)動(dòng)型決策至關(guān)重要。
03
適用專業(yè)人士的低代碼平臺(tái)
2021 年，經(jīng)過市場(chǎng)驗(yàn)證的替代方案便是低代碼平臺(tái)，優(yōu)秀的平臺(tái)供應(yīng)商已經(jīng)幫助企業(yè)解決了具有挑戰(zhàn)性的問題。事實(shí)上，根據(jù)企業(yè)低碼應(yīng)用平臺(tái)的魔力象限：“到 2025 年，企業(yè)開發(fā)的新應(yīng)用程序中有 70% 將使用低代碼或無代碼技術(shù)。”
低代碼并不意味著開發(fā)人員將被業(yè)務(wù)用戶取代。低代碼平臺(tái)提供了一種抽象，可以減少開發(fā)者在創(chuàng)建應(yīng)用或網(wǎng)絡(luò)時(shí)通常面臨的復(fù)雜性。而想要做到更好則依賴于軟件設(shè)計(jì)者進(jìn)行全棧監(jiān)督，以實(shí)現(xiàn)細(xì)粒度控制。
這樣做的目的是，讓那些重復(fù)和日常的任務(wù)，如依賴關(guān)系管理，代碼驗(yàn)證和自動(dòng)構(gòu)建，由平臺(tái)完成，以便開發(fā)人員可以專注于開發(fā)有差異的額外流程，而不用花大量時(shí)間做重復(fù)勞動(dòng)。
04
云原生平臺(tái)
SaaS 方面，云服務(wù)請(qǐng)求的爆發(fā)正在改變“自建 vs 購買”的經(jīng)濟(jì)性和時(shí)間安排。這是因?yàn)?SaaS 發(fā)展不僅使原始預(yù)算暴增，而且還演變成了另一種形式的技術(shù)債務(wù)：在十幾個(gè)系統(tǒng)網(wǎng)絡(luò)之間切換是一種糟糕的體驗(yàn)，會(huì)帶來比較差的業(yè)務(wù)后果。
大型供應(yīng)商的 Web 服務(wù)從五年前的約 30 個(gè)，增加到如今由單個(gè) IaaS 提供商提供多達(dá) 250 個(gè)，這對(duì)于創(chuàng)建云原生應(yīng)用程序的業(yè)務(wù)開發(fā)人員來說是一個(gè)巨大的挑戰(zhàn)。
為了克服這些挑戰(zhàn)，云原生開發(fā)平臺(tái)必須能夠使開發(fā)團(tuán)隊(duì)繼續(xù)專注于其數(shù)字產(chǎn)品的價(jià)值流管理，而不是僅僅在基礎(chǔ)設(shè)施監(jiān)管上耗盡其工程技能。
科技巨頭在爭(zhēng)奪稀缺專業(yè)工程師的競(jìng)賽中具有巨大的優(yōu)勢(shì)，所以那些獲得不到技術(shù)精英的組織便需要采用新的方法來保持創(chuàng)新和團(tuán)隊(duì)競(jìng)爭(zhēng)力。
這意味著，需要找到能夠幫助他們抽象或消除技術(shù)復(fù)雜性的技術(shù)，并能夠讓他們的開發(fā)團(tuán)隊(duì)專注于業(yè)務(wù)成果和創(chuàng)新，就像云原生低代碼平臺(tái)一樣。
05
DesignOps
DesignOps 是一種高效的設(shè)計(jì)運(yùn)作團(tuán)隊(duì)理念，用戶研究團(tuán)隊(duì)和前端設(shè)計(jì)團(tuán)隊(duì)（包括共享存儲(chǔ)庫，工具，資產(chǎn)交換）之間的密切合作會(huì)促進(jìn)組織內(nèi)不同產(chǎn)品團(tuán)隊(duì)之間的協(xié)作，并確保產(chǎn)品體驗(yàn)從交付開始的一致性。
在 2022 年，IT 和應(yīng)用程序開發(fā)預(yù)算已經(jīng)評(píng)估包含混合工作的需求，因?yàn)閱T工和合作伙伴的體驗(yàn)已經(jīng)變得與客戶體驗(yàn)一樣重要——追求極致的使用體驗(yàn)。另外，廣泛和頻繁的使用這些應(yīng)用程序有助于提高公司技術(shù)水平。
這種情況下，公司在滿足用戶體驗(yàn)的同時(shí)，還要推出更多數(shù)字化產(chǎn)品，進(jìn)行大規(guī)模的設(shè)計(jì)管理，同時(shí)最大限度降低專業(yè)性和用戶體驗(yàn)的不足，在這樣的業(yè)務(wù)壓力下，DesignOps 實(shí)踐也便被推到了舞臺(tái)的中心。
06
通用可觀測(cè)性
工程管理者還應(yīng)該重視軟件的可觀測(cè)性，可以與 DesignOps 同步推進(jìn)，以實(shí)現(xiàn)多用戶群支撐。可觀測(cè)性受益于開放標(biāo)準(zhǔn)，可用于日志和指標(biāo)的設(shè)計(jì)，如用于跟蹤的開放遙測(cè)技術(shù)。為了跟上這一趨勢(shì)，更多的數(shù)字開發(fā)團(tuán)隊(duì)將致力于實(shí)現(xiàn)用戶使用指標(biāo)改善，這在過去是很難實(shí)現(xiàn)的。
07
PWA-first 方法
漸進(jìn)式 web 應(yīng)用 PWA 結(jié)合了原生應(yīng)用程序的功能和網(wǎng)站可訪問性，但不需要發(fā)布到應(yīng)用程序商店。與原生應(yīng)用一樣，PWA 可以脫機(jī)工作、發(fā)送推送通知，以及訪問設(shè)備硬件（如相機(jī)或 GPS）。用戶體驗(yàn)類似于移動(dòng)和桌面設(shè)備上的原生應(yīng)用程序，無需下載且沒有更新沖突，這有一個(gè)巨大的優(yōu)勢(shì)——它們?cè)谶B接性差的情況下運(yùn)行良好。漸進(jìn)式的 web 應(yīng)用程序開發(fā) 仍然是全球的發(fā)展趨勢(shì)。
因?yàn)樗鼈兊倪B接彈性設(shè)計(jì)和用戶阻力（不斷在其設(shè)備中安裝本機(jī)應(yīng)用程序），PWA 將在 2022 年繼續(xù)發(fā)展。開發(fā)人員和軟件領(lǐng)導(dǎo)者已經(jīng)有很好的技術(shù)論據(jù)來支持 PWA 優(yōu)先的技術(shù)思維，巨大的數(shù)字需求也加快了這種變化，因?yàn)椋?/div>
從最終用戶的角度來看，PWA 很容易在移動(dòng)設(shè)備上使用 (沒有應(yīng)用程序商店)，并且輕量級(jí)。
從開發(fā)者的角度來看，與原生應(yīng)用相比，PWA 修改速度要快得多，并且更易于維護(hù)。
與原生應(yīng)用不同的是，它們對(duì)所有設(shè)備使用同一個(gè)代碼庫，搜索引擎可以搜索到它們，并且它們很輕量。
08
寫在最后
以上便是2022 年探索的主要軟件工程趨勢(shì)，這些趨勢(shì)已經(jīng)在重塑軟件開發(fā)過程中發(fā)揮著主導(dǎo)作用。無論是新時(shí)代的 DevOps 還是 headless 和 PWA 解決方案，你都需要與時(shí)俱進(jìn)。如果你計(jì)劃為公司開發(fā)軟件，你可以聯(lián)系市場(chǎng)上的各種軟件開發(fā)公司。不過要確保你選擇了一家能滿足你獨(dú)特需求的。
 |
