2022年軟體開發的十五種趨勢 - geekculture

1. 可觀察性[跟蹤、監控和記錄]是至關重要的!
你正在開發你的軟體，並且你已經準備好部署它。所有的測試都透過了，測試覆蓋率也達到了一個不錯的水平。知道了這一點，我們就可以部署我們的程式碼，並繼續平靜地工作。儘管這不是最理想的情況（也很罕見），但我們的程式碼仍然可能失敗。是的! 因此，開發人員需要一直觀察他們的程式碼，並讓它一直報告指標。萬一有什麼故障，你需要讓你的系統準備好向你提供日誌。

可觀察性是至關重要的。沒有它，開發者就是瞎子。它讓我們有機會隨時對系統中發生的每個問題做出反應。

2. 同時使用 "無伺服器 "和 "有伺服器 "方法是一個很好的做法。
在這種情況下，我們可以從兩種軟體開發方法中獲益。
無伺服器是一種在沒有任何伺服器參與的情況下執行應用程式（看似）的方式。當然，這是一個重大的簡化--總是有伺服器參與其中；只是在這種情況下，你不需要對它們做任何事情，而且它們是預先配置好的。它被吹捧為新的黑科技，除了......它並不是解決所有疾病的完美療法。首先，你不能配置底層伺服器，正如我們之前提到的。你也不能真正知道引擎蓋下有什麼。這個主要的缺點同時也是這個方法的主要優點。你不需要配置任何東西，所以與其說是部署⇾擔心，不如說是部署⇾忘記。

無伺服器或有伺服器的解決方案都有好處。在現代系統中，通常會加入兩種方法來獲得大部分的解決方案。

3. 容器化一切! Kubernetes是一項熱門技術!
並非所有的軟體開發趨勢都是好主意。你還記得CoffeeScript或Ruby嗎？很遺憾，我們有。幸運的是，Kubernetes（K8S）看起來並不像要加入這兩者的悲哀谷中。K8S正在使DevOps專家的生活變得更加、更加、更加容易。

以下是引入容器化和容器協調作為你的技術戰略的核心條款所能帶來的好處。

• 你將能夠輕鬆地最佳化你的IT基礎設施成本
• 由於無縫擴充套件，你的使用者可以期待更高的可用性和更好的SLA
• 使用Kubernetes使你的團隊能夠更容易地使用多雲解決方案
• 由於容器和容器編排工具是不分技術的，你可以使用任何你想要的技術來建立一個更精簡的團隊
• 透過容器化，你不再遇到 "它在我的機器上能用 "這一古老的問題

Pearson案例研究 | Kubernetes：
縮短新功能的上市時間，將配置速度從幾個月提高到幾分鐘，並確保為一家服務於 7500 萬使用者的教育公司提供高 SLA。

Prowise 案例研究 | Kubernetes：
應用程式版本之間的停機時間為零，新部署幾小時到幾秒，在包含許多產品的複雜開發環境中，新版本的速度提高了 3 倍。

Zalando 案例研究 | Kubernetes：
歐洲時尚電子商務領導者使用 K8s 實現可擴充套件性，支援多種業務用例，如當日交付、多租戶，增加其產品和地理範圍，並使他們能夠重寫和建立所有 SaaS 產品他們一直用作定製軟體。

阿迪達斯案例研究 | Kubernetes：
電子商務網站的載入時間減少了一半，每天釋出多次而不是每月一次，由於阿迪達斯轉向雲原生，開發人員擁有更多的自主權。

4. 當涉及到軟體架構時，我們應該分而治之
大規模的單體在某種程度上是一個昨天的故事。它們長期困擾著開發者，不過現在已經不是了。將巨大的單一程式碼庫分割成較小規模的應用程式是新的做事方式。它可以使你的應用程式防火，減少錯誤的頻率，使應用程式在發生錯誤時更加安全。缺點是，應用程式變得更難測試，而且需要更多的資源來完成。對於規模較小的團隊來說，維持一個單體還是比較有意義的。

將一個單體應用劃分為獨立的微服務。

5. 開源和自由軟體是未來的方式。
React、Angular和Zuul，分別來自Meta（曾經是Facebook）、谷歌和Netflix，是無數開發者每天在工作中使用的工具。如果沒有這些組織向所有願意使用它們的人免費釋出的工具，每個人的工作就會變得更加困難。無數的服務將不會出現在陽光下，因為編寫這些應用程式太難或太耗時了。所有這些都是因為，在編寫這些應用程式之前，人們必須弄清楚如何為規模而編寫前端，而不分享所學到的經驗將是極其低效的。

這就是為什麼我們要讚揚開源和自由軟體的維護者、創造者以及所有其他為創造和維護這種軟體做出貢獻的人。

創造一種工具/技術並使其開源（或使其免費），給組織帶來永恆的榮耀。

6. 使用架構模式
在軟體開發中，有一條常見的規則--不要重新發明車輪。知道我們很可能曾經面臨過與別人相同的問題，這條規則就變得更有價值。這就是為什麼世界各地的工程師和開發人員都使用建築模式來構造他們的專案--而不是把時間浪費在思考如何找出別人已經想出的解決方案上。

許多現代的軟體都使用CQRS和Event Sourcing等模式。不要重新發明輪子，要使用這些模式。

7. 程式語言在不斷髮展。
我們有越來越多的新的程式語言這一事實並不奇怪。它們都是來來去去，離開後又被其他語言取代。沒有人再用Algol或Pascal編碼了。然而，有一個老前輩，C，仍然存在，儘管這是個值得單獨探討的話題。

一個值得注意的方面是它們在這些年裡的演變方式。起初，命令式語言是唯一存在的。然後，物件導向的語言蓬勃發展，現在，有些人可能會爭辯說，它們正被更靈活的語言所排擠，這些語言混合了一些命令式、函式式和物件導向的特性。

語言的發展方式越來越獨立於我們工作的系統，也越來越獨立於我們的系統。現代語言是跨平臺的。由於DevOps的發展，語言的選擇變得越來越不重要了。

8. 由於現代的基礎設施，複雜性正在從應用程式轉移到外部平臺。
在地下室的物理伺服器上的傳統基礎設施被雲供應商和相關技術所取代。我們有作為服務的虛擬機器、作為服務的資料庫和作為服務的許多其他資訊元素。軟體解決方案中的主要規劃已經轉移到了基礎設施的高水平設計，因為很多東西可以在此基礎上自動化。此外，我們還有容器和容器協調。它接管了複雜性，因為我們可以把系統分成更小、更簡單的部分。

應用程式程式碼變得更加獨立於平臺。然而，複雜性在於基礎設施和運營。應用程式開發人員越來越關注業務邏輯。DevOps工程師處理其餘部分。

9. SCRUM != AGILE
採用特定的流程通常會導致學習行為，最終形成習慣。至少，這是它的理論。

然而，在某些情況下，流程仍然是流程，人們只是為了走過場而苦苦掙扎，但行為從未發展。這樣想吧，你見過多少開發團隊經歷了所有的Scrum儀式，但實際上沒有以敏捷的方式工作？太多了嗎？我們同意。

那麼你能做什麼呢？首先，團隊買入，這永遠是需要建立的第一步。如果你的團隊沒有看到使用這種方法工作的價值，那麼從長遠來看，所有的流程和儀式都不會有什麼進展。

第二步是確保你有一個優秀的Scrum主管和專案經理，以確保良好的實踐被傳遞下去，並確保任何反對意見被採納。

第三步是認識到：當敏捷價值和Scrum框架沒有任何價值時，將其強行灌輸到人們的喉嚨裡，會讓你很快就一無所獲。我們在題為 "Scrum不是每個IT專案的答案（itmagination.com）"的文章中已經詳細介紹了這一點以及更多的內容。

SCRUM可以是敏捷的，但它並不能保證敏捷性。敏捷性來自於行為，而不僅僅是流程。

10. 持續安全
正如我們以前多次寫過的那樣，安全不能是事後的想法。我們不能簡單地 "留待以後"。檢查應用程式的安全問題必須被整合到DevOps流程中，並且從第一天開始就整合到開發流程本身。幸運的是，我們可以使用一些工具來使這個過程無摩擦。Snyk就是其中之一。這是一個全面的工具，"找出並自動修復你的程式碼、開源依賴、容器和基礎設施作為程式碼的漏洞[...]"。

我們必須在開發週期中應用安全檢查程式。安全是信任的基礎--未來的貨幣。

11. 審計雲供應商的服務價格
由於三個主要的雲端計算供應商幾乎不享有競爭，而且他們提供的服務的差異是（或多或少）任意的。在現實中，我們可能看到的唯一差異是服務價格的差異。這就是為什麼，對這個特定的供應商有偏見並不一定是壞事。大多數情況下，確實沒有什麼區別。

選擇你感到滿意的、已經瞭解的供應商。邊走邊評估，不要害怕改變。

雲供應商沒有虛擬競爭，也沒有成本套利。雲基礎設施的成本非常依賴於通貨膨脹和經濟衰退。

12. 一切都可以 "作為一種服務 "來做。
平臺即服務，基礎設施即服務，資料庫即服務，軟體即服務，後臺即服務......我們沒有給你更多的例子，你應該明白我們的意思。你能想到的一切都可以由第三方完成並出售給你。

使用這些服務是一種折衷。你放棄了一些控制權，以便變得更精簡，能夠更快地迭代，同時也能在前期節省一些錢。

由於雲供應商和無伺服器方法的重要性的增長，每一個軟體都可以作為一個服務來完成。

13. 每個人都在使用Visual Studio Code
Visual Studio Code在世界範圍內掀起了一場風暴。有微軟的支援，有開源許可證，用TypeScript編寫，並允許輕鬆擴充套件功能，這些組合都是偉大的決定。到目前為止，文字編輯器是現代程式設計師中最受歡迎的選擇。其他選擇，如基於Intellij的整合開發編輯器（IDE）或Vim，都在Code的陰影下，儘管JetBrains的Fleets可能會改變這種情況。

由於有多種擴充套件和定製工具，VS Code成為開發者中最受歡迎的IDE。

14. 如今，TensorFlow被廣泛使用
TensorFlow是谷歌的機器學習框架，在程式設計師中是一個非常受歡迎的選擇。首先，它在GitHub的最多星級儲存庫中排名前20。然後，有多個埠，包括JavaScript埠，團隊在他們的例如React Native應用程式，或React或任何其他JS框架的Web應用程式中使用。這提供了巨大的靈活性，並允許團隊將解決方案嵌入許多解決方案中。

由於TensorFlow，我們可以在網路應用中實現AI解決方案。用於訓練的模型是由庫提供的。開發人員應該專注於訓練它們。

15. 一個很好的長期僱用策略是僱用後輩並培訓他們
僱用後輩（後起之秀的年輕人）是一個很好的長期戰略。雖然沒有適合所有公司的 "最佳策略"，但僱用後輩並培訓他們絕對是成長和保留內部人才的最佳方式之一。

僱用後輩是一個很好的方式，可以隨著時間的推移慢慢擴大你的團隊，並建立一個內部文化，與僱用那些可能已經定型的人相比，更容易塑造。初中生還能提供一個新的視角，並更多地接觸到當前的趨勢。

在一些情況下，這並不理想，例如，當你的公司需要迅速擴大規模和開發新功能時。如果你有一個小的內部團隊，由於不現實的開發期望，他們總是試圖趕上他們的積壓工作，這也不是最好的。在這種情況下，僱用一個外部技術合作夥伴來幫助開發，同時同步擴大內部團隊的規模，可能是一個很好的中間解決方案。

僱用後輩來培訓他們的策略並不是沒有陷阱。加入你的團隊的年輕人沒有經過以前公司的審查，他們沒有工作經歷，而且很可能是一擊即中。不幸的現實是，雖然這種策略在適當的補償方案下可以很好，但初級僱員可能會發現自己處於這樣的位置：他們只需轉移公司，而不是等待或推動晉升或加薪，就可以使自己的工資翻一番、三番，甚至四番。

這就是為什麼擁有透明的工資和薪資表是如此重要，以顯示人們在職業道路上可以在哪裡以及如何晉升。這就是為什麼擁有優秀的入職培訓計劃也非常重要，以確保花在培訓後輩上的時間得到很好的利用，使導師和學員都受益。