周六去了趟杭州參加 D2 前端技術論壇。
阿里的確很大，但也很遠，感覺都要出杭州了。
眾所周知的是，阿里的前端技術在業(yè)界一直處于領先地位，不論是技術的深度還是廣度都難忘其項背。當然，我們現(xiàn)在使用的一些技術在橫向上已經(jīng)可以跟上時代的潮流了。比如 React ，比如 ReactNative ，當然還有一直很火熱的 Node.js。
React
React 方面，我所在的部門剛開始搞。支付寶所做的 AntDesign 是一個非常不錯的示范，可能也是我之后要在我們組做的一些事情：抽象出很多的基礎組件用于業(yè)務邏輯的開發(fā)。當然?這肯定是一個很漫長的積累的過程。任重而道遠，仁以為己任。
React Native
由于當時那個分會場實在太小，沒有擠進去聽元彥和他同事的分享。不過據(jù)說很多內容都是關于 React 和 ReactNative 的介紹。還有就是淘寶前端會開源一些他們在這方面的實踐。一個是 react-web ，還有一些 RN 相關的工具吧。也都是道聽途說，到時候等 slide 出來再仔細看看。
我們部門在 RN 方面已經(jīng)有了上線的實踐，之后也會在公司內部做一些分享。
雖然現(xiàn)在應用的規(guī)模還不大，值得肯定的一點是確實開發(fā)效率比較高，基本上我們是3人2周開發(fā)出一個完整的應用（包括了消息推送，產(chǎn)品搜索，產(chǎn)品列表，產(chǎn)品詳情以及訂單的一些內容），其中還有兩個原先是做 iOS 開發(fā)的同事，基本上是從零到一的一個過程。
現(xiàn)在看來還是有些隱患的，比如：
- 路由的管理。我們現(xiàn)在是直接用 Navigator 來進行操作的，直接寫了一個 Mapper 的方法來管理各種跳轉，比較混亂。
- 接口的抽象。很多接口其實調用方式都是一樣的，但是都分散在了不同的 View 里面。這其實嚴重的違背了 DRY 原則，這是一定要改掉的。
- 代碼的質量。正如我前面所說，只有我一個是原先寫前端/Node.js 的開發(fā)，另外兩個對于 JavaScript 和 ReactNative 基本上是新手的姿態(tài)進入項目開發(fā)的。所以在很多代碼結構以及編碼風格方面確實做的不是很好。這可能是我們項目的一大隱患。
- More...不得不承認的一點是，由于項目的進度要求以及人員配置的問題，在項目開始變得龐大的時候還會暴露出更多的問題。
Node.js
Node 方面，我們部門已經(jīng)實踐了將近大半年時間了。當然之前還有一些失敗項目的鋪墊，這就不談了。
這次在 D2上聽了不四(dead-horse)的分享。大部分內容都是之前在天貓的 Github 分享上看到過的。相比他們，我們的規(guī)模可能在可見的未來也不會達到那個程度，不過還是有很多可以值得借鑒的地方的。
- 私有 NPM。這是我在很早之前就想在公司內建設的東西。這對于企業(yè)的 Node.js 開發(fā)而言還是比較重要的，畢竟很多可以復用的東西用 require 文件路徑的方式來做還是很蛋疼的事情。封裝成模塊，配以完善的文檔對于日后的維護和新員工對系統(tǒng)的熟悉都是很重要的。
- 單元測試。測試在我們這一直沒有得到應有的重視，基本上一個 feature 會有一些黑盒測試的用例，然后由測試人員進行覆蓋。但是從任何角度來說，單元測試都是很重要的。不過我在這方面實踐的確實很少，之前也只有在一些小的模塊里寫過一些測試用例。這也是我們之后需要提高的點。
- 性能。對于前端來說主要還是 CDN ，這方面也沒有很好的提升空間，關鍵還是看量。至于 Node.js 代碼層面的性能，之前也使用過樸靈大大的 node-profiler -- 雖然確實能捕捉到很多代碼相關的內容，但是并不是很好分析。聽同事和他聊好像還要接入到 Alinode 的服務才能進一步分析。
- 穩(wěn)定性。天貓使用的自己開發(fā)的一些諸如 cfork, graceful 等模塊然后配合 Node.js 的 cluster 進行應用的管理。不四也表示不使用 PM2就是因為它的提及比應用本身還龐大。不過我倒是覺得這并不是一個問題。 PM2 已經(jīng)是一個成熟的管理工具，它的體積并不會影響我們應用的性能。而且還可以基于它提供的一些 API 做一些后臺監(jiān)控（我們現(xiàn)在暫時只實現(xiàn)了一個可以管理應用狀態(tài)和監(jiān)控 CPU 和內存的后臺）。就我們現(xiàn)在在線上跑的兩個應用來講，基本上不是代碼寫的出大 BUG 了，還沒有出現(xiàn)過宕機的情況。
早點休息了，明天上班繼續(xù)擼 React :D
