做項目有一段時間了，利用下班或者零碎時間的功夫，想分享一些個人心得和感受。與君共勉。

前端應該具備的幾個能力：

（1）準備假數據（模擬數據）的能力，因為后端有時候接口沒有準備好，前端沒有數據，但是排期比較緊，不能等待后端，前端要有造模擬數據的能力

（2）有跳過某一個業務邏輯的能力，假如一個閉環的業務需要5步可以完成，如果2卡住了，那么345就不能繼續推進，當然麻煩后端改數據庫確實是一個好辦法，簡單粗暴。如果是不得已的情況下，又是在開發環境我想也行吧。

（3）數據處理的能力，有時候數據后端處理好，前端直接渲染比較輕松，但如果接口返回的數據并不能直接使用就需要前端在渲染頁面之前要進行一些數據處理，有時候數據處理的工作量還比較大。這是一個比較模糊的問題，需要考慮好這個數據處理的工作是誰來做比較好？

（4）校驗的問題。前端的校驗可以替代后端省去不少校驗工作，但是如果直接用postman接口工具去測試就會存在問題。校驗的問題在一些場景是前端做比較好，例如表單校驗；另一些場景，例如數據量較大的重復性檢索的問題肯定是后端校驗。還是要根據具體場景具體分析。

（5）多個項目同時開發的情況，后端的開發環境操作，影響前端不同版本的迭代開發，應該怎么辦？

（6）代碼分支的管理，項目多的時候，或者同一個項目需要同時迭代多個版本的時候，代碼管理尤為重要。以前做的項目在這方面沒有規范，隨著越來越正規，還有就是分支寫多了，就慢慢有了新的感悟，這一塊確實有必要去維護好。如果引起代碼丟失或者項目發布沒有合并代碼的話是比較嚴重的發布事故。

（7）封裝組件的能力，這里分享一點我自己的想法，根據個人經驗，我想，前端組件可以簡單分為公共的一般功能組件和實現業務的業務組件，一般功能組件是實現系統普遍存在的一般性功能，可以方便之后的相似功能業務的開發。業務組件就是和我們的需求業務有很強的關聯，其中的數據，邏輯跟我們的業務強耦合，一般不能再放入其他頁面中使用。我們前端在封裝組件的時候確實需要也是一定要考慮的一件事情就是盡可能的不要把業務上的數據和邏輯放入到這種一般性功能的組件之中，這樣會產生一些代碼的耦合，我們的項目在逐漸健壯起來的時候，就很難再操作。所以在操作組件的時候，盡可能把數據和邏輯準備在業務組件中，假如我們不得不這樣做的時候，也最好寫好備注，并且盡量不影響以前的代碼邏輯。以前剛開始做項目的時候就確實碰到這個問題，導致本來封裝的一個table組件，其中添加了太多的if和else，我想就是因為和業務耦合性太強，不過這是一方面，另一方面就是迭代的次數頻繁，加上周期比較久，經手人多，就改起來難度變大了一些。所以針對于封裝組件這一點，我在現在的項目開發中也慢慢發現了一些可以去優化的點，那么就要在之后的項目迭代中如果要封裝組件，那么就應該盡可能規避掉一些問題，這也是如果在排期比較充足，有時間的話需要進一步優化的事情。畢竟這可以讓我們使用組件的時候更流暢一些。

to be continued...