咱們之因此一遍又一遍地聽到上述問題，背後是有緣由的。爲了保持競爭力，企業天天都須要新的軟件功能，但隨着時間的流逝，咱們交付軟件的速度彷佛停滯不前，或者更糟，變得更慢了。前端
我想解釋爲何會這樣。不過，爲了探討這個話題，須要先了解一個我最關心的話題：本質複雜性和偶發複雜性。後端
任什麼時候候，當你在解決一個問題，不只僅是軟件問題，都有兩種類型的複雜性：安全
本質複雜性——這是包含在問題中的複雜性。若是不解決這種複雜性，就沒法解決問題。它也被稱爲內在複雜性。微信
偶發複雜性——這是用來解決問題的方法和工具所帶來的複雜性。這種複雜性不是你要解決的問題的一部分，而是在解決方案中引入的複雜性。它也被稱爲偶然複雜性。網絡
IBM 360 系統之父 Fred Brooks 在經典論文「沒有銀彈：軟件工程的本質性與附屬性工做」中提出了這個概念。能夠這麼想，若是你要解決一個數學問題，本質複雜性就是指對數學的瞭解，由於只有懂數學才能解題。若是你想解決這個問題，要麼學習所需的數學知識，要麼找個懂數學的人幫忙。若是你想解決這個問題，就沒法逃過學習數學這一關。架構
咱們假設，這是一個頗具挑戰性的數學問題，徹底用人腦來解決是徒勞的，因此須要使用計算器。這就是偶發複雜性。還記得第一次使用圖形計算器的情形嗎？在這個時候，偶發複雜性就是學習如何在計算器上輸入全部複雜的數學信息來幫你解決問題。你不必定要使用計算器，但你知道它對你有用，並且不會太難學。app
如今，咱們假設你對 Mathematica 很熟悉。Mathematica 是一個很是強大和複雜的軟件，不過既然你已經知道它了，就決定用它來解決問題。你在學習 Mathematica 上投入了不少，因此不須要不少額外的努力，只是增長了解決方案的偶發複雜性。框架
幾周後，你的一位同事遇到相似狀況，他記得你曾經解決過一個相似問題。他們來找你，看你是如何解決問題的，而後你把 Mathematica 發給他們。你認爲這個時候會發生什麼？你認爲他們會去學習數學嗎？不，他們會想出另外一種解決問題的方法，或者試圖讓你替他們解決問題。分佈式
正如你所看到的，這兩種複雜性來自不一樣的地方，但它們之間有着緊密的聯繫。若是不引入一些偶發複雜性，就沒法解決問題。即便是一支鉛筆和一張紙也會帶來一些微不足道的偶發複雜性。工具
若是沒有偶發複雜性，就沒法解決問題。
這可能會讓你感到驚訝，在過去 20 年中，軟件領域本質複雜性與偶發複雜性比率在急劇降低。David Heinemeier Hansson（Ruby on Rails 之父）用「概念壓縮（conceptual compression）」這個詞來描述這種趨勢以及它是如何讓咱們的行業變得更好的。在過去的 20 年中，開源框架和庫的激增是減小軟件系統偶發複雜性最強大的力量。
與 20 年前相比，解決業務問題所需的代碼量已經減小了一個數量級，所以你可能會認爲開發軟件將比那時快一個數量級。但這種狀況彷佛並無發生，爲何會這樣？
軟件變得愈來愈容易開發，但與此同時，其餘現象也在發生：
-
咱們對軟件的要求愈來愈高 -
公司內部的軟件數量呈爆炸式增加 -
採用新技術的步伐正在加快
儘管咱們正在利用愈來愈多的外部工具和庫來開發軟件，讓軟件開發變得愈來愈容易，但咱們對軟件的要求也愈來愈高，僅這一點就抵消了大量的收益。若是咱們用現代工具來開發 2000 年代的 Web 應用程序，會看到軟件開發的生產力有十倍 (或更多) 的提高。
但咱們的世界並無停滯不前，消費者和企業對軟件的指望一直在迅速增加。咱們指望軟件能比 20 年前作得更多。當咱們開發出這些更大型、功能更豐富的應用程序時，爲了保持它們的可靠性、功能性和可理解性，不得不改變軟件的開發方式。
如下是咱們在過去 20 年裏看到的幾個行業變化：
源碼控制——源碼控制一直都存在，但並不像如今這麼廣泛。不認爲這增長了偶發複雜性？那就去問問第一次使用 Git 的初級工程師，他們是怎麼想的。
自動化測試——咱們引入了不少測試類型和測試工具。咱們須要進行驗收測試、集成測試、單元測試等等……這給項目帶來了大量的偶發複雜性，但有助於確保交付的軟件是高質量的，且功能是符合預期的。
拆分系統——隨着系統複雜性的增長，組件之間鏈接和交互的量會呈二次級數增加。也就是說，在某種程度上，若是軟件設計得很差，交互量將會繼續增加，直到由於自身的複雜性而垮掉。拆分系統，特別是進行分佈式拆分，會帶來大量的意外複雜性。
專門化——隨着 Web 應用程序變得愈來愈複雜，出現了大量的專門化。在 2000 年，由軟件工程師負責 UI 設計、UI 構建和應用程序後端構建都是很常見的事，而到了 2020 年，這些工做須要幾個角色分別承擔。開發 Web 應用程序的團隊一般由 UI 設計師、UX 設計師、前端軟件工程師、後端軟件工程師和 DevOps 工程師組成。在較大的組織中，會有更加專門化的角色，如安全、架構、數據管理、數據科學，等等……全部這些額外的角色讓咱們可以開發更大規模的軟件，但所需的工具和流程了引入大量的偶發複雜性。
基礎設施自動化——爲了構建更大型、更復雜的環境來運行愈來愈多的應用程序，咱們已經開始自動化它們的構建和維護過程。這樣咱們就能夠更容易地進行大規模的環境管理，但須要一整套工具和知識。這些工具帶來的複雜性是巨大的，致使 DevOps 成爲大多數大型團隊的專門角色。
頻繁部署——因爲應用程序的大小和複雜性都在增加，爲了下降風險，咱們須要以較小的增量交付軟件。爲此，咱們引入了持續集成和持續部署的概念。一樣，這對於大規模交付軟件來講是很是好的，但用於構建和操做這些管道所需的工具和技能引入了偶發複雜性。
多設備和形式因素——在之前，咱們能夠說，咱們的軟件運行在一個操做系統上，只有少數的幾種分辨率。如今，咱們的應用程序須要在臺式機、筆記本電腦和跨平臺的移動設備上運行。一般，咱們會有原生移動應用程序和 Web 應用程序，或許還能夠加入一些物聯網應用程序和手錶應用程序。咱們在訪問數據的位置和方式上有了巨大的靈活性，改變了咱們的社會，但無疑增長了軟件開發過程的複雜性。
在閱讀上一個小節前，你可能已經很是清楚，人們對軟件要求愈來愈多以及愈來愈多的軟件開發形式會致使複雜性的增長。可是，從單個應用程序的角度來看，企業擁有更多的軟件會增長開發單個應用程序的複雜性嗎？
答案很簡單：不會，除非你想讓這個軟件與其餘軟件發生交互。一家公司使用的軟件越多，系統之間的重疊就越多，不一樣的系統須要訪問相同的數據才能正常運行，這就須要爲更多的系統保存共享數據，並將全部系統集成起來。
舉個例子，假設在 2000 年，你是一家辦公椅生產商，那個時候你尚未網絡系統。你須要爲公司創建一個庫存系統，因此須要開發軟件來完成這件事。庫存系統的用戶是倉庫工做人員，你能夠經過生成夜間報告來得到庫存信息，這些報告也能夠被髮送給整個公司的人。這個系統相對獨立，報告功能對於每個人來講都沒有什麼問題。
時間快進到 2020 年，你的庫存系統已經不是一個獨立的應用程序。你的合做夥伴能夠直接將訂單推送到你的系統中，Web 頁面能夠得到實時的庫存更新，並在下單時更新庫存。你的庫存系統與物流系統直接集成，這樣就能夠自動生成物流標籤和取貨時間表。你直接在亞馬遜上銷售你的產品，因此你的庫存系統直接與第三方軟件集成。倉庫的工做人員使用移動設備定位、掃描、登記和挑選商品，因此你還有一個用來完成這些事情的移動解決方案。
隨着系統的激增，並覆蓋了業務的各個方面，開始出現愈來愈多的重疊，一直到若是不與其餘系統集成就沒法知足需求的地步。雖然這帶來了史無前例的生產力和自動化程度，但也給數據移動和集成引入了大量的偶發複雜性。
Marc Andreesen 提出了「軟件正在吞噬世界」的說法。這個過程正在加速，並且看不到盡頭。
在 2000 年，你一般會從單個廠商那裏購買系統，如微軟、Sun 或 Borland，你還可能還會購買一些組件，但無論怎樣，整個生態系統都是由單個廠商提供的。此時，你所採用和集成的外部工具和技術相對較少，你所能完成的任務被限制在廠商所提供的功能上。
爲了跟上快速變化的技術格局，公司開始採用更開放的技術。這帶來了巨大的優點，由於你能夠用這些工具完成之前只能在夢中想想的壯舉。但切換工具一般是有代價的，最終會在流程中引入不少偶發複雜性。
雖然使用前沿的技術可能會在某些方面得到好處，但技術越新，維護的難度就越大。並且，越早採用一項技術，當它演化成爲一項對廣大用戶都有用的技術時，你所經歷的痛苦就越多。如何平衡一項新技術所帶來的收益以及使用它所帶來的痛苦是技術專家們長期以來一直在努力解決的問題。
咱們如今發現，挑選有用的工具、框架和技術是一項很是有價值的技能。若是不當心使用了未經驗證的新工具或框架可能會產生有害的影響。它們可能會致使大量的偶發複雜性，更糟糕的是，若是框架在跨越鴻溝以前死亡，就會把你帶入死衚衕。
關於爲何開發軟件須要的時間愈來愈長，緣由還有不少，好比業務須要更快的迭代速度、企業架構標準或對安全性的重視程度，等等。但關鍵是，咱們在 2020 年開發的軟件與在 2010 年開發的軟件幾乎沒有什麼類似之處，更不用說在 2000 年了。在很大程度上，這是一件好事。
但也有很差的地方。咱們彷佛又回到了 2000 年到 2007 年，那時每一個應用程序都是用一樣的工具開發的，而其中有不少工具變得愈來愈複雜。如今，不少流行的工具和框架都來自於大型企業，但它們解決的不少問題是其餘企業不會遇到的。
正由於如此，不少中小型企業，甚至是大型企業的一些部門都發現，他們運行軟件的能力正在迅速降低，並且不知道如何扭轉局面。爲了加快開發速度，他們已經開始轉向低代碼和無代碼，但在不少狀況下，這也破壞了使用這些工具構建的系統的功能和壽命。
原文連接：
https://www.simplethread.com/why-does-it-take-so-long-to-build-software/
純學習的Python公衆號，天天4篇文章，沒有任何廣告！很是適合討厭廣告的Python讀者關注看看！
本文分享自微信公衆號 - 程序IT圈（DeveloperIT）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。