前端又稱Web前端開發工程師,主要負責製作頁面,設計互動,對接介面.與UI設計師,產品經理,和後臺開發人員協作.

根據UI設計師的設計圖 切圖,使用CSS製作高保真頁面.

根據產品經理需求,完成頁面互動,路由跳轉,功能實現,

根據後端開發提供的介面,對接介面,資料,聯調功能.

根據.....

總的來說,前端開發人員是一個很苦逼的工作,三個"根據"完全把前端開發人員的主動性和創造性完全打壓下去了.你想先做頁面,不行,你得根據UI設計師的設計圖來,你想先設計路由,實現互動,後來產品經理把這裡改了,你想準備對接介面,後臺人員還在設計表結構,MMP,還能不能好好工作了,還能不能好好的愉快的編碼?

我常常痛恨那些蹩腳的產品經理,只知道摳圖,完全沒有一點自己的設計思想,邏輯混亂,文件參差不齊,描述含糊,一份文件看下沒有幾個能做的,有的甚至只是截個圖,說,實現一個圖片一樣的功能,每次聽到這樣的話,我就想啐它一臉,沒有一點腦子.

就拿一個表單頁面來說吧,我們的產品經理總是那以前的頁面,截圖下來,改幾個字,也沒有額外的話,沒有什麼限制,你問他,他才會說.真是讓人火大.

如果讓我設計一個表單頁面我會這樣設計

首先這個頁面的入口和出口,從那裡進來,從那裡出去

其次欄位的預設值,欄位的限制規則,比如不能超過多少位元組,錯誤彈窗怎麼提示,還有內外聯動,以及彈窗的聯動,必填,選填,互動.頁面上的關鍵按鈕的功能都要寫清楚.

其次產品經理應該有個公共的設計原則,比如,表單上的取消按鈕就是返回到列表頁,或返回到上一級,比如列表頁滅有特殊說明每頁都是顯示15條

原型圖和頁面規則邏輯不要放在二個文件裡,這樣看起來很痛苦的.對於那些原型圖只是簡單截圖的需求文件我心裡是崩潰的.為了提高彼此的效率,產品所有的規則,要求,邏輯都要寫在文件裡,以便追蹤,檢視.如果只是口頭傳述,不能保證別人再問第二遍,不能保證所有需要知道這個改動的人員都在場,測試,後臺,前端,交接人員,DB,運維,等...

以上所寫的一些抱怨,要求,都是我在工作中遇到的,可能對於一些剛入門的產品經理有一些指導意義吧,或許沒有,如果產品文件一直改動,要麼是 產品定位不準確,要麼是產品經理做的還不夠好.總是,受苦的還是開發人員,對於上線前還改需求的我會回敬:next version..... 順便一提,其實我們專案專員(就是產品經理,直接負責出需求文件的)對我們還是挺不錯的,陪我們加班,給我們吃的,我經常質問她需求的問題,她也不會生氣.一個很好的女孩子.

說完了我會產品經理再來說說和後臺開發協作的糟心事吧

現在很少專案是前後端不分離的啦,所有資料都是前端通過介面請求獲得,這樣後端就要寫介面文件,

一個介面包括六部分

請求地址

介面名稱,描述

請求資料

返回資料

資料解釋

示例(重要介面需要)

請求地址要使用比較能標明操作的詞語組成,讓人看到介面,大概就能猜到它是做什麼用的,這不用多說了,重要的是下面幾個部分.請求引數,對於列表頁,根據id獲取詳情頁,這些介面都有固定的請求資料,比如頁碼,每頁多少,主鍵id 對於這些介面請求資料相似性很高的介面這些需要單獨整理出來,頁面是從0還是從1開始, 而不是不寫,讓前端調取介面時自己猜.整理出來也有助於規則統一.更好維護,介面的描述要準確,是在如果不寫該介面應用在那個頁面,應該寫應用在那個或那些功能上.請求資料一定寫型別,string int array object 寫清楚才足夠顯得專業,注重細節就會減少bug,減少溝通成本,魔鬼隱藏在細節裡.除了請求引數外,重要的還有返回引數,返回引數都是有一個基本格式的,標明介面請示是否是正常返回,嘗試用自定義的狀態碼和錯誤訊息使用約定的屬性,如{errcode:200,errmsg:'ok',data:{}},這樣前端就可以直接使用公共的方法來處理每個介面的標識狀態碼 改重定向的重定向,該彈窗的彈窗,出來資料的基本格式外,介面文件還應該讓前端,清楚地知道資料結構,而且經過儘量減低資料結構的層級,以避免不必要的麻煩,後臺在資料返回前端之前,可以先處理一下資料,這樣不僅可以去掉多餘的欄位,還可以簡化資料結構,還有一個好處是後臺完全可以先寫介面文件,有了二次資料處理根本不需要再次更改資料欄位.大大的提高前後端工效效率.這是關於介面返回的資料的一下  想法和要求,另外返回的資料應該對應前端也頁面上的每一個欄位,有的欄位需要直接顯示,有的欄位需要轉義,比如狀態碼.還有的欄位需要和其他欄位一起計算顯示在頁面上,這些東西都要寫清楚,為了不是人誤會,也為了以後更好的維護專案.這些都是必須要做的.

工作的協作方式是要不斷改進,前端作為一個承前啟後的中心點,發揮著不可替代的作用,不重視前端的公司,其工作流程,工作效率肯定還不夠好.