摘要：因為路由層面受業(yè)務影響很大，經(jīng)常修改一些功能的行為，所以后來大部分測試都是針對層面的單元測試。在我了解的過程中，我發(fā)現(xiàn)中文網(wǎng)絡上對的討論非常分散，于是我創(chuàng)建了中文社區(qū)，到年末已經(jīng)有個注冊用戶和個帖子了。

https://jysperm.me/2016/02/programming-of-2015/

從 2014 年末開始開發(fā)的一個互聯(lián)網(wǎng)金融項目終于在今年三月份上線了，這是一個 Node.js 編寫的 Web 服務，但上線僅僅是個開始，之后的半年時間我們?nèi)栽谶@個項目上進行著密集地開發(fā)。

就像 2014 年度的技術(shù)小結(jié) 中提到的，2014 一整年我都在進行有關(guān)自動測試的實踐，經(jīng)過幾個項目的積累，這個項目從頭至尾都有著覆蓋完整的自動測試，我所有的調(diào)試工作也都是借助自動測試完成的，我甚至沒有在自己的電腦上運行過這個項目的前端頁面。因為路由層面受業(yè)務影響很大，經(jīng)常修改一些功能的行為，所以后來大部分測試都是針對 Model 層面的單元測試。

這個項目使用了一種「以數(shù)據(jù)結(jié)構(gòu)為核心」的設計，所謂數(shù)據(jù)結(jié)構(gòu)就是一個 JavaScript 的 Object, 對應著數(shù)據(jù)庫中數(shù)據(jù)表的各個字段，這些代表著業(yè)務實體的 Object 在項目中的各個函數(shù)之間傳遞。絕大部分函數(shù)的參數(shù)和返回值都是這種 Object, 它們在這些 Object 上獲得或修改數(shù)據(jù)，并將這些 Object 與數(shù)據(jù)庫同步，即使需要傳遞額外的數(shù)據(jù)，也是將數(shù)據(jù)作為屬性附加到相關(guān)的 Object 上。可以說這是一種非常 JavaScript 的風格，因為這些 Object 非常近似于數(shù)據(jù)庫中的一行記錄，所以在單元測試中很容易構(gòu)造，非常大地簡化了單元測試中「構(gòu)造特定環(huán)境」的這個步驟 —— 函數(shù)的輸入和輸出都是特定結(jié)構(gòu)的 Object, 這對于 JavaScript 來講太簡單了。

隨著功能的添加，業(yè)務邏輯變得越來越復雜，因為 Node.js 強制 IO 操作異步的這個特征，異步流程控制變成了一個令人頭痛的問題 —— 直到我發(fā)現(xiàn)了 Promise。Promise 是 對異步任務的一種抽象，當我深入地理解了它的工作原理后，才認識到我在學習 Node.js 上走的最大的彎路就是很晚才開始了解和使用 Promise.

相比于編寫 Callback 風格的異步代碼，使用 Promise 意味著一種思路上的轉(zhuǎn)變，雖然 Promise 的原理簡單，但在具體的使用場景上還是需要自己做很多嘗試的，例如具有分支的異步邏輯、循環(huán)地處理數(shù)據(jù)、逐級傳遞異常等。

在這個實踐的過程中，我逐步地將自己的項目中的異步代碼改成基于 Promise. 在和 Express 的配合中，我發(fā)現(xiàn)因為 Express 沒有對 Promise 的支持，所以 Express 的路由定義實際上變成了 Promise 的「邊界」，所有的 Promise 都要在這里進行一次轉(zhuǎn)換，改成 Express 的錯誤處理機制。于是我想如果有一個支持 Promise 的路由框架將會是一件很有趣的事情，于是我花了幾天的時間設計并實現(xiàn)了 Cichorium, 這是一個代碼只有一百來行，基于 Promise 來提供異步中間件和錯誤處理的路由框架。

在使用 Promise 的過程中，也讓我對「異常」有了更加深入的認識，異常是現(xiàn)代語言所提供的非常強大的流程控制機制，讓本來唯一一條通常的、正確的執(zhí)行路徑變得可以從任何一處中斷，并進入一個所謂的異常處理流程。異常可能包括「預期到的情況」和「非預期的情況」，如果在自己的代碼中拋出了異常，那么通常是屬于可以預期到的情況，例如參數(shù)錯誤、前提條件不滿足等，拋出異常的目的是為了中斷正常流程，并通知調(diào)用者；而非預期的情況則可能是所依賴的庫拋出的異常，或因運行時錯誤 JavaScript 引擎拋出的異常。

異常會被調(diào)用棧上離異常被拋出處最近的處理程序捕捉到，一旦異常處理程序「解決」了這個異常，其他的異常處理程序就不會再得到通知。所以處理程序應當只去處理已知的、必須在此處理的異常，然后將其他的異常繼續(xù)向其他處理程序拋出，最后到達一個「邊界」，例如作為 HTTP 相應發(fā)給客戶端，或打印一條日志。

這個項目在上線初期時間趕得比較緊，加上經(jīng)驗不足，在上線后的前幾個月時間一直都在遭遇性能問題。中間出現(xiàn)過幾次因為并發(fā)請求過多，多個請求修改同一條數(shù)據(jù)進而出現(xiàn)的數(shù)據(jù)不一致的情況。本來是有一個通過簡單的 Redis 鎖限制一個用戶同時只能有一個寫入數(shù)據(jù)的請求的機制的，但畢竟不是根本的解決方案。于是我開始嘗試使用 MySQL 的事務，將一組相關(guān)的 SQL 查詢放入一個事務中執(zhí)行，對于有前提條件的更新操作（例如扣余額后余額不能為負數(shù)），將前提條件作為一個更新條件，如果執(zhí)行后發(fā)現(xiàn)并沒有行被更新，就說明前提條件不滿足，然后回滾這個事務，向客戶端報告失敗。借助于數(shù)據(jù)庫提供的原子性和一致性，即使并發(fā)很高，或者程序崩潰，都不會出現(xiàn)數(shù)據(jù)不一致。

使用事務只是解決了在高并發(fā)情況下的數(shù)據(jù)一致性的問題，但并沒有解決性能問題。這個項目中的數(shù)據(jù)主要是財務記錄，用戶的每一次操作都會生成財務記錄，這些數(shù)據(jù)被用來追蹤每一筆資金的流向，會被聚合起來用于給用戶展示統(tǒng)計信息，這個過程需要對數(shù)據(jù)進行篩選、分組、排序等復雜的計算。

顯然這些計算如果在數(shù)據(jù)庫中計算會有更好的性能，因為不需要在程序和數(shù)據(jù)庫之間傳輸大量的數(shù)據(jù)，而且 MySQL 應該會對這類計算有更好的優(yōu)化。于是我開始補習 SQL, 將幾乎全部的篩選、分組、排序邏輯都在 MySQL 中完成。同時我開始學習如何分析 MySQL 的性能瓶頸，最簡單的就是慢查詢?nèi)罩荆?jīng)一度有一些查詢需要 300 秒的執(zhí)行時間。至于解決方案，除了優(yōu)化查詢條件之外最主要的就是加索引了，我也花了一些時間來了解索引背后的原理和最佳實踐。

這些統(tǒng)計數(shù)據(jù)和時間是強相關(guān)的，過去的數(shù)據(jù)通常來講就不會再修改了，所以如果能夠?qū)⑦@些數(shù)據(jù)的統(tǒng)計結(jié)果緩存起來，將會顯著地提高性能。其實本來也有一個簡單的緩存機制，用戶訪問統(tǒng)計信息后會被緩存，但一旦用戶執(zhí)行任何財務操作都會使整個緩存刷新。所以很容易想到的是進行更細粒度的緩存，即在時間的維度上應用所謂的「套娃娃緩存」，在 Redis 中以天為單位緩存發(fā)生的財務變動、當日結(jié)束時各項統(tǒng)計指標的值。如果某一天的財務數(shù)據(jù)發(fā)生變動，只需以前一天的數(shù)據(jù)為基礎去計算之后的數(shù)據(jù)，大多數(shù)情況下歷史數(shù)據(jù)是不會改變的，只會刷新當天的緩存。

這項修改花費了不少時間，因為需要重寫所有生成統(tǒng)計數(shù)據(jù)的代碼，在前一天的計算結(jié)果的基礎上計算出當天的統(tǒng)計數(shù)據(jù)，并連同一些中間結(jié)果一起緩存起來，供下一天的計算使用。相當于將原來一個簡單明了的計算過程被拆分成了若干個小步驟，步驟之間還需要通過 Redis 來交換數(shù)據(jù)，看似復雜，但減少了很多不必要的重復計算，上線之后將性能提高了差不多一個數(shù)量級。

這個項目大概是我這一年完成的最滿意的項目了，我參與到了絕大部分的設計工作中，也完成了差不多一半的編程工作，從頭至尾都有著完整的自動測試覆蓋，借助 Promise 實現(xiàn)健壯的異步流程控制和異常處理，在高并發(fā)的情況下實踐了事務、緩存、索引相關(guān)的知識。

-

我從年初 開始使用 Atom 完成我的全部工作，選擇 Atom 并不是因為它已經(jīng)有多么好用了，而是因為 Atom 有著優(yōu)良的設計和活躍的社區(qū)。最近兩年我工作都是使用 Node.js 來完成的，而 Atom 也基于 Node.js 和 Web 技術(shù)構(gòu)建起來的，甚至 Atom 也是用 CoffeeScript 實現(xiàn)的，這種相同的技術(shù)棧，令我非常有「安全感」。我也在了解和學習 Atom 的實現(xiàn)，它有著完全插件化的架構(gòu)和設計良好的 API, 對我后來重構(gòu) RootPanel 都非常有幫助。

在我了解 Atom 的過程中，我發(fā)現(xiàn)中文網(wǎng)絡上對 Atom 的討論非常分散，于是我創(chuàng)建了 Atom 中文社區(qū)，到年末已經(jīng)有 800個注冊用戶和 1000 個帖子了。說實話，中文技術(shù)社區(qū)的氛圍并不好，因為可能技術(shù)能力較強或英語水平較高的人會直接選擇去參與官方的社區(qū)，目前也基本上是我一個人在回答問題、翻譯官方博客和文檔、匯總一些資料，不過既然我還在用 Atom, 就會一直將這個社區(qū)維護下去。

-

RootPanel 在 2015 年上半年依然在緩慢地進行著，因為通過閱讀 Atom 的代碼學習到了大量有關(guān)插件化設計的方法，所以我這半年并沒有向 RootPanel 中添加新功能，而是一直在反復地重構(gòu) RootPanel 的架構(gòu)。

首先是為其中的重要概念建立抽象，例如服務組件（MySQL 數(shù)據(jù)庫、Nginx 站點之類）、計費方案（計費周期、價格、限制）、支付渠道、控制臺上的控件等。之前雖然也有針對這些概念進行抽象，但基本上是寫到哪里、需要什么接口，就添加一個相應的接口，缺乏一個全局性的規(guī)劃。進而導致抽象出的概念不夠簡潔、不夠徹底（有一些插件的邏輯仍散落在核心代碼中）。

JavaScript 本身是一個很靈活的語言，對象本身是「無模式」的，屬性和方法都可以隨意地修改，也提供了「原型鏈」來支持對象之間的繼承關(guān)系。為概念建立抽象的一種有效途徑就是「面向?qū)ο蟆癸L格的設計，Atom 就采用了這樣的設計，我覺得面向?qū)ο髮τ?RootPanel 可能同樣很合適。

面向?qū)ο笫紫冉y(tǒng)一了「數(shù)據(jù)」和「行為」，讓數(shù)據(jù)可以帶有行為，而在執(zhí)行這些行為的時候又不必顯式地傳遞數(shù)據(jù)；對象本身也是一個抽象層級，只要兩個對象有相同的屬性和方法（而不論背后的行為），就可以被當作同一種對象操作，即所謂的「鴨子類型」，這對于插件化的系統(tǒng)而言十分便利。

于是我用了一部分面向?qū)ο蟮娘L格來重構(gòu) RootPanel, 將其中很多概念抽象為了類，為每個模塊起一個恰當?shù)拿郑瑴p少不同模塊之間的依賴；為模塊劃分「級別」，建立層級一致的抽象 —— 即在任何一個層級來看，抽象都是完整的，讓同層級的類來打交道，而不是將層次不一的類混在一起。

-

在 2014 年我就一直對 Mongoose 有很多不滿，一直想自己造一個輪子，在 RootPanel 的開發(fā)過程中也遇到了 Mongoose 的一些坑和一些難以實現(xiàn)的需求，于是今年終于行動起來了，然后就有了 Mabolo —— 一個輕量級的 MongoDB ORM。

我對 Mabolo 的定位是一個簡單的、「沒有魔法」的 ORM, 每個 Model 都是一個普通的 JavaScript 構(gòu)造函數(shù)，而每個文檔則都是由這個構(gòu)造函數(shù)生成的實例 —— 除了幾個用來保存內(nèi)部狀態(tài)的不可枚舉屬性之外和普通的對象沒有任何區(qū)別。Mabolo 不去追蹤數(shù)據(jù)被改變的情況，而是鼓勵使用 MongoDB 的原子操作符進行數(shù)據(jù)更新，Mabolo 僅在更新后幫你將最新的數(shù)據(jù)同步到這個對象上。

嵌套對象是 MongoDB 的特色之一，在實際項目中也經(jīng)常會用到這樣的設計，于是我也為 Mabolo 添加了嵌入式對象的支持，允許將 Model 中某個字段的類型設置為另一個 Model. 在儲存到數(shù)據(jù)庫前會運行所有子 Model 的驗證方法，在從數(shù)據(jù)庫取出結(jié)果后會為每個子 Model 字段構(gòu)造相應的對象，以便在這些子 Model 上運行更新和刪除等方法。

-

五月初的時候和 Yeechan 等人參加了 SegmentFault D-Day 上海站 的活動，主要聽了有關(guān) Docker 和 React 的主題分享。

因為我開發(fā) RootPanel 的經(jīng)驗，對 Docker 這種性能損耗極低的虛擬化技術(shù)自然十分感興趣，在參加這次活動之前就去簡單地了解過 Docker, 當時我對 Docker 的不解主要在于 Image 只能單繼承，這樣就不太容易像「搭積木」一樣去組合自己想要的環(huán)境，這可能是因為文檔上面那個搭積木的示意圖對我的誤導比較大。

經(jīng)過這次的主題分享，我才比較全面地了解到基于 Docker 去部署應用的思路，即既然創(chuàng)建容器的成本是極低的，那么可以為系統(tǒng)中的每個部分去創(chuàng)建多帶帶的 Image, 運行多帶帶的容器，然后通過 Docker Compose 這類工具去組合容器。Dockerfile 描述了應用的運行環(huán)境和依賴項，而 docker-compose.yml 描述了如何將一個系統(tǒng)中所需要的各個部分組合起來，完成了關(guān)于一個系統(tǒng)的完整描述。在實際運行時，因為容器之間的聯(lián)系非常少，通常只暴露幾個網(wǎng)絡端口，所以給整個系統(tǒng)帶來了非常好的橫向拓展的能力，系統(tǒng)的每個部分都可能會運行多個容器，甚至這些容器可能會分布在不同的物理服務器上，同時提供一致的服務。

因為 Docker 是內(nèi)核級別的虛擬化，對系統(tǒng)調(diào)用的抽象代價很低，而因為使用了 AUFS 對文件系統(tǒng)進行抽象、需要建立虛擬網(wǎng)卡進行端口轉(zhuǎn)發(fā)，所以磁盤和網(wǎng)絡 IO 的抽象開銷相對較大。所以 Docker 更適合計算密集型、依賴復雜（這樣才能發(fā)揮 Docker Image 的優(yōu)勢）的程序，就是通常 Web 項目中負責處理請求的「應用」這部分，而將數(shù)據(jù)庫等 IO 密集、部署簡單、不頻繁升級的程序直接部署在物理機上。

現(xiàn)在 Web 后端程序面臨的主要挑戰(zhàn)就是高并發(fā)，保證單個程序的穩(wěn)定性，倒不如采用分布式的架構(gòu)，將一個處理能力強的實例拆分為若干個處理能力較弱的實例，轉(zhuǎn)而保證一旦有實例失效，可以立刻重新創(chuàng)建一個實例接替它繼續(xù)工作。但如果在實例中儲存了一些全局的狀態(tài)（例如鎖）就無法通過啟動多個實例的方式來橫向拓展。所以比較理想的實踐就是將應用實現(xiàn)為「無狀態(tài)」的，即容器中的應用只根據(jù)來自網(wǎng)絡的請求進行計算，對數(shù)據(jù)庫、緩存和文件系統(tǒng)的調(diào)用同樣通過網(wǎng)絡去請求容器外部的服務。這樣才可以進一步利用 Docker 的優(yōu)勢 —— 容器可以根據(jù)規(guī)模需要隨時去在不同的物理機上創(chuàng)建和銷毀而不需要同步數(shù)據(jù)。

隨著對 Docker 了解的深入，我開始意識到 Docker 對 RootPanel 這類 PaaS 平臺是一個「殺手級」的應用，像 RootPanel 那樣笨拙地使用一系列 Linux 的機制和工具去隔離用戶和直接使用 Docker 相比毫無優(yōu)勢，讓我很有將 RootPanel 改為基于 Docker 的架構(gòu)的沖動。但想來想去還是放棄了這個想法，因為一方面這個改動可能會非常大，另一方面其實已經(jīng)有了很多非常優(yōu)秀的基于 Docker 的開源 PaaS 程序了。

后來我加入 LeanCloud 負責云引擎的開發(fā)工作，云引擎實際上就是一個基于 Docker 的 PaaS 平臺，各方面都和 RootPanel 非常相似。既然日常的工作已經(jīng)是這樣一個項目了，所以進一步促使我中止了 RootPanel 的開發(fā)。但說實話我對 PaaS 還依然有興趣，也許有一天我會根據(jù)我在 RootPanel 和 LeanCloud 的經(jīng)驗，重新設計一個最簡架構(gòu)的 PaaS 來紀念 RootPanel.

隨著在工作中深入地了解 Docker, 在年末的時候我將我的服務器上應用全部換成了基于 Docker 來運行，這樣的好處就是每個應用都可以有自己的環(huán)境，而且每個服務的環(huán)境和服務之間的依賴關(guān)系都被描述在了 Dockerfile 和 compose.yml 中，徹底解決了以前服務器上各種應用「亂七八糟」的現(xiàn)象，以后若要遷移服務器或重新部署將會變得非常容易。

-

過去一年我花了不少時間斷斷續(xù)續(xù)地將「JavaScript 權(quán)威指南」和「計算機程序的構(gòu)造和解釋」看完了，對 JavaScript 的了解也進了一步，其實 JavaScript 對函數(shù)式風格的代碼還是有很不錯的支持的。按我在 JavaScript 中對函數(shù)式編程的實踐，最有價值的的兩點就是「無狀態(tài)」和「無副作用」。

隨著前端應用越來越復雜，所展現(xiàn)的數(shù)據(jù)之間的邏輯關(guān)系也越來越復雜，也出現(xiàn)了很多框架來解決前端 UI 和數(shù)據(jù)（即狀態(tài)）之間的同步問題，其中之一的 React 從一個非常有趣的角度來入手 —— UI 可以是應用狀態(tài)的一個函數(shù)，給定一組狀態(tài)就有一個確定的 UI. 如果每次狀態(tài)發(fā)生變化都重新渲染整個 UI, 便可以極大地降低管理 UI 和 狀態(tài)的復雜度。

React 還在瀏覽器提供的 DOM 上建立了一層抽象，在每次重新渲染 UI 時，React 操作的都是 Virtual DOM, 而后再去與真正的 DOM 進行對比，更新必要的部分。我覺得這種抽象還是非常有價值的，Virtual DOM 限制了很多操作，但它提供了優(yōu)化性能的空間，也為將 React 程序遷移到非 Web 平臺提供了可能性，例如后來我就嘗試過在服務器端使用 React 來渲染 HTML.

后來我在 RootPanel 和其他一些項目上實驗性地使用了 React, 我也使用了官方推薦的 JSX 來編寫代碼，React 這種將 JavaScript 作為應用主體的做法很不同于一些將 HTML 作為應用主體的框架。有一些人批評 JSX 將這些年好不容易才分開的 HTML 和業(yè)務邏輯（JavaScript 代碼）又重新混在了一起。而我則認為「模板語言」的出現(xiàn)一方面是因為部分語言表現(xiàn)能力較弱，需要模板語言將 HTML 和瑣碎的語法細節(jié)分離；另一方面則是試圖在數(shù)據(jù)和冗長的 HTML 表現(xiàn)之間建立一層抽象。JavaScript 本來已有很不錯的表現(xiàn)能力，JSX 又添加了一些與 HTML 相融合的語法；React 通過引入「組件」的概念來拓展 HTML 的標簽，讓用戶可以自己創(chuàng)建包含內(nèi)部邏輯和狀態(tài)的標簽，進而讓 HTML 表現(xiàn)不再冗長，所以分離就變得不必要了。

總體上來講我對 React 很有好感，因為我覺得 React 很好地實現(xiàn)了一些函數(shù)式編程的風格，來簡化 UI 編程中對狀態(tài)的管理，React 鼓勵將組件設計為無狀態(tài)的，同時將渲染過程設計為無副作用的，這樣無論何時，只要狀態(tài)發(fā)生改變就重新渲染整個 UI 即可。

在我后來編寫 LeanEngine Snipper 的時候，需要在前端進行大量數(shù)據(jù)處理以便根據(jù)用戶的篩選來展示圖表。一開始沒有考慮太多，部分函數(shù)是會修改其參數(shù)（往往是一個包含大量對象的數(shù)組）的，在后來支持用戶修改篩選條件時就遇到了問題 —— 原始數(shù)據(jù)在繪圖的各個環(huán)節(jié)中都有可能被修改，不得不在開始繪圖之前對原始數(shù)據(jù)進行一次 clone, 在后來的性能分析中發(fā)現(xiàn) 98% 的時間都花費在了 clone 上面。

于是我不得不重構(gòu)代碼，讓大部分函數(shù)不修改參數(shù)，而是在參數(shù)的基礎上返回一個新的對象，將需要 clone 的數(shù)據(jù)減少到了最小，經(jīng)過這次的優(yōu)化，篩選的性能提高了 40 倍以上。從直觀感受上來看，每個函數(shù)返回新的對象會消耗更多的資源，但在 JavaScript 中，返回新對象實際上只是在拷貝它的屬性的引用，并不會花費多少時間，反倒是在 clone 對象時需要遍歷所有的屬性，才需要花費大量的 CPU 時間。

-

因為最近兩年都在使用 Node.js, 我希望也使用 Node.js 來驅(qū)動我的博客，我最后選擇了插件化架構(gòu)的 Hexo —— 一個靜態(tài)博客生成器，我自己編寫了 主題，并將博客的數(shù)據(jù)也托管在 GitHub 上。后來我將 RP 主機博客、粉絲團主頁 也都遷移到了 Hexo, 后來新建的 皮蛋豆腐的博客 也使用了 Hexo.

-

今年我作為 HackPlan 的成員，參與了幾次招聘，后來我也作為求職者參加了幾次面試。

國外的一些職業(yè)，包括醫(yī)生、律師，也包括工程師，都普遍地去打造自己的個人品牌，目的是為了找到更好的工作。確實在過去兩年中這種個人品牌對我的工作是很有幫助的，在我面試的過程中，我去的幾乎所有公司的面試官都表示曾經(jīng)聽說過我。雖說技術(shù)崗位以能力為先，但至少如果混個臉熟，雙方會有一個基本的信任。

我當時說在找到工作之后會和大家分享一下參加面試的經(jīng)驗，但后來想了一下，寫出來的話應該都是關(guān)于我沒有選擇的那些公司的負面評價，大家都是同行，這樣不是很好，所以后來只寫了 加入 LeanCloud 的過程。

-

說實話，現(xiàn)在使用 Node.js 的公司依然是少數(shù)，因此在求職時我也將 PHP 納入了考慮。在我離開 PHP 之后，社區(qū)發(fā)生了許多變化，出現(xiàn)了像 Laravel 這樣設計優(yōu)良的一站式框架，composer 這個包管理器也被越來越多的人接受。為了重新?lián)炱?PHP 這個技能，我花了一些時間用 Laravel 做了一個最簡單的論壇系統(tǒng)的輪子 —— labbs-laravel.

在之前，無論是 PHP 還是 Node.js 中，我都沒有使用過像 Laravel 這種重量級的框架。Laravel 不同于國內(nèi)一些粗制濫造的重量級框架，雖然它提供了很多功能，但卻并不顯得臃腫。首先 Laravel 并沒有選擇造輪子而是構(gòu)建在 搜索結(jié)果 Packagist 中已有的包之上，它有著一個非常精簡的核心架構(gòu)，除了經(jīng)典的 MVC 支持外，其他的各類功能（認證、緩存、隊列）都被抽象成了「服務」，這些服務可以獨立為多帶帶的包發(fā)布在 Packagist 上，且同類的服務是可以互相替換的。

Laravel 對我來講最大的亮點是 ORM 部分（Eloquent），我之前用過的 ORM 比較少，在實現(xiàn) Mabolo 的過程中一直在糾結(jié)如何實現(xiàn)對象之間的引用關(guān)系。Eloquent ORM 將關(guān)系本身也抽象為了一個類，當你訪問一個對象的關(guān)系字段時，得到的是一個「關(guān)系對象」，你可以在這個對象上進行篩選和查詢等操作。其實這樣的設計還是非常直觀的，但因為我之前閉門造車，一直沒能「獨立發(fā)現(xiàn)」，在新的一年中我會用這樣的思路去給 Mabolo 添加關(guān)系支持。

-

最后如果做個總結(jié)的話，我這一年依然主要在編寫 Node.js 代碼，也寫過少量的前端代碼，對 JavaScript 的了解越來越深入。這一年的我在關(guān)注基于 Promise 的異步流程控制和錯誤處理、深入了解關(guān)系型數(shù)據(jù)庫和 SQL、探索函數(shù)式風格的 JavaScript、探索和學習插件化架構(gòu)的設計、借助 Docker 來管理應用的部署和拓展。

https://jysperm.me/2016/02/programming-of-2015/