今年5月開始前端之旅，學習近4個月之后，於9月底，參與了一個商城廠家后台的前端頁面的開發，所做的內容並不多，但是在這段時間的收獲卻不少。接下來將詳細談談這些收獲。
1）參與項目之前應該做什么
在實習剛開始的時候，主要是從git上clone代碼，然后自己在前輩的指導下查看代碼結構，理解整個流程。當時花的時間不長，基本也把代碼看的差不多了。這個是很重要的，你需要對整個前端的架構有一個大致的了解。
2）寫第一行代碼前應該做什么
仔細看產品原型，查看接口文檔。這是非常重要的，特別是原型，需要仔細的查看原型，看看那些地方存在不合理的，需要及時找產品或相關負責人溝通，最終要確保你對整個產品原型有很詳細的了解。這樣子不至於在寫頁面，寫交互的時候出現大問題。還有接口文檔也是很重要的，前端和后端都需要一份共同的接口文檔，大家根據這個文檔進行數據交互。有了共同的接口文檔，在開發過程中不用關注變量名這些無關緊要的細節。而且能確保前后端數據交互時不會有不一致的地方。
3）寫代碼時應該做什么
多思考，就能少寫幾行不必要的代碼。這是很重要的一個問題，一般來說，在最開始的時候，需要將所需要的技術掌握，然后將頁面分成幾個小塊，從整體到部分，要清楚代碼的大致結構，脈絡。先將大的東西做好，再慢慢細調。這樣子不必時刻糾結於細節，浪費不少時間。寫代碼時要遵循代碼規范，比如說Tab鍵還是空格縮進的問題，比如說是LF還是CTLF換行的問題，盡量采取和大家一致的開發環境，這樣在別人看你的代碼和你看別人的代碼時會減少不必要的麻煩。
4）寫完代碼時應該做什么
單元測試，不用多說。如果是用RAP來進行單元測試的話，要注意測試用例設計的合理性。
5）前后端聯調
前后端聯調應該采取怎樣的方式才是最好的？以前是一個前端搭配一個后端，他們用同一個分支。聯調時，后端從git上pull代碼，然后在本地跑一遍gulp，然后運行聯調。這樣有一個問題就是，當前端有問題時，如果是一個很小的問題，那么他也需要從他自己的機子上改，然后commit，push代碼，然后后端在他的機子上重新pull，gulp，運行聯調。這樣子比較繁瑣，效率不怎么高。現在的做法是前端將請求用nginx代理請求到后端的機子上，然后在前端進行測試。這樣前端發現有問題，他自己修改就好。后端不用pull代碼。后端發現有問題也是如此，這樣前后端就分開了。
6）提交給測試人員
當聯調完成之后就可以將代碼提交給測試人員。測試人員通過模擬真實數據來進行功能測試。之所以在測試階段會有這么多問題，是因為：前后端聯調的時候，對聯調數據沒太在意，以為數據跑得通就OK。導致一上到真實環境出現一堆問題。另外一個原因是，測試人員往往不能夠詳細描述問題出現的情形，比如說：在什么情況下，做了什么操作之后，出現了什么樣的結果。出現的頻率。和預期的差別。實際得到的結果往往是：出現了某個問題，然后把錯誤一截圖發給開發人員就沒了。其實對於前端來說，需要知道做了哪些操作導致的bug往往是特別重要的。
暫時就先寫這些，其實還有很多，但還沒整理好，先不寫了。