[譯]不變性之道 —— 組合軟體系列

niayyy發表於2020-04-06

不變性之道

函式式程式設計方法

前言

我徘徊在一箇舊圖書館檔案室,發現了一條通往計算機教室的黑暗隧道。在那裡,我發現了一個似乎被遺落在地上的卷軸。

卷軸被裝在滿是灰塵的鐵筒中,上面貼著這樣的標籤:“Lambda(匿名函式)教堂的檔案。”

它被包裹在一張紙裡,上面寫道:


一位高階程式設計師和他的徒弟陷入圖靈沉思中,思考著 Lambda(匿名函式)。徒弟看著師傅,問道:“師傅,你告訴我要簡單化,但是程式是複雜的。框架可以通過消除困難的選擇來簡化建立的工作。那麼類庫和框架哪個更好呢?”

高階程式設計師看著他的徒弟反問道:“難道你沒讀過智者 Carmack 的學說嗎?”,並引用道…

“有時,優雅的實現僅僅是一個函式。不是一個方法。不是一個類庫。也不是一個框架。僅僅是函式”

徒弟又開始說到:“但是,師傅,” —— 但是師傅打斷了他的話,問道:

“‘not functional(無功能)’這個詞不就是 ‘dysfunctional(功能障礙)’嗎?”

然後徒弟明白了。


在這張紙的背面是一個索引,似乎引用了計算機行業的許多書籍。我偷偷看了一眼這些書籍的名稱,但是裡面充滿著我不能理解的詞彙,因此我略過它們,繼續閱讀卷軸。我注意到索引旁邊的空白頁面被寫滿了簡短的評論,我將在這忠實地抄錄這些評論以及卷軸裡面的文字:


不變性: 唯一的不變就是改變。變異隱藏變化。而被隱藏的變化會帶來混亂。因此,智者擁抱歷史。

如果你有一美元,而我又給你了一美元,前一刻你僅有一美元,現在你擁有了兩美元,這一事實並沒有改變。事態的變異會嘗試抹除歷史記錄,但是歷史記錄無法真正被刪除。如果不儲存過去,它將表現為程式中的 bug,再次困擾你。

分離: 邏輯就是思考,效果就是行動。因此,智者三思而後行。

如果你嘗試同時執行效果和邏輯,你可能建立導致邏輯錯誤的副作用。儘可能儲存函式功能的單一。一次只做一件事並做好。

組合: 自然界中萬物和諧相處。沒有水,樹木無法生長。沒有空氣,鳥兒不能飛翔。因此,智者把原料混合在一起,讓湯嚐起來更美味。

規劃組合的方式。設計函式時確保最終編寫的函式的輸出結果可以作為許多其他函式的輸入引數。讓函式標識儘可能的簡單。

節約: 時間是寶貴的,而努力需要時間。因此,智者儘可能地重用他們的工具。愚蠢的人會為每個新的東西創造特殊的工具。

特定型別的函式不能用於其它型別的資料。明智的程式設計師通過 lift 函式來處理多種資料型別,或者把資料包裝為函式所需要的格式。列表和列表項構成了很好的通用抽象。

流動: 流水不腐,戶樞不蠹。智者之所以成功,是因為他們讓事務順其流動。

[編者注:卷軸上唯一的插畫在這節經文的上方,畫面上有一排看起來不同的鴨子在順流而下。我沒有複製插畫,因為我不相信我可以做到這一點。奇怪的是,他的標題是:]


列表像是一條隨著時間推移而變化的水流。


[相應的說明如下:]

共享物件和資料配件(data fixtures)可能導致函式相互干擾。競爭相同資源的多個執行緒會互相阻礙。只有當資料通過純函式自由流動時,才能對程式進行推演並預測結果。

[編者注:卷軸以最後一節經文結尾,沒有註釋:]

智慧: 明智的程式設計師在走上這條路之前,會先了解透徹這條路的走法。因此,明智的程式設計師是有價值的,而不明智的程式設計師會迷失在叢林中。

注意: 這是“組合軟體”系列(叢書)中的從頭學習 JavaScript ES6+ 中的函數語言程式設計和組合軟體技術。後續還有更多文章!敬請關注。

本系列目錄:


埃裡克·埃利奧特(Eric Elliott) 是一名分散式系統專家,並且是《Composing Software》《Programming JavaScript Applications》這兩本書的作者。作為 DevAnywhere.io 的聯合創始人,他教開發人員遠端工作和實現工作 / 生活平衡所需的技能。他為加密專案組建開發團隊並提供諮詢,併為 Adobe 公司、Zumba Fitness、《華爾街日報》、ESPN、BBC 和包括 Usher、Frank Ocean、Metallica 在內的頂級唱片藝術家的軟體體驗做出了貢獻。

他與世界上最美麗的女人一起享受著遠端辦公的生活方式。

如果發現譯文存在錯誤或其他需要改進的地方,歡迎到 掘金翻譯計劃 對譯文進行修改並 PR,也可獲得相應獎勵積分。文章開頭的 本文永久連結 即為本文在 GitHub 上的 MarkDown 連結。


掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群,文章來源為 掘金 上的英文分享文章。內容覆蓋 AndroidiOS前端後端區塊鏈產品設計人工智慧等領域,想要檢視更多優質譯文請持續關注 掘金翻譯計劃官方微博知乎專欄

相關文章