那是過去的事情了。今天，涉及語法和結構的戰爭基本結束了，因為世界已經彙總了一些簡單標準。在 C、Java 和 JavaScript 裡，分號、花括號等之間的差異不大。關於型別和閉包的有趣爭論仍然存在，但是大部分是毫無意義的，因為自動化在縮小差距。如果你不想定義資料型別，那麼有一種可能，計算機將能準確推斷出你的意思。如果你的老闆想用 JavaScript、而你喜歡 Java，那麼交叉編譯器【注1】將把所有靜態型別的 Java 程式碼轉化成可以在瀏覽器執行的最小化的 JavaScript。當技術做後盾時，為什麼還有戰爭呢？
今天，有趣的戰鬥發生在框架上。當我在約翰·霍普金斯大學和其他院系成員規劃一門新課程時，框架成了討論的重點。Angular 優於 Ember？Node.js 就是一切嗎？
我們設計了一份調查課程，將探索最重要的軟體包的架構，這是網際網路的基礎。這是行動的中心，這份調查課程的價值在於探索圍繞著當今網際網路的、最重要的軟體包的架構。
從這個意義上說，框架就是新的程式語言。它們就是當代程式碼被建立起來的最新思想、哲學和實用性。有些曇花一現，不過大部分成為了程式設計的、新的基本構成要素。下面是助長這種框架趨勢的七個方面，使得框架成為滋生乏味戰爭的新的最愛。
大部分程式碼正和 API 串在了一起
過去編寫軟體，意味著呼叫你對程式語言的所有技能，以最大化壓榨程式碼。掌握指標、函式和作用域是講得通的——程式碼質量取決於做正確的事情。如今自動化處理了這方面的大多數事情。如果你在程式碼裡遺留了無用的語句，不要擔心，編譯器會去掉無用程式碼。如果你讓指標吊著，垃圾回收器可能會找到它。
還有，如今編碼實踐也不同了。大部分程式碼現在都是一長串 API 呼叫。偶爾有一些 API 呼叫之間的資料重組，但是，甚至這些工作通常也有其它 API 來完成。幸運的一些人在為我們機器的核心編寫更聰明的、位拆裂【注2】、指標雜耍之類的程式碼，但是我們大部分人工作於更高的層次。我們在 API 之間簡單地執行管道。
鑑於此，理解 API 的表現以及能做什麼，就顯得更加重要。它接受哪種資料結構？當資料集增長較大時，演算法表現如何？類似這樣的問題，與關於語法或語言的問題比起來，更加集中在今天的程式設計裡。的確，有大量工具簡化了某種語言從另一種語言呼叫一個程式。比如，把 C 資源庫連結到 Java 程式碼，變得相應簡單了。理解 API 才是重要的。
站在巨人的肩膀上，是值得的
假設你已經成為了 Erlang 或另一種新語言的信徒。你認為，它為編寫文件、沒有 bug 的應用提供了最好的平臺。這是優秀的觀點，但是你要花費數年才能把可獲得的 Java 或 PHP 重寫為你最新選擇的語言。你的程式碼最終可以顯著變得更好，但是值得花這些額外的時間嗎？
框架讓我們對來到我們面前的那些艱難工作做出了改變。我們或許不喜歡他們選擇的架構，我們或許爭論於實現細節，但是停止抱怨、找到和差異共存的方式才是更有效的。繼承框架程式碼庫裡的所有精華和糟粕，是如此地容易。用你喜歡的新語言、自己編寫所有東西，而不採用某種更受歡迎的框架，這種強悍的方式和簡單地遵循框架作者及其 API 比起來，不會讓你快速享受到新選擇的樂趣。
理解架構是做什麼的，而非語法
由於大部分編碼都是串起 API 呼叫，因此沒有太多優勢去學習語言的特質了。當然，你可以成為關於 Java 是如何初始化物件內的靜態欄位的專家，但是如果能夠搞清楚如何發揮 Lucence、JavaDB 或其它一堆程式碼的威力，那才是更好的。為了深入理解 Objective-C 編譯器的優化程式，你要花費數月，但是學習最新的 Apple 核心資源庫的來龍去脈，你將真正讓程式碼優秀。你將更深入地學習框架吹毛求疵的細節，而不是框架所依託的語言的語法。
我們的大部分程式碼在資源庫的內部迴圈中花費了大量時間。搞清楚語言細節的正確性可以起到幫助，但是瞭解資源庫內部發生了什麼可以獲得顯著的回報。
演算法主導
學習一門語言有助於你應付隱藏在變數裡的資料，不過只是把你帶到了更遠的地方。真正要克服的是，確保演算法正確，它們通常被框架定義和實現了。
很多程式設計師明白，重新實現標準演算法和資料結構是危險的，也是浪費時間的。你可能讓它更符合需求，但是你要冒著犯微妙錯誤的風險。框架已經廣泛測試過多年了。它們代表了軟體基礎設施的集體投資。當弄明白“go off the grid”【注3】是什麼意思時，將其他人的辛苦勞動扔在一邊，用你自己的雙手搭建一個演算法小屋——其實，沒有太多這種例子。
正確的做法是學習框架，學習如何使用它們來發揮你的最大優勢。如果你選擇了錯誤的資料結構，那麼你就把一個線性工作變成了耗時的、輸入大小的二次函式。一旦你這樣做了，將是一個大麻煩。
糾正語法的編譯器和聰明的 IDE
我應該在程式碼塊的最後一個語句後面加上分號嗎？分號是“分隔符”，還是“終止符”？語言設計者們花了大量時間來製作實施這些規則的分析器——猜猜怎樣——我不關心。我關心的時候大概是在 10 年前，但是現在的 IDE 為我做了這部分工作。它們一直在身後看著我，當我搞砸的時候就告訴我。我讓它們替我去考慮，把時間花在考慮關於程式碼方面的大問題。IDE 是苦力、是處理這些瑣碎細節的程式設計助理。
自動化已經把我們從程式設計語法的單調乏味中拯救了。當然，它們不能為我們做所有工作。我們仍然需要具備部署那種標點符號的模糊思維。但是大部分時候，語言的這種細節已經不重要了。
IDE 不僅對框架有幫助，還有一些小細節。它們提醒我們函式呼叫的引數，它們甚至檢查資料是否為正確的型別。然後，我們應該知道使用哪種函式、如何將它們組合在一起。當語法不是太緊要時，這就是我們精力需要集中的地方——更高階的方法和函式，將有助於更方便地找到解決方案。
語法和視覺化語言一起消失
雖然已經預言很多年了，但是它在某些程式碼——儘管不是全部——仍在緩慢地發生著。某些程式設計繼續著非常文字式，但是有些正變得更加視覺化【注4】，這意味著潛在的計算機語言不是太重要。
GUI 構建器是最容易看到這個現象的地方。你可以整日整夜地拖拉使用者介面部件，而不用擔心它是 C、Java 或其它語言。細節在視覺化盒子裡被編碼。
AndroidBuilder 使得拖拉更多的佈局成為可能，它將忠實地編寫 XML 以及需要讓程式碼執行的 Java 小程式碼。很難討論視覺化語言未來會成為什麼樣子，尤其是在它們多次未能意識到該預言之後，但是當它們成長時，工具將增加更多視覺化。這意味著語言沒那麼強大或重要了。
程式碼即法律（code is law）
計算機語言有著極大的不可知論者。它們被設計為開放、接受和幾乎無限延展的。它們意欲做你想要的任何事情。當然，有時候由於語法，你需要使用一些額外的字元，但是這些是很少的擊鍵。之後，它主要是 if-then-else，再加上偶爾的聰明約束。所有這些語言將幫助你用想得到它們的方式、得到你想要的結果。如果有一些苛責的話，那麼它們應該被設計為儘可能保持你的程式碼沒有 bug，不要限制你能做的事情。
框架的威力就在這裡，這就是設計師可以決定什麼被允許、什麼本質上要禁止。如果設計師不想讓某些東西發生，那麼神奇的函式呼叫將從 API 中消失。如果設計師喜歡這種想法，那麼通常會有多個函式呼叫以及許多支援工具。這就是哈弗法學院教授 Larry Lessig 【注5】為什麼喜歡說“程式碼即法律”的原因。
框架為它們所處的網際網路角落建立規則，一旦你選擇它們，就必須生活在規則之下。一些部落格平臺鼓勵通過 Ajax 呼叫與其它部落格連結。這就是你必須謹慎調查、聰明選擇的原因。這就是框架最終主導我們生活方方面面的原因，甚至包括我們不在程式設計的那些短暫時光。
- 注1：交叉編譯器（英語：Cross compiler）是指一個在某個系統平臺下可以產生另一個系統平臺的可執行檔案的編譯器。交叉編譯器在目標系統平臺（開發出來的應用程式序所執行的平臺）難以或不容易編譯時非常有用。http://zh.wikipedia.org/wiki/%E4%BA%A4%E5%8F%89%E7%B7%A8%E8%AD%AF%E5%99%A8
- 注2：位拆裂 (Bit Banging)：一種利用微控制器的通用埠模擬序列介面標準(I²C、SPI 等)的技術。http://en.wikipedia.org/wiki/Bit_banging
- 注3：off the grid：不使用水、電、信用卡，不上社交網路，以避免留下記錄；願意用自己做的東西而願使用現成的。http://www.urbandictionary.com/define.php?term=off+the+grid
- 注4：視覺化程式設計語言（Visual programming language，以下簡稱 VPL），又稱‘圖形化程式語言’、‘視覺化程式編成語言’。系使用者利用圖形化元素進行程式設計；相異於文字式程式設計。VPL 以視覺表達為基礎，利用‘文法’或是某種‘輔助標記’進行圖形與文字的排列。許多 VPL 建基於‘方塊與箭頭’的概念之上，以方塊或螢幕上的物件為本體，以箭頭相連線，以直線段與弧線段代表相互之間的關係。http://zh.wikipedia.org/wiki/%E8%A6%96%E8%A6%BA%E5%8C%96%E7%A8%8B%E5%BC%8F%E8%A8%AD%E8%A8%88%E8%AA%9E%E8%A8%80
- 注5：http://en.wikipedia.org/wiki/Lawrence_Lessig#.22Code_is_law.22
相關閱讀
評論(1)