什么是函數(shù)式編程？使用函數(shù)式編程為什么會有幫助呢？

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

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

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

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

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

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

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

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

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

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

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

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

現(xiàn)在，想象一下，你每次使用微波爐時，洗碗機的循環(huán)設置會從一般程序變?yōu)槠抗耷逑闯绦?。當然，這在現(xiàn)實世界中并不會發(fā)生，但在軟件中，這樣的情況卻一直出現(xiàn)。程序員編寫調用一個函數(shù)的代碼，期望執(zhí)行單個任務。但是許多函數(shù)都有副作用，會改變共享的全局狀態(tài)，從而導致意想不到的后果。

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

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

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

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

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

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

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

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

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

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

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

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

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

與大多數(shù)語言不同，函數(shù)式編程語言深深植根于數(shù)學。這種邏輯極為嚴密的數(shù)學血統(tǒng)正是函數(shù)式語言最大的優(yōu)勢。

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

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

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

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

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

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

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

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

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

審核編輯：劉清