【前言】
本文是我們UED組一名前端工程師的總結和心得。作為Web前端新人，小明在工作中發現了些問題也體悟到自己的進步。實際上很多類型的工作或項目，都值得階段性的歸納和總結，同時為寫總結而抓耳撓腮的同類朋友們，直接拿走，不送！
下為原文：
2017年4月1日——5月17日
2017年4月1日，正式編寫基礎通用平臺PC端前端代碼。按照以往的編寫習慣和思路，首先我將公共部分樣式寫在一起，然後根據UI設計師提供的源文件進行頁面99%的還原，最後交與後臺工程師。
開始是按照響應式PC端書寫代碼，運用jQ框架，書寫頁面交互效果。後來是應後臺要求書寫固定尺寸的PC端。結果有很多地方呈現的效果並不是上級想要的效果。最終確定的部分固定，部分響應。比如table表單標籤和間距為響應式，內容高度固定等。
截止今日（2017年5月17日），算是徹底完成了基礎通用平臺的架構和數據更新工作。這期間遇到了很多的問題，我也又一次有了質的成長。
問題
一、我認為前端工作的重要性就在於將UI設計師與後臺工程師銜接起來，前端工程師參與瞭解整個項目的內容能夠讓團隊更好的更高效的更準確的完成工作。剛開始做此項目的前端構架時只有UI設計師與我溝通協作，因此我不能完全的理解工作要求和內容，以至於後來不能滿足後臺工程師的要求導致樣式的不斷更改。這其中有個我自身的原因，我剛剛來到公司，不曉得後臺工程師是誰，有哪些，以及我要完成的項目是什麼。我想這不只是我的尷尬，這也是大部分新員工的尷尬。
建議：對於新員工的到來，尤其要讓團隊合作性強工作的新員工首先熟悉團隊，緊接著就是了解熟悉工作內容，參與工作的進程，為此更好的完成工作。
二、這次的工作最主要的問題就是出現在彈窗問題上。其他的頁面，比如首頁、登錄頁、APP頁和詳情頁都是有源文件，所以能夠很好的完成設計稿還原。其他的就像彈窗，源文件中只有兩種彈窗結構，後來就是後臺需要哪種樣式的我就設計編寫哪種樣式的，最後才確定出通用版彈窗樣式。再此之前做的很多彈窗樣式成了無用工，浪費了時間也花費了精力。
建議：在做原型的時候就分好類，比如表單頁面的通用樣式和列表的通用樣式，然後UI設計師給出標準，我再將還原的標準交給後臺，這樣就避免了重複工作和無用工作，同時也能減少工作時間，加快團隊的工作效率。
三、溝通問題。此次工作在溝通的時候沒有出現多少問題，我們能夠相互理解對方表達和想要的效果。溝通上的問題主要出現在前期沒有與所有團隊成員溝通或者溝通較少，不曉得哪些是需要自適應寬高的結構，哪些是固定寬高結構。
建議：下個項目開始之前我能夠多做一些瞭解，最好是跟進項目從確定到製作的進程，這樣我能更好的確定樣式類型和編寫。
四、樣式應用問題。在後臺使用樣式的時候，我發現有些的彈窗樣式已有，但是後臺並沒有使用我給出的樣式，而是用其他彈窗的樣式，對於特殊部分的後臺自己做了編寫。
對於這樣的做法我不贊同，原因一：我寫的樣式是後臺提出並且確定需要的，如果寫完的樣式後臺不應用等於我做無用功；原因二：後臺編寫的樣式出問題後我要去找源頭，看代碼，看樣式，費時費力，增加不必要的工作內容和工作時間。
建議：後臺工程師應用我寫的樣式，一步到位。對於內容多少不定寬高自定義的樣式還需後臺自己定義。我希望團隊合作能夠緊密一些，這樣能夠更好更快的完成工作。總結一下就是說：後臺需要樣式就和我說，我寫，然後後臺應用即可。
成長
1、規範化樣式名稱。以前編寫代碼都是通過網上查詢此模塊名稱的英文單詞，比如警告（warn）。事實上前端樣式名稱有一套自己的規範，比如彈窗（pop）。規範可以更好的方便前端工程師，也能讓後臺工程師明白樣式名稱的含義。此次機會讓我係統的學習和掌握了前端樣式名稱規範，也為我以後編寫規範化樣式打下良好的基礎。
2、通用架構。通用樣式通用寫，特殊樣式要命名。通用樣式使用標籤選擇器來編寫樣式，特殊樣式用類名來編寫樣式。
3、兼容性。IE8的標籤選擇器與h5標籤選擇器有很大的不同，建議涉及IE8及以下的瀏覽器兼容性的時候用類名來書寫樣式，這樣就減少了css樣式代碼的編寫，能更快的加載頁面，同時也能更高效的完成工作。
彈框的確不少
最後
感謝劉總在工作上對我指導，使我的前端編寫更加規範化和專業化。同時謝謝邱總和後臺工程師們對我工作的幫助和理解。也謝謝UI設計師的合作和鼓勵。最後謝謝我的組長對我的教導和工作上生活上的幫助。
小明
2017年5月
正文完
UI-用戶界面；UE-用戶體驗；UCD-以用戶為中心的設計