你可能認為軟件產品生命周期中耗時最長、費用最高的階段是系統的初期開發階段，因為所有美妙的功能都是在這一階段構想出來的。而事實上，最困難的部分是后期的維護階段。在這個階段，程序員將為自己在開發過程中走的捷徑付出代價。那么，程序員為什么要走捷徑？可能性有很多：也許他們沒有意識到自己在“投機取巧”；只有代碼被許多用戶部署并執行時，隱藏的漏洞才會暴露出來；開發人員時間緊，也可能導致缺陷；此外，產品上市時間的壓力幾乎肯定會讓軟件包含更多的錯誤。

大多數公司維護代碼的難題導致了第二個問題：脆弱性。添加到代碼中的每個新功能都會增加代碼的復雜性，從而增加程序中斷的機會。軟件變得越來越復雜，開發人員因為害怕出現程序中斷，如非絕對必要，都盡量避免改動軟件，這是很普遍的現象。在許多公司中，整個開發團隊的工作不是為了做任何新的開發，而只是為了保持現有系統的運行。你可能會說，這就像是軟件版本的紅皇后效應，奮力奔跑只是為了停在原地。

這種現狀令人遺憾。然而，軟件行業目前的發展趨勢就是復雜度越來越高、產品開發時間越來越長、運行系統的脆弱性越來越高。公司一般只能投入更多人力來解決這些問題：更多的開發人員、更多的測試人員、更多的技術人員在發現系統漏洞時及時干預。

當然，一定有更好的方法。越來越多的開發人員認為這一問題的答案可能是函數式編程。本文中，我描述了什么是函數式編程，使用函數式編程為什么會有幫助，以及我為何如此熱衷于函數式編程。

為更好地理解函數式編程的基本原理，我們先回顧半個多世紀前發生的事情。20世紀60年代后期，為了提高代碼質量，減少所需的開發時間，一種編程范式應運而生，稱為結構化編程。

各種語言的出現促進了結構化編程的發展，為了更好地支持結構化編程，一些已有的語言被修改。結構化編程語言最顯著的特征之一，是消除了一個長期存在的特征：GOTO語句。

GOTO語句用于程序執行的重新定向。程序流不是按順序執行下一條語句，而是重定向至其他某個語句，即GOTO行中指定的語句，通常需滿足某些條件。

取消GOTO語句是基于程序員在使用GOTO的過程中學到的教訓——它讓程序非常難以理解。帶有GOTO語句的程序通常被稱為“意大利面代碼”，因為指令序列執行可能就像一碗意大利面，難以單鏈跟隨。

開發人員無法理解自己的代碼是如何工作的，或者為什么代碼有時不工作，這是一個復雜的問題。那個時代的軟件專家認為，GOTO語句造成了不必要的復雜性，因此必須消除這些GOTO語句。

這在當時是頗為激進的想法，許多程序員拒絕消除自己一直依賴的語句。相關爭論持續了十多年，最終，GOTO不存在了，今天也沒人主張它再次回歸。這是因為在高級編程語言中消除GOTO語句大大降低了復雜度，提高了生產軟件的可靠性。這是通過對程序員的限制實現的，其結果是程序員更容易推理自己編寫的代碼。

盡管軟件行業已經從現代高級語言中消除了GOTO語句，但軟件的復雜度和脆弱性仍在繼續上升。如果想看看還能修改哪些編程語言以避開一些常見的陷阱，你會很奇怪地發現，軟件設計師往往能在硬件同行那里找到靈感。

在設計計算機硬件時，電阻不能共用，比如鍵盤和顯示器電路就不能共用電阻。但程序員在軟件中卻一直在做這種共用，也就是全局狀態共享：變量不由某一個進程所有，而可由任意數量的進程進行更改，甚至可以同時更改。

現在，想象一下，你每次使用微波爐時，洗碗機的循環設置會從一般程序變為瓶罐清洗程序。當然，這在現實世界中并不會發生，但在軟件中，這樣的情況卻一直出現。程序員編寫調用一個函數的代碼，期望執行單個任務。但是許多函數都有副作用，會改變共享的全局狀態，從而導致意想不到的后果。

在硬件中，這種情況不會發生，因為物理定律限制了這種可能性。當然，硬件工程師也可能會搞砸，但不像軟件那樣有太多的可能，且有好有壞。

另一個潛藏在軟件“沼澤”中的復雜怪物被稱為空引用，即引用內存中某個位置根本不指向任何內容。一旦嘗試使用此引用，就會出現錯誤。因此，程序員必須牢記，在嘗試讀取或更改引用的內容前，需檢查該引用是否為空。

當今幾乎所有流行的語言都存在這一缺陷。先驅計算機科學家托尼?霍爾（Tony Hoare）早在1965年就在ALGOL語言中引入了空引用，空引用后來被納入許多其他語言?；魻柦忉屨f，自己這樣做“僅僅是因為它很容易實施”，但今天他認為這是一個“數十億美元的錯誤”。因為當程序員期望的是有效引用而實際上是空引用時，便會導致無數錯誤。

軟件開發人員需要非常自律，才能避免此類陷阱，但有時他們沒有采取足夠的預防措施。結構化編程的架構師知道GOTO語句確實是陷阱，未給開發人員留下任何逃避的借口。為保證無GOTO語句的代碼獲得預期的清晰度改善，他們知道必須在結構化編程語言中完全消除GOTO語句。

歷史證明，刪除危險特征可大大提高代碼的質量。今天，許多危險的習慣做法損害了軟件的魯棒性和可維護性。幾乎所有現代編程語言均有某種形式的空引用、全局狀態共享和帶有副作用的函數，這些要比GOTO語句糟糕得多。

如何消除這些缺陷？事實證明，答案已經存在幾十年：純函數式編程語言。

第一個流行的純函數式語言稱為Haskell，創建于1990年。因此，軟件開發領域如今依舊面臨的棘手問題早在20世紀90年代中期便已有了解決方案。遺憾的是，當時的硬件通常不夠強大，無法使用該解決方案。但今天的處理器已經能夠輕松管理Haskell和其他純函數式語言的需求。

事實上，基于純函數的軟件特別適合現代多核CPU。這是因為純函數僅靠輸入參數運行，因而不同函數間不可能存在交互。這使我們可以對編譯器進行優化，生成在多個內核上高效、輕松運行的代碼。

顧名思義，純函數式編程意味著開發人員只能編寫純函數，既然是純函數，便不會產生副作用。這種限制提高了穩定性，打開了編譯器優化的大門，最終生成的代碼更容易推理。

但若是函數需要知道或操作某個系統的狀態，又該如何？這種情況下，狀態會由一長串“組合函數”進行傳遞——一個函數將其輸出傳遞給下一個函數作為輸入。將狀態自一個函數傳遞至另一個函數，每個函數都可以訪問該狀態，且不會出現另一個并發程序線程對該狀態進行修改——這是在太多程序中發現的常見且代價高昂的脆弱性。

函數式編程亦可解決霍爾的“十億美元錯誤”：空引用。解決的方法是不允許值為空。另外，有一種結構通常稱為Maybe（或某些語言中的Option）。Maybe的值可以是Nothing或Just。使用Maybe結構，開發人員不得不始終考慮這兩種情況。在這件事上他們別無選擇，每一次遇到Maybe時都必須處理Nothing的情況。這樣做可以消除空引用可能造成的許多錯誤。

函數式編程還要求數據不可變，這意味著一旦將變量設置為某個值，該值就永遠不變。變量更像是數學中的變量。

例如，要計算方程y= x2+ 2x - 11，需要為x選擇一個值，并且在計算y的過程中，x都不會取不同的值。因此，計算x2時使用的x值與計算2 x時所用的x值是相同的。在大多數編程語言中沒有這樣的限制。可以使用一個值計算x2，然后在計算2 x之前更改x的值。不允許開發人員將賦值更改（變異），他們可以使用與中學代數課相同的推理過程。

與大多數語言不同，函數式編程語言深深植根于數學。這種邏輯極為嚴密的數學血統正是函數式語言最大的優勢。

為何是這樣？因為人們研究數學的歷史已有數千年之久。它牢不可破。而大多數編程范式（如面向對象的編程）背后的歷史最多只有60年，相比之下顯得粗糙且不成熟。

不妨通過一個例子來說明編程與數學相比有多“草率”。通常情況下，我們會告訴編程新手在第一次遇到語句x = x + 1時忘記自己在數學課上學的東西。在數學中，這個方程為零解。但在當今的大多數編程語言中，x = x + 1不是一個等式。它是一個語句，命令計算機讀取x的值，將其加1后，放回名為x的變量中。

在函數式編程中，沒有語句，只有表達式。我們在用函數式語言編寫代碼時可以使用在中學學到的數學思維。

由于函數的純粹性，我們可以使用代數替換來推理代碼，從而幫助降低代碼復雜性，就像回到代數課上，降低方程復雜性一樣。在非函數式語言（命令式語言）中，則并無同等機制來推理代碼是如何工作的。

純函數式編程刪除了編程語言中的危險特征，解決了我們行業中的許多大問題，開發人員也不容易出現“搬起石頭砸自己的腳”的問題。這些限制起初可能看來很極端，我可以肯定地說，20世紀60年代開發人員對消除GOTO也有相同感。但事實是，使用函數式語言既不失自由，功能又強大，以至于當今幾乎所有最流行的語言都包含了函數功能，盡管它們本質上仍然是命令式語言。

這種混和編程方法的最大問題在于它仍然允許開發人員忽略語言的函數性質。如果50年前保留GOTO作為一個選項，我們可能至今仍面臨著“意大利面代碼”的困境。

要獲得純函數式編程語言的全部好處，就不能妥協。需要使用從一開始就符合這些原則設計的語言。只有這樣，才能獲得本文闡述的許多益處。

但函數式編程并非易事，要有所付出。學習使用此類函數范式編程幾乎就像從頭再學編程一樣。許多情況下，開發人員必須學習那些學校里不曾教過的數學知識。所需的數學并不難，但是新知識，而且對于數學恐懼癥人群來說很可怕。

更重要的是，開發人員需要學習一種新的思維方式。因為不熟悉，起初這會讓人感到有負擔。但隨著時間的推移，新的思維方式習慣成自然，與舊的思維方式相比，最終減少了認知成本，效率也就會大幅提升。

審核編輯：劉清