background
最近部門的專案比較多，而且慢慢開始有較多的專案有介面對接的需求，有的同志包括我剛開始接到這樣的任務的時候可能會不太熟悉，考慮到後面這樣的工作比重會越來越大，今天就來介紹一下日常開發中涉及到介面對接的內容，以下內容是我自己在工作中總結出來的拙見，如有不當之處請各位大佬指正！
throw the result firstly!
先丟擲結論，介面對接，就是把我們平時任務中用的模擬資料換成真實介面，而已。乍一看感覺蠻簡單的，但是實際上在投入到工作中後會遇到各種各樣的問題，後面會依次介紹。
why?
前後端分離，就是前端和後端分離，前臺邏輯全部邏輯由前端實現，而後臺只需要專注於介面，確保提供符合規範及需求的資料介面給前端呼叫，一方面能夠提高工作效率，另一方面也大大增加了前臺頁面的可維護性。 我們部門很大一部分前後端分離工作都涉及到入口網站、oa對接。先來隨便看看一些經常碰到的網站是啥樣的。
可以看到，這些網站都有一些共性，大量的列表資訊，還有不同的欄目，使用者登入，這些功能的實現都遵循對應的規則，也就形成了介面規範，關於這個可以在oa上檢視標準版oa對接文件或者在部門網站檢視相關介紹。
how？
在工作中，以oa對接為例，我將其中涉及到前端的工作內容總結為這幾塊。
- 重構，這個就不多說了。
- 根據介面開發提供的介面文件進行資料對接。
- 有的時候你可能需要自己登陸後臺錄入一些模擬資料。
- 一些個性化的需求的溝通，調整（這個最難，最耗時）。
- 一些莫名其妙的需求修改（這個最噁心）。
以oa網站來說，簡單的示意圖如下（我是這麼認為的...）：
從圖中可以看出，oa和介面、資料庫都部署在伺服器上（也可能在不同的伺服器上），前臺網站是使用者訪問伺服器獲取的，呼叫介面，拿到資料再展現在前臺，資料資訊的維護可以在oa後臺來維護，有時候前端開發也會做一些這樣的工作，大致流程就是這樣。
type
目前我接觸到的前後分離的工作大概可以總結為以下幾種。
-
1 標準版oa對接 這種型別的任務比較常見，直接根據標準版oa介面的文件，標準版oa介面文件包含了非常全面的內容，能夠滿足大部分oa對接入口網站的需求。在只需要標準版對接的情況下，是非常方便的，只需要把平時開發中獲取的模擬資料從介面中獲取即可。
-
2 個性化oa介面 雖然標準版能夠滿足大部分需求，但是還是存在較多的網站有一個需要個性化的需求，比如列表資訊需要展示額外的欄位等，這個時候就需要介面開發對介面做一些個性化修改，實際開發以介面開發提供的文件為主。
-
3 按照公司規範，自己設計資料格式模擬介面，後臺根據前端設計的資料格式實現介面，此類開發一般以前端主導。
notice
從我不多的前後端分離開發經歷來看，我覺得前後分離最難得地方就是溝通，介面的調整個性化需要溝通，需求變動、頁面調整也需要溝通。溝通的好壞直接影響到後續工作的效率及質量。接下來分享一下我能想到的一些注意點或者常見的問題。
-
1 跨域問題 遇到這種問題，不要想著自己配代理、anyproxy什麼的，這些我覺得是第二方案，直接找後臺在伺服器配一下跨域規則即可，一步到位，避免浪費時間。
-
2 現有介面滿足不了需求 介面滿足不了需求，對前端來說最好的解決方案就是改介面，比如說要在列表加一個會議室欄位，比如這樣的，oa標準版介面沒有這樣的欄位，有的介面開發可能會讓你直接在列表標題前加上幾個字就行，但是這樣的方案只是治標不治本，而且如果這樣做會加大自己的工作量，給自己挖坑。
-
3 適當的評估需求的合理性，不要來什麼就做什麼 經常會有一些莫名其妙的需求，並且在使用者體驗上來不合理，遇到這種情況還是要跟專案組溝通，引導客戶把需求往合理的方向去提，當然這個工作主要是實施同事來做。一些不合理並且不重要的需求，可以適當拒絕。
-
4 程式碼可讀性，可維護性也非產重要 我目前做的幾個對接oa的任務，基本每一個都是不停的在改改改，一個專案從第一次交付到最終上線，程式碼實現邏輯可能會“大變樣”，後面的修改都會跑到我們手裡，所以把程式碼寫的方便維護真的非常重要，不然真的會被自己坑。
tips
- 一般介面對接開發時調的都是測試環境的介面，將所有涉及到呼叫介面的ajax語句中的url的公共部分提取成全域性變數，方便切換真實環境和測試環境。
- 能一次獲取的資料，不要獲取兩次。最最典型的例子就是使用者資訊，一般入口網站都是 首頁-二級頁-詳情頁 三級模式，每一頁的頭部可能都會有一塊展示使用者資訊，這些相同的資料，可以只請求一次，多個頁面共用。
- 相同的操作可以提取成公共函式，這個可以參考部門骨架裡common.js。
- 每個功能都可以看成一個模組，細化再細化，做到每個函式模組的功能只專注於一個任務，定義合理的引數，暴露適當的介面等等，這樣在維護修改的時候只需要修改對應的模組而不用擔心影響到其他模組，非常舒服。
- 儘可能的考慮各種情況，比如文字過長等，開發的時候不考慮，改bug的時候心裡苦啊。
- 非常重要的一點，拿到任務先別急著開發，磨刀不誤砍柴工，理清楚邏輯思路再做。
- 自己模擬資料注意資料結構，利於維護。
- ie虐我千百遍，我待ie如初戀。 大部門使用者電腦都是ie8，所以這個相容性還是要多考慮的。
- 非常容易踩的一個坑，純正的ie8是不支援console.log語句的！！！請在交付的時候（不管是不是ie），將console除錯程式碼註釋或刪除！
- echarts配置寫對了不生效，99%的解決方案就是去官網下最新的js檔案！
- 可以對高版本瀏覽器做一些漸進增強的效果，比如加個transition變色什麼的，我覺得很好看。