上個月，由于時間關系，在項目初始選型時，選擇了Mint-Ui。。。然后入坑了，此后項目堅決不用這個Ui框架啦。。。
該項目是為公司合作伙伴服務的，比較簡單，涉及到的無非就是增刪改查的功能，因此這個項目采用的是官方推薦的vue-cli腳手架搭建，文檔目錄結構是：
webpack相關的環境設置，處于應用層面的技術水平，說不出啥太好的見解。
前端的測試工具，說實話，目前很多小型團隊，真的沒啥必要使用，在沒有嚴格成體系的前端規范前提下，這種就是自個兒玩玩的東西，畢竟更大的比重和時間在于實現公司的產品。
這個項目體現不了前端工程化亦或者前端MVC的思想理念，簡單說下src相關的，src當中除了基礎的main.js 、APP.vue、routes、filters、utils、assets外，一般項目都會公共配置api，api當中會根據自己的喜好封裝一下數據請求的方法。
pages里面根據頁面緯度來進行開發。這個項目初始的時候懶了一下，每個程序猿都會在寫代碼的某個時刻偷個懶，不巧的是寫這個的時候真的偷懶了。1.0當中，書寫頁面時，只是根據原型圖，看到什么功能寫什么，沒有過多去思考和分離代碼，因此復雜的頁面代碼就略顯臃腫。我覺得自己首先需要優化的就是提取公共的組件（這個工作不要粗心簡單地看待，需要考慮更全面），應該分的更詳細一些；其次以頁面緯度進行開發也沒啥問題，但是每個頁面需要更嚴格地按照組件化的思想進行優化。
這個版本當中，es6的對象、數組的語法使用了一些，其中發現 object. assign這個方法在低版本的安卓機型上無法兼容。相信瀏覽器全面兼容es6的時代很快來臨了把，日常工作學習定要加強對es6的熟練度。。。
這個項目使用less作為css預編譯，其實less最方便的地方還是在于嵌套以及定義變量，其余也就如此吧，其實less sass 在大型項目里才能真正體現出它的作用，這種小項目，css本來就少而且比較獨立，因此使用他們無非加強熟練程度而已。目前的spa開發，主流布局還是以flex彈性盒模型居多，postcss還是需要的，自動給為css加上內核前綴。
最后，我認為目前前端的浪潮中，大家都是會去使用一個主流的前端框架來幫助自己快速的完成公司產品，甚至很多公司不要UI，樣式的設計完全按照框架的樣子來寫，此時前端人員需要具備和加強交互設計的能力，用戶的體驗感都在前端的代碼之下。在日后的項目開發當中，項目開發前，還是需要花時間和精力去做好項目規劃，雖然測試人員看到的都是同樣的東西，為何不寫一份好的代碼給自己看給同事看呢？
時刻告誡自己不要寫懶代碼。。。
與君共勉！！！
