今天和網上的朋友聊到了前端開發，這位朋友真是一位大師級人物，聊聊幾句話，幾乎就概括了整個前端的開發工作。
我整理了一下，前端的開發工作大致包含3點：
1. 前后端的數據交互
2. DOM操作
3. 模塊化設計
/* 因此，我也興趣大發，想借此寫點什么。首先聲明一下，下面的口水話較多，僅當是一次技術閑聊，多有不嚴謹之處，還望大家多多指教。*/
這3點將我們前端雜亂無章的開發工作梳理了一遍，至少讓我們的思路得到片刻清晰，是的至少是片刻清晰。讓緊綳的神經得到片刻放松。
我個人從事開發工作有15年時間，其中大概有5年左右的Web前端經驗。 至少到目前為止，還沒有一個項目能夠給我上面3點的那種輕松的感覺。這就像我們看房子的樣板間，家具擺放得賞心悅目，但當我們真的住進去之后，才發現各種問題。
的確，軟件開發的實際情況從來都沒有過看起來如此簡單過。現在就讓我們進入這個樣板間轉轉。
前后端的數據交互
我們至少可以通過以下庫來實現前后端的數據交互
- AngularJs的http
- JQuery的ajax
- axios
- WebSocket
對於AngularJs的http，如果你用AngularJs進行開發，一般都使用http模塊。據我了解，大多數類似於angularjs的重量級js框架，都會有其自身的前后端數據交互模塊。
對於后面3種，它們一個比一個專。
JQuery的ajax是通過JQuery這個輕量級的Js框架發布的。JQuery作為Js世界的老大哥，很多現有的其它js框架都會跟jQuery兼容 。而JQuery又有着很強的DOM操作能力。因此，當JQuery作為項目前端架構的一部分時，通常也會使用到JQuery的ajax來實現前后端通信。
axios則只專注於http的數據通信，它可以在nodejs和瀏覽器環境下運行。支持Promise對象。我之所以在這里提到axios，是因為我曾經使用過它，個人感覺api設計得不錯。但事實上，在npmjs的網站上，類似的庫還有很多。
DOM操作
這方面的技術，個人認為，鼻祖就是JQuery。以前我也試過ExtJs，Dojo，里面也有類似的DOM操作庫。
DOM操作的目的是展現數據。關於數據展現，最初就是簡單的表單和列表，后來隨着web應用的日漸繁榮和需求的日益復雜，出現了WYSIWYG編輯器和類似於JQueryUI， Bootstrap的各種庫。最終，這些UI庫隱藏了DOM操作的細節，只暴露出API給開發人員調用，使得開發人員只用正確配置和調用接口，就可以實現很酷的界面效果。
目前，就我個人的觀點，最好用的UI庫是Boostrap，它不僅提供了目前常用的Js插件，還提供了一套頁面布局的標准。這些都和DOM的操作緊密相關。
當然，EasyUI也是一個很強大的Js庫，提供了豐富報表和界面插件。限於個人的見識，我相信還有不少類似於EasyUI的Js庫。在這些Js庫的幫助下，可以完成我們日常需要的各種復雜界面。
我個人認為，DOM的操作可以分為3個層次：
- 能夠使用Js庫來完成DOM的操作
- 能夠解決Js庫的沖突，Js庫的樣式問題和Js庫的瀏覽器兼容性問題
- 能夠自己寫Js庫來完成DOM的操作
模塊化設計
我對Js的模塊化設計最初是從Js的閉包開始的，然后接觸到了requireJs，然后是AngularJs。
最初的模塊化設計僅僅是為了管理日趨龐大的代碼，隨着requireJs的出現，又出現了模塊加載的能力。個人認為，無論模塊化的技術怎么發展，模塊化設計都離不開業務分析的結果，模塊化設計是技術與業務的結合，業務分析在這個階段必不可少。
如果你的項目已經使用了angularJs這樣的重型框架，那么它已經為你提供了模塊化設計的技術支持。如果你想自己去構建項目的模塊，那還是推薦使用requireJs或者seaJs。
因此，從技術層面上來說，模塊化設計依賴於各種Js框架/庫提供的技術支持，了解並掌握類似於AngularJs, requireJs的模塊定義就可以了。而從業務層面上看，則可以參考Eric Evan 的Domain Driven Design這本書。
個人認為，模塊化的設計核心價值是讓系統得到有序構建，其衡量標准是讓模塊之間的依賴盡量簡單，其實現的方式是讓模塊功能范圍與業務的相關范圍得到最大程度的匹配。因此，模塊化設計的切入點就是對先對業務模型進行設計。
-------------------------------------
目前來說，這三個方面基本闡述完畢，看上去也比較單純。這里借用一位我們的祖先老子的一句話：道生一，一生二，二生三，三生萬物。貌似什么事情，過了3就會變得復雜起來。
下面給出一個例子，來展示這3個方面扭在一起時的情況。
以TypeScript的Angularjs 2項目為例。
假設我們定義了serviceA用於前后端數據交互。
定義了componentA用於數據展示，即dom的操作。
定義了一個module，用於存放serviceA和componentA，用於模塊化設計。
個人認為，用於前后端數據交互的service定義，在javascript的動態語言環境下，不過就是一個管道，甚至不用去考慮傳輸的數據結構是怎么樣的，只用關心如何正確傳入參數和正確獲取輸出。而真正要關心的是獲取的數據如何正確綁定/顯示到界面上，界面上的參數如何正確綁定到service要傳入的參數上面。這時，我們會想到component的定義，或者是在界面上，會展示/編輯什么數據。從理論上講，后台傳到前台的數據應該直接綁定到界面上就結束了，數據沒有理由增加或減少。唯一需要做的是在前台定義個model來綁定到界面設置的參數上，最后在查詢時，將這個model傳給service，但有時，這一步都可以被省略。
到目前為止，我們都還是理論上的推導，但在實際開發中，這些僅僅是保留在大腦里還未付諸實施的想法。當我們開始動手編碼的時候，我們會遇到各種各樣的問題。
- 子數據的處理
- 數據選項的展示
- 數據驗證
- 根據數據A推導出數據B的數據展示
子數據的處理需求一般來至於業務的逐漸完善。當我們完成藍圖的第一個版本設計的時候，我們構建的數據模型是抽象的。抽象意味着任何一個點在實施的時候，都有可能再向更深的邏輯層次展開。
因此，隨着業務的逐漸完善，這種抽象到更深層次的展開就不可避免。
這種情況帶來的干擾是數據處理出現了分支。出現了分支，就會有分支展開和分支回歸操作。這種展開和回歸的操作具體到代碼中，它幾乎會同時影響到我們上面提到的3個方面。
在前后台的數據交互方面， 會影響到定義的model的結構，會添加新的結構來映射子數據。
在DOM的操作方面，會定義出新的區域來展示和操作子數據，而這個動作無疑會引入新的，和業務關系不大的膠水代碼，而最終貢獻了代碼的復雜性。
在模塊化設計方面，你需要決定是否設計出新的component來存儲相關的代碼，如果你決定是否定的，那么就要修改處理主干數據的component，如果你決定是肯定的，那么整個系統的結構就會受到一定程度的影響。
數據選項的展示無論是在“先天的”設計階段還是在“后天的”開發階段都會影響到開發的三個方面。
數據選項和數據字典不同在於，它是根據當前的上下文，動態生成的。它涉及到事件的聯動處理，DOM的動態更新以及默認選項的處理。我曾經遇到過的復雜情況，事件的聯動超過了4級。而這些聯動處理都是膠水代碼，不易於維護。
數據驗證是一種技術挑戰。數據驗證的方式有：
- 前端的數據驗證
- 后端的數據驗證
實時的數據驗證對技術要求比較高，它要求對用戶的每一次鍵盤敲擊進行數據驗證，AngularJs 2的ValidatorDirective可以助我們一臂之力。對於簡單的驗證邏輯，我們可以直接將其放在自定義的Directive里面，對於復雜的業務邏輯，可以放在Service里面。雖然，我們已經有了清晰的思路來處理驗證代碼，但是對於這些驗證的配置，需要不少的時間，當然也會貢獻出不少代碼。
保存數據時的數據驗證發生在數據完成編輯后，將數據持久化之前的這個窗口中。隨着現今類似於Angularjs前台框架的應用，很多時候，數據驗證也被放在了前台。但是，按照傳統的分布式系統的設計方式，數據驗證會被放在后台，這樣有利於業務邏輯在更大層面上的復用。
前端的數據驗證優勢在於速度快，后端的數據驗證優勢在於對數據的處理能力強。因此，通常情況下，我們要同時使用前后台的數據驗證方式，來一起解決問題。注意，這里還有一顆地雷，就是前后台的驗證邏輯同步問題。
但不管是前端的數據驗證還是后端的數據驗證，最終都需要將驗證的邏輯體現在DOM上面。這使得前后端的數據交互和DOM的數據展示再一次擰在了一起。這里再一次考驗架構師的真實能力，但無論怎么設計，代碼的復雜性因此而再次增加。
根據數據A推導出數據B的數據顯示通常是開發后期追加的業務需求。個人認為它是對代碼結構沖擊最大的方式。它在處理上創建的分支首先會影響到已經穩定的結構。由於得響應某個事件來加載數據，因此，還必須為此添加額外的膠水代碼。而這段膠水代碼，會影響到前后台的數據交互，會影響到DOM的數據展示和操作響應，最終可能到處都被糊上了。
上面這些問題僅僅是從應用的業務邏輯實現來看的，還有無數的日日夜夜處理的瀏覽器兼容問題，特別是使用了類似於Bootstrap這樣的CSS框架后還遇到的瀏覽器兼容問題，這里我就不多說了。
以上就是個人的一些想法，寫到這里，我發現這里既是結束，又是開始。既然都已經知道了這些問題的模式，那么就有對應的解決模式，容我再想想，有時間接着侃吧。
上面寫了這么多，都沒有一行代碼，如需代碼，請前往 https://github.com/cao5zy/restful_angularjs
口水話較多，限於個人的經驗，漏洞百出，還望大家多多指教。