今天找文件的時候突然發現了一枚總結文檔，覺得有必要留存，以防下次找不著就一不小心發了這篇，哈哈哈

一直做後臺管理系統，采用react前後端分離，以接口的形式相互交流，猝不及防得來了三個頁面開發，然後：

項目概況：二月開始接手A項目，該項目由前端寫靜態頁面，php開發嵌套數據的形式展現，為期一個月，給前端時間為兩周，然後交付到數據嵌套的人員；三月中旬開始接手B項目，該項目有兩個端，支付寶端C端以及後臺管理平臺，這兩個項目統統由前端寫靜態頁面，java來嵌套數據。

項目詳情：

1.A項目：由於一直沒有好好的啃過bootstrap，對於這個有點熟悉又陌生，使用過但是都是別人已經搭好整體框架，自己在那個框架的基礎之上進行修改調整叠代需求，也就是粘過來刪刪改改。於是最開始沒想要運用這個，試圖自己從

對於網站類項目經驗缺乏，然後又是第一次自己一個人擔任一個完整的前端，沒有一點兒懈怠，就開始了bootstrap的摸索之路。開始寫demo實驗，差不多試驗了兩天把頭部尾部等公共部分完成，寫好了一個頁面。在試驗響應式的時候，沒有手機端頁面設計，然後做起來也花費大量時間經歷，結合產品方面的需求，最後決定將頁面寬度定位

對於文件的結構糾結了一段時間，一開始給每個頁面都寫了一個樣式文件，但是請求這麽多樣式文件也是很消耗資源的，有的頁面樣式添加的還是蠻少的，到後來就把自己寫的全部樣式文件都寫入到了一個文件裏面index.css有大概50k的樣子。

2.支付寶C端：根據之前支付寶生活號的開發，便於後期統一管理維護，於是借鑒了他們采用的技術，采用antUI組件，所有新增樣式差不多22k的樣子，對於手機端還是蠻好用的，手機端的常用組件基本上都有，在支付寶裏面也不會存在兼容性。

3.後臺

存在的問題：

1.常用的控件應該積累起來，到時候要用了直接取過來用。控件比如：時間選擇，分頁，輸入匹配，輪播，彈框，弱提示，等等

2.對於框架裏面的樣式我們是直接重寫，還是自己再取class來覆蓋掉

3.UI設計跟框架出入較大，調整內容較多。

4.交付之前總是很想盡善盡美，但是一交付出去就出現問題，這次一連三個項目都這樣，同類型的技術形式沒有放一起總結。嵌套形式的完整交付必須包括：頁面沒有遺漏，錯誤頁面，表單驗證機制，通用的報錯提醒，弱提示，彈框的用法。

解決問題：

1.針對控件的積累問題，在查找控件的時候發現一個好辦法，那就是把平常的好用的控件都放到一個地方集中管理，推薦放到GIthub找的時候比較方便不用電腦裏死找文件。借鑒一些好的做法，然後自己寫寫，自己寫的用起來肯定更加順手，有些控件基本上每個系統會出現，更加得自己動手去寫，理解其中的原理。

2.在項目中采用的方法是，在自己的class下覆蓋框架內部。

3.盡量避免UI在前端之前介入產品，盡量在技術框架選定之後再去進行針對性的UI設計，不然會有很多調整，重寫。

4.***important***頁面一般不會落下，下次嵌套項目進行之前，首先把基礎設施建好，可行性demo，錯誤頁面，表單驗證機制，通用的報錯提醒，弱提示，彈框的用法，在這些全部完成的情況下再去動手寫頁面，預防最後匆匆交付然後遺漏了。

總結：三種框架之前都沒有用過，能在項目開始之前寫可行性demo，在技術選型的時候聽取同事提出的的建議，在A項目前臺開發的時候，推薦的bootstrap獲得良好的兼容性，antUI是借鑒之前支付寶生活號的開發方式，B端選型的時候在項目經理確定只能出靜態頁面時，采用原來php開發人員用的metronic.bootstrap。

之前一直很恐懼的用插件框架，感覺無法駕馭，擔心用著不完全符合需求，後期自己不會改，這次之後，能自己動手找到問題所在，然後進行調整（A項目輪播，帶戶型說明等），一步一步摸索，變得不那麽害怕新的東西，也不那麽害怕自己一個人去整理規劃整個項目了。

前後端不分離