程序員為什麼需要框架？

Clojure 是一種運行在 Java 平台上的 Lisp 方言，它的出現有助於將比較複雜的表述定義成簡潔的呈現。與此同時，Clojure也具備諸多的工具來解決程序員經常需要面對的難題。

不過隨著對該語言的深度學習與應用之後，Clojure 開發社區中開始出現一批對使用框架有著強烈反感的程序員群體，而這到底是怎麼回事？框架對 Clojure 編程語言來說是否真的多餘？

作者 | Daniel Higginbotham

譯者 | 蘇本如，責編 | 屠敏

出品 | CSDN（ID：CSDNnews）

以下為譯文：

似乎Clojure開發社區對使用框架有著強烈的反感。其它語言可能需要框架，但我們Clojure不需要！因為我們有無所不在的函數庫！

這種態度並非毫無理由。首先，我們當中的很多人都是在深受像Rails這樣的神奇框架荼毒後選擇使用Clojure編程語言的，因為在那裡我們不得不花費大量的時間來處理這些框架的缺點。另外，像Luminus這樣的Clojure開發工具和它捆綁在一起的頂級Web開發庫提供給開發人員一種富有成效的體驗，框架對Clojure編程語言來說似乎是多餘的。

儘管有各種各樣的理由，但是我對Clojure開發社區這種對待框架的主流觀點不太認同。我認為框架對Clojure開發是有用的。首先，讓我解釋一下什麼是框架。我還沒有讀過任何讓我滿意的框架定義，我認為針對框架的一些仇恨源於對它們究竟是什麼缺乏明確的定義。它們只是對開發庫的名稱上的美化嗎？它們必須具備魔法嗎？有沒有強制要求它們的價值必須大過它們製造的麻煩呢？所有這些問題都將在本文中闡明。

我認為，要想讓一個框架的效用容易被大家理解，就必須對這個框架所服務的目的，以及如何實現這一目的，作一個清楚地描述，並且這個描述還應該闡明什麼是一個好的框架，而壞的框架為什麼最終會傷害我們。我希望你會發現這個討論有趣而且令人滿意，並且能夠為你提供一個嶄新的，有幫助的視角，不僅僅是從框架方面，更是從總體編程方面。即使你讀完本文後仍然不想使用框架，我也希望你能更好地理解一個框架所要解決的問題，這會幫助你更好地設計應用程序。

框架具有二級優勢，本文也將介紹這些優勢。概括來說，框架使得可重用組件的生態系統得以存在。框架使編程變得更加有趣。並且框架使初學者更容易出成果。

在本文的最後，我將對Clojure編程語言特別適合創建真正了不起的框架的特性作一個介紹。

什麼是框架？

框架是一組開發庫的集合，它們的職責是：

管理對編寫應用程序所需資源進行協調的複雜性…

通過提供這些資源的抽象...

以及在這些資源之間進行通信的系統...

在一個環境中...

使得程序員能夠專註於編寫特定於其產品的業務邏輯。

下面我將以Rails框架和操作系統（可以稱其為終極框架）作為例子，詳細介紹上面的每一點。

你可能會想，操作系統怎麼會是一個框架呢？當你查看上面的框架職責列表時，你會注意到操作系統不但處理了所有這些職責，而且處理得非常好。簡而言之：操作系統為硬體資源提供虛擬抽象，這樣程序員就不必關注細節，比如將位元組推到某個特定磁碟上或管理CPU調度。它還提供了帶有由正斜杠分隔的名稱組成的定址系統的分層文件系統的協議，並且這些協議提供了一種資源相互通信的方法（進程A可以寫入/foo/bar，而進程B可以讀取）。相像一下，如果每個程序員都有自己的特定的定址系統，那將是一場災難。而現在操作系統為我們處理了這個問題，因此我們可以將重點放在特定於應用程序的任務上。

操作系統作為一個非常成功的框架，下面我們將詳細介紹它們的一些特性，以便更好地了解一個好的框架設計應該是什麼樣子。

協調資源

資源是程序用來完成工作的「材料」，它們可以分為四類：存儲資源、計算資源、通信資源和介面資源。存儲資源的示例包括文件、資料庫和緩存。計算資源的示例包括進程、線程、參與者、後台作業和core.async進程。通信資源則有HTTP請求、消息隊列和事件匯流排。而介面資源通常包括鍵盤和滑鼠，再加上屏幕和用於在屏幕上顯示內容的系統：如GUI工具包、瀏覽器和DOM等等。

專用資源建立在更通用的資源之上（有些人將這些專用資源稱為服務或組件）。我們從硬體開始，在上面構建虛擬資源。對於存儲資源來說，操作系統從磁碟和內存開始，並將文件系統創建為頂部的虛擬存儲資源。像Postgres這樣的資料庫使用文件系統創建另一個虛擬存儲資源來處理文件系統不能滿足的用例。Datomic資料庫則使用其他資料庫（如Cassandra 或 DynamoDB）作為其存儲層。瀏覽器創建自己的虛擬環境並引入新的資源，如本地存儲和cookies。

對於計算資源，操作系統引入進程和線程作為虛擬資源的代表和管理程序執行。Erlang語言使用了一種與底層操作系統顯著不同的流程模型創建了一個環境。Clojure語言的core.async處理了同樣的問題，它引入了通信順序進程（CSP）計算模型。它是由Clojure宏定義的虛擬模型，先「編譯」成核心Clojure，再編譯為JVM位元組碼（或JavaScript！），然後必須由操作系統進程執行。

介面資源遵循相同的模式：在可視顯示端，操作系統向監視器繪製圖像，應用程序向自己的虛擬畫布上繪製圖像，瀏覽器引入了自己的資源（DOM和）的應用程序，而React則引入虛擬DOM。Emacs是運行在操作系統之上的操作系統，它有自己的windows和frames。

資源管理自己的實體(entity)。在資料庫中，entity可以包括表、行、觸發器和序列。文件系統的entity包括目錄和文件。圖形用戶界面的entity包括窗口、菜單欄和其他組件。

（我意識到，這種對資源的描述並不像程序員喜歡的那樣嚴密，公理化和詳盡。其中的一個不足之處是資源和應用程序之間的界限不是非常清晰：Postgres本身是一個應用程序，但從Rails應用程序的角度來看，它又是一個資源。不過，希望我在這裡對資源的解釋已經足夠清楚，你對我對資源的所有闡述都能夠理解。）

協調這些資源本身就很複雜。其實，協調任何事情都不簡單。我還記得我第一次在小聯盟比賽中因為缺乏協調性而被棒球打到臉上。還有一段時間，當時我還是個孩子，我上跆拳道課，當每堂課結束的時候，我經常背靠著牆坐在地上，痛苦地閉著眼睛。原因有兩個：a）我媽媽因為某種原因拒絕給我買護具，b）我缺乏協調性，在對抗練習時不能保護好自己。

在構建一個產品時，你必須決定如何創建、驗證、保護和處置資源實體；如何將實體從一個資源傳遞到另一個資源；以及如何處理諸如競態條件（race condition）下的定時安排和在資源交互時出現的故障處理等問題，所有這些都需要好好協調。例如，Rails框架被設計用來協調瀏覽器、HTTP伺服器和資料庫。它必須將用戶輸入傳遞到資料庫，還必須通過HTTP請求和響應檢索和呈現資料庫記錄以供用戶界面顯示。

沒有一個公認的或絕對正確的方法來協調這些資源。在Rails框架中，HTTP請求將被發送到一個控制器（Controller），該控制器負責與資料庫交互，並使數據能夠為視圖(View)可用，該視圖將渲染可以發送回瀏覽器的HTML。

你並非必須使用Rails框架的MVC（Model/View/Controller）模式來協調Web應用程序的資源，但你必須以某種方式協調這些資源。這些決策涉及到權衡和施加約束，以實現可擴展性（創建一個足夠通用的系統以讓新資源加入）和控制力（允許系統充分利用特定資源的獨特功能）之間的平衡。

即使對於經驗豐富的開發人員來說，這也是一項非常困難的任務，並且你所做的選擇可能會產生負面影響，而且這些負面影響直到你進行了大量投資之後才能明顯看到。例如，在Rails框架中，ActiveRecord（AR）為資料庫提供了一個很好的通用抽象，但在早期，它很容易生成效率極低的SQL，而且有時很難生成高效的SQL。所以你經常需要手工編寫SQL，這就首先消除了使用AR的一些好處。

對於完全初學者來說，正確地做出這些權衡是不可能的，因為這樣做需要經驗。初學者甚至不知道做這些決定的必要性。同時，有經驗的開發人員更願意花時間和精力解決更重要的問題。

而框架會幫助我們做出這些決策，使我們能夠更加專註於業務邏輯。框架通過引入通信系統和抽象來實現這一點。

資源抽象

我們的軟體通過抽象與資源交互。我認為抽象是：

用於表示資源的數據結構

資源響應的一組消息

資源用於調用應用程序代碼的機制

（抽象在這裡可能是一個可怕的詞。每一個三年以上的開發者對它都有自己的定義，如果我的定義與你的不一致，那請你放過，讓我們繼續下去：）

Rails框架通過ActiveRecord抽象，公開了一個你的應用程序代碼可以與之交互的資料庫資源。其中表對應於類，而行則對應於該類的對象。這是一個帶有折衷的選擇，行可以表示為Ruby的哈希對象（類似於JSON對象的基元），這可能使它們更易於移植，但同時也使得簡潔地表達資料庫操作（如save和destroy操作）變得更加困難。抽象還可以響應查找(find)、創建(create)、更新(update)和銷毀(destroy)等操作。它通過生命周期回調方法調用應用程序的代碼，比如before_validation方法。而框架的意義是通過識別這些生命周期並在它們不在底層資源中時為它們提供介面，來體現它的價值。

你已經知道這一點，但這裡值得再強調一下：抽象讓我們在更高的層次上編碼。框架抽象解決了我們對特定於資源管理的關心，讓我們專註於構建產品。框架通常設計良好，能夠實現松耦合。

沒有什麼比Unix框架引入的大量成功的文件抽象能夠更好地證明了這一點。接下來我們將詳細介紹，因為它體現了設計智慧，可以幫助我們理解什麼是一個好的框架。

文件操作的核心功能包括打開（open）,讀取(read)、寫入(write)和關閉(close)。文件被表示為連續的位元組流，這和ActiveRecord使用Ruby對象的選擇一樣。在進程中，打開的文件表示為文件描述符，通常是一個小整數。open函數接受一個文件路徑並返回一個文件描述符，read、write和close函數使用一個文件描述符作為參數來完成它們的工作。

這裡有一個神奇的訣竅：文件並不一定是指磁碟上的文件。正如Rails框架實現了MySQL和Postgres的ActiveRecord抽象一樣，操作系統（OS）實現了管道、終端和其他資源的文件抽象，這意味著你的程序可以使用與將文件寫入磁碟相同的系統調用來寫入它們。實際上，站在一個程序的立場上看，它只知道它正在寫入一個文件；它不知道文件描述符所指的「文件」實際上可能是一個管道。

作為讀者的一個練習：寫幾段話，準確地解釋選擇這種程度的松耦合設計的好外。以及這些選擇如何幫助我們評估和設計框架？

這種設計是Unix著名的簡單性的重要組成部分。這就是讓我們能夠在shell中運行下列命令的原因：

shell解釋這條命令，然後啟動ls進程。通常，當一個進程啟動時，它會創建三個文件描述符（記住，它表示打開的文件）：0表示STDIN（標準輸入），1表示STDOUT（標準輸出），2表示STDERR（標準錯誤），shell會將每個文件描述符設置為引用你的終端（終端可以是文件！吃驚嗎？！？）。當你的shell看到管道符號「|」後，就將ls進程的STDOUT設置為管道的STDIN，將管道的STDOUT設置為wc進程的STDIN。管道鏈接了進程的文件描述符，使得進程可以讀寫「文件」，而不必知道另一端實際上是什麼。不開玩笑，每次想到這一點，我的脊椎底部都會有點興奮，因為我是個書獃子。

這就是為什麼文件I/O被稱為通用I/O模型的原因。在下一節中，我將介紹更多關於這方面的內容，我在這裡分享它是想讓你知道，如果你找到正確的抽象，你的編程環境會有多麼強大。文件I/O模型在引入幾十年後仍然佔據主導地位，它使得我們的編程生活更輕鬆，甚至不必了解它的實際工作原理。

任何初學者程序員都要做的第一個經典的練習是編寫一個列印「Wassup, homies?」的程序。這個程序利用了文件模型，但是初學者甚至不需要知道這種東西的存在。這就是一個好的框架需要做的。一個設計良好的框架可以讓你輕鬆地開始構建簡單的應用程序，更不會在你學習了更多知識後，阻止你構建更複雜和有用的應用程序。

對於*nix操作系統，你可以說在C程序中的main函數是一種onStart回調（callback）。操作系統調用main，然後main告訴操作系統應該運行什麼指令。但是，執行指令的實際時間是由操作系統控制的，因為操作系統負責調度。這也是一種控制反轉，對吧？

通信

框架協調資源，協調需要通信。而通信並不是件容易的事。框架通過將資源所說的完全不同的「語言」轉換為一種或多種易於理解和高效的通用語言，同時確保可擴展性和可組合性，使通信更容易實現。框架也做了一些確保彈性的工作。這通常需要：

建立命名和定址約定

制定如何構建內容的約定

引入通信代理

處理通信故障（如資料庫關閉！該文件不存在！）

許多人熟悉的一個例子是HTTP stack，它是一種用於在瀏覽器和伺服器資源之間通信的「語言」，它包括了：

HTTP結構內容（請求頭和文本格式的請求正文）

TCP通信故障句柄

IP定址句柄

約定

文件模型是一種「通用語言」，操作系統使用設備驅動程序在文件模型和硬體設備所說的任何本地語言之間進行轉換。文件模型有命名和定址約定，允許你使用由斜杠分隔的字元串指定文件系統上的文件，斜杠轉換為內部inode（一種存儲文件和目錄詳細信息（如所有權和許可權）的數據結構）。我們已經習慣了這一點，所以很容易忘記這是一種約定；*nix系統的設計可能會使你不得不使用數字或UUID來引用文件。我在上一節中講到的文件描述符也是一種約定。

文件模型引入的另一種約定是將內容構造為位元組流，而不是位流、字元流或XML文檔。但是，位元組通常級別太低，因此操作系統包含了一套命令行工具，它通過將位元組解釋為字元（sed, awk, grep,和friends）來引入位元組構造的進一步約定。最近，人們引入了更多的工具，將文本解釋為YAML或JSON。Clojure世界有更多的工具將JSON解釋為Transit。我的YAML工具不能用jack工具鏈來處理JSON文件，但是因為這些格式都是用較低級別的格式表示的，所以較低級別的工具仍然可以使用它們。結構影響可組合性。

文件模型的簡單性使得它成為「通用I/O模型」。想像一下，如果所有的Linux進程都必須與XML而不是位元組流通信的話！哎呀，那這個世界就瘋狂了。擁有一個簡單的、通用的通信系統，使得新資源能夠非常容易地參與進來，而無需直接了解彼此。它允許我們輕鬆地編寫命令行工具。它允許一個程序讀取一個日誌的同時，另一個程序寫入該日誌。換句話說，它支持松耦合和所有附帶的好處。

通信代理

全局可定址通信代理（像文件系統、Kafka隊列或資料庫）對於可組合系統的啟用至關重要。全局（Global）意味著每個資源都可以訪問它。可定址（Addressable）意味著代理（broker）為獨立於其客戶的實體維護標識符，並且客戶可以使用這些標識符指定實體。通信代理（Communication broker）意味著系統的目的是將數據從一個資源傳輸到另一個資源，並且它具有明確的語義：隊列具有FIFO語義，文件系統具有就地更新語義等等。

如果Linux沒有文件系統，只允許進程通過管道進行通信的話，那將是一場噩夢。間接信通比直接通信更靈活。它支持基於時間的解耦，因為讀和寫不必同步進行。它還允許參與者獨立地進出通信系統。（順便說一句，我想不出這個概念的名字，也想不出更好的表達方式，希望能得到你們的反饋。）

我認為這是框架設計中最棘手的部分。在本文的開頭，我提到開發人員可能最終會繞過框架的約束，而且我認為主要的約束通常是通信代理的缺失。框架的設計者引入了新的資源和抽象，但是把它們組合到一起的唯一方法是通過直接通信，並且有時候還用「魔法般」的方法來處理直接通信。（我似乎記得Rails框架就是這樣工作的，控制器和視圖之間有緊密的耦合，並且缺少將控制器數據傳輸到系統其他部分的選擇）。如果有人想要引入新的抽象，他們必須解開所有的魔法，並深入到框架的內部，使用(應該是)私有的代碼，甚至依靠打補丁來解決問題！

我記得MongoDB發布時，我在Rails上遇到過這個問題。文檔資料庫（document database）資源與關係型資料庫（relational database）資源完全不同，MongoDB幾乎不可能參與ActiveRecord抽象，而且引入一種可以很好地與Rails生態系統的其他部分配合使用的新的數據存儲抽象也非常困難。

對於更為當前的示例，前端框架可能將表單標識為資源，並為它創建一個很好的抽象，用於處理驗證和表單提交生命周期之類的事情。如果表單抽象是在沒有通信代理（如全局狀態容器）的框架中編寫的，那麼將很難滿足「使用表單篩選表中的行」這一常見使用情況，因為渲染表數據的代碼無法訪問表單輸入的值。你可能會想出一些類似於定義導出表單狀態的處理程序的黑客方法，但是在特殊的基礎上這樣做會導致代碼混亂和脆弱。

相比之下，通信代理的存在可以使生活更輕鬆。在Clojure世界中，React框架下的re-frame和om.next包含了全局狀態atom，這是一種類似於文件系統的通信代理（atom是一種內存存儲機制）。它們都有定義良好的通信協議。我對Redux不太熟悉，但我聽說它也包含了一個集中管理的全局狀態容器。

如果使用re-frame創建一個表單抽象，就可以在全局狀態atom中跟蹤它的狀態。還可以為表單建立命名約定，這樣其他參與者就更容易查找表單的數據並對其做出反應。（劇透警告：我工作中一直使用的框架就是這樣做的！）

通信系統是基礎。沒有它們，除了最簡單的應用程序之外，你很難構建任何東西。通過提供通信系統，框架減輕了構建程序的許多認知負擔。通過建立通信標準，框架使開發人員能夠創建可組合的工具，這些工具讓使用該框架的每個人都受益。標準使基礎設施成為可能，而基礎設施使生產力得以提高。

在這一部分中，我主要關注文件模型，因為它非常成功，並且我認為我們可以從中學到很多東西。其他模型包括事件匯流排和消息隊列等等。我就不在這裡一一贅述了。

環境

構建框架是為了協調特定環境中的資源。當我們談論桌面應用程序、Web應用程序、單頁應用程序(SPA)和移動應用程序時，我們談論的是不同的環境。從開發人員的角度來看，環境是以可用的資源來區分的，而從用戶的角度來看，不同的環境意味著不同的使用模式，和對分發、可用性、許可和支付的期望。

隨著技術的進步，新的資源變得可用（互聯網！資料庫！智能手機！強大的瀏覽器！AWS！），新的環境將不斷發展以組合這些資源，並創建針對這些環境的框架。這就是為什麼現在我們談論移動框架和桌面框架之類的東西。

我不再使用Rails框架的原因之一是因為它是一個Web應用程序框架，但是我想構建的是單頁應用程序。當時（大約2012年左右？）我正在學習使用Angular，並希望使用它來部署應用程序，但是它並不是真正適合Rails框架的設計。

不過沒關係。有些人為Linux編寫程序，有些人為macOS編寫程序，出於某種原因，有些人仍然為Windows編寫程序（開玩笑！饒了我吧！）。框架是一種工具，而工具是為特定目的而構建的。如果你試圖達到一個工具所不能達到的目的，那就使用一個不同的工具。

使用框架的更多好處

到目前為止，我主要討論了框架為單個開發人員帶來的好處。在這一節中，我將解釋框架如何讓整個社區受益，框架是如何讓編程變得有趣，以及（也許最重要的）框架為何對初學者來說是一個巨大的助力。

首先，讓我們回顧一下，框架是一組開發庫的集合，它們的職責是：

管理對編寫應用程序所需資源進行協調的複雜性…

通過提供這些資源的抽象...

以及在這些資源之間進行通信的系統...

在一個環境中...

使得程序員能夠專註於編寫特定於其產品的業務邏輯。

僅此一點就減輕了開發人員的巨大負擔。如果我闡述的不夠充分，那請你記住，這些職責的實現工作是很難的，如果每次你想使用的時候都必須這樣實現一遍的話，那會讓人沮喪和筋疲力盡的。實際上，讓我換個說法：要是我必須實現框架的這些職責的話，那一定是令人沮喪和筋疲力盡的。這就是為什麼當我在2005年第一次遇到Rails框架時，感覺它是如此的神聖。

框架給社區帶來的好處

清晰的抽象和通信系統允許人們共享模塊、插件或任何你想稱之為框架擴展的東西，從而創建一個充滿活力的可重用組件生態系統。

如果你接受我關於操作系統是框架的斷言，那麼你可以將通過操作系統的通信系統（套接字、文件模型等）進行通信的任何程序視為框架的擴展。比如說，Postgres是一個關係型資料庫管理系統（RDBMS）資源的框架擴展。而StatsD是一個監控資源的擴展。

同樣地，Rails框架使開發人員能夠識別專門的資源並擴展框架以方便地支持它們。其中一個最受歡迎和最強大的是Devise，它負責協調Rails資源以引入新的用戶認證資源。正如人們傾向於使用Postgres，而不是手動操作自己的數據一樣，人們也傾向於使用Devise，而不是手動來管理自己的認證系統。

是否有可能為Clojure語言創建一個Devise呢？我不認為有這個可行性。Devise被設計成資料庫無關的，但是由於Clojure語言沒有一個真正的值得信賴的框架來指定或引入值得信賴的資料庫抽象，因此沒有人能夠以這樣一種方式編寫與Devise等效的東西，使得它可以很容易地支持任何RDBMS資料庫。沒有這樣的一個框架，就不可能有人能夠編寫一個你可以重用的功能齊全的認證解決方案；即使你編寫了一個，其他人也不太可能看到你共享它的好處。Clojure語言正在和這些生態系統的好處擦肩而過，我認為這對Clojure來說太糟糕了。

另一個框架帶來的不很明顯的好處是，它們為開發人員如何使用你的語言構建應用程序提供了一個連貫的故事，這使你的語言更具吸引力。構建應用程序意味著為目標環境（桌面、移動、SPA等）協調資源。如果你的語言沒有針對目標環境的框架，那麼學習或使用該語言的風險更大。構建產品有一個更高的障礙：開發人員不僅必須學習語言的語法和範例，他們還必須弄清楚如何使用語言的範例來執行抽象和協調資源的複雜任務。如果你的目標是創建一個大眾市場產品，那麼選擇一種沒有目標環境框架的語言是一個危險的選擇。

最後，框架成為你可以為其創建工具的基層。文件系統的引入使得人們可以編寫易於創建和操作文件的工具。Rails框架的抽象使得生成用於創建新的資料庫表，以及用於與之交互的整個堆棧（model, view, controller）的代碼變得更加輕鬆。

框架使開發變得有樂趣

如果你仍然認為框架是多餘的或者麻煩大過它們的價值的話，相信我，我理解你。當我從Rails框架切換到Clojure時，我非常喜歡它的「使用庫，不用框架」的方式。我感覺使用框架是沒有必要的，因為所有的部分都是如此簡單，以至於我把它們粘在一起時不費吹灰之力。而且，我覺得解決一個我熟悉的問題對我來說是純粹的樂趣，因為它幫助我學習了這門語言。

好吧，就當我放了一個無聊的千年臭屁吧。因為我現在不再認為這工作有趣了。我想要構建產品，而不是構建用於構建產品的基礎架構。我想要一個插件，它可以幫我處理重置密碼的過程。我想要一個管理面板，五分鐘內我就要它能夠工作。框架能夠處理那種理想情況下只需要完成一次的工作。我不想每次想做點什麼的時候都要一遍又一遍地做同樣的工作。

對我來說，編程是一項創造性的工作。我喜歡做些傻事，並且把它們擺在人們面前看看會發生什麼。Rails框架幫助我構建了像phobiatopia.com（現在已經失效）這樣的網站，在那裡用戶可以分享他們害怕的東西。這個網站會使用用戶的IP地址來得到用戶的地理坐標，並且使用谷歌地圖來顯示全球恐懼地圖。它顯示很多人害怕熊。

框架讓你專註於構建應用程序的有趣部分。框架可以讓你更快地實現一個想法，無論這個想法有多麼愚蠢。

框架幫助初學者

框架可以幫助初學者構建真實的，並且能真正運行的應用程序，他們可以自豪地向朋友們展示這些應用程序，甚至可以用它們來賺錢，而不必完全理解，甚至不需要知道他們使用的所有技術。能夠變魔術般地召喚出一個完整的創造物，不管它有多小或者多麼粗糙，it is the very breath of wonder and delight。（我不知道這句英文什麼意思，但我喜歡它的發音！）

有一種看法認為：框架是不好的，因為它們允許初學者構建東西，而不必知道它們是如何工作的。ActiveRecord正在腐蝕年輕人，因為它允許他們構建應用程序，甚至在他們不知道如何正確發音SQL的情況下。

也有另一種看法認為：讓初學者更容易構建出東西是不對的。人們必須為了學習而努力或經受磨難，否則就不合乎道德。

忘掉上面這些愚蠢的，無聊的廢話。我認為快樂勝過每一次的痛苦。讓你的學習更加快樂，讓更多的人從你創造的任何工具或產品中獲益。

我是個攝影師。我有一台專業相機，我知道怎麼用。我的一些照片需要大量的技術知識和專業設備（如下圖）：

上面這張照片不是你能用手機創造出來的東西，不知道為什麼，我能享受我自己的技術和藝術創作，但是我也不討厭「傻瓜」相機的存在，我也不抱怨人們喜歡它們。

新手從專家指導中受益匪淺。我不認為你能用手機拍照而成為一名大師級的攝影師，但是有了手機的「指引」，你可以拍一些非常好的照片並為它們感到驕傲。而如果你真想成為一名攝影大師，這種積極的反饋和成就感會激勵你堅持下去，學習一些困難的東西，而獲得更多的進步。

框架通過在「流沙」和「陷阱」周圍創建一條安全的路徑來提供這一「指引」，來幫助你在創建應用程序時規避這些陷阱。框架幫助初學者，這是它的一個好處，而不是一個bug。

我的Clojure框架

框架用來管理協調資源的複雜性。看到了嗎？「Managing Complexity」（管理複雜性）是Clojure英文全稱Clojure Managing Complexity McCarthy-Lisp的中間部分。就我個人而言，我想要一個單頁應用程序（SPA）框架，Clojure語言的設計和理念有很多方面，讓我認為創建一個真正了不起的框架是非常可能的。下面我只舉幾個例子。

首先，考慮一下像sed和awk這樣的Linux工具如何實現文本導向的。開發人員可以通過將文本格式化為JSON或YAML向文本添加附加結構，而這些文本處理工具仍然可以處理結構化的文本。

同樣，Clojure語言強調簡單數據結構，這意味著我們可以創建專門的結構來表示表單和Ajax請求，以及處理這些結構的工具。但是，如果我們用地圖和向量來定義這些結構，我們仍然可以使用一個龐大的功能生態系統來處理那些簡單的結構。換句話說，創建專門的結構並不妨礙我們使用為更簡單的結構而構建的工具，對於許多其他語言來說，情況並非如此。

第二，Clojure語言基於協議（protocol）和多方法（multimethod）的抽象機制非常靈活，這讓我們在新資源可用時能夠方便地實現它們的抽象。

第三，你可以在前端和後端使用相同的語言！！！！不僅如此，Transit還允許兩者輕鬆地通信。這就消除了其他語言框架必須解決的一整類的協調問題。

在我看來，Clojure粉絲們認為框架的麻煩超過它的價值的立場完全是一種倒退：Clojure語言給我們打好了創建一個真正了不起的框架的基礎！它就是那麼簡單易行。這不是做夢，這是事實！

我的目標是建立一個SPA框架，幫助目前和未來的Clojure開發人員，使我們的想法能夠快速地投入生產。我希望我們能夠花更多的時間在困難的事情上和有趣的事情上。我希望我們在發布新產品時能夠更加輕鬆和自信。

我正在構建的框架是建立在一些真正令人驚嘆的庫之上的，這些庫主要包括Integrant, re-frame,和Liberator。Integrant引入組件抽象，並負責處理應用程序的啟動/停止生命周期。re-frame為前端提供了一個文件系統和通信代理。Liberator引入了一個處理HTTP請求的標準模型。

如果我的框架最終有用的話，那是因為這些工具的創建者已經完成了所有繁重的工作。我的框架引入了更多特定於創建單頁應用程序的資源和抽象。例如，它創建了一個用於包裝Ajax請求的抽象，以便在請求處於活動狀態時輕鬆地顯示活動指示器。它也創建了一個表單抽象，用於處理輸入更改和表單提交發送，以及整個表單生命周期（包括fresh,dirty,submitted,invalid,succeeded等等）的所有管道。它同時為組織數據制定了一些約定。

正如我所提到的，這個框架還沒有完全準備好供公眾使用，因為在實現我的想法的時候，我仍然對有些地方舉棋不定，而且現在基本上沒有任何文檔。但是希望在不久的將來我能夠將它發布出來。

但是，如果你現在就想看到一個使用這個框架的生產應用程序的話，我邀請你去看看Grateful Place（感恩之地）這個網站。這是一個社區網站，為那些希望通過實踐同情心、感恩、慷慨和其他積極價值觀來支持彼此的人提供恢復力、平靜和快樂。通過加入這個社區，你不僅僅是幫助自己，你還通過讓別人知道你支持他們並分享他們的價值觀來幫助他們。

你可以到處點擊看看那些漂亮時髦的動畫載入。如果你被它感動了，請一定加入！我喜歡在相互支持共同價值觀的背景下與人互動。除了Clojure，我唯一關心的事情就是幫助人們開發工具來引導他們在這個瘋癲的世界裡航行。

同時，我將繼續努力使這個框架為公眾使用做好準備。期待另一篇博客文章分享Grateful Place（感恩之地）網站如何實現的一些細節。最後，期待框架本身的發布聲明：）

如果你不耐煩等我的新框架，那就看看已經存在的一些神奇的Clojure工具（如下）：

Luminus：http://www.luminusweb.net/

Fulcro它可以做我希望我的框架能做的一切，只是更好：http://book.fulcrologic.com/

re-frame仍然是我最喜歡的前端框架：https://github.com/Day8/re-frame/

duct很不錯，但它的文檔還不太好：https://github.com/duct-framework/duct

Coast on Clojure，一個全棧Web框架：https://github.com/coast-framework/coast

原文: http://flyingmachinestudios.com/programming/why-programmers-need-frameworks/

本文為CSDN翻譯，轉載請註明來源出處。

【END】

熱 文推 薦

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！