【進階】前端幸福感是怎樣煉成的（上）

前言

作前端開發已經有一年多了，前端這個職業，在不少人看來就是一個切圖仔、頁面仔，包括產品、UI或後端等同事，不少時候在他們看來，前端只需按照設計圖作頁面，作作交互，對接接口，工做比較簡單沒有難度。可是前端真的是這樣簡單嗎？

其實近年來前端須要學習的知識愈來愈多，從之前前端三劍客，到如今的各類框架、混合開發、各種小程序開發、打包工具、服務端知識等等，不少前端小夥伴直言學不動了，前端焦慮感也愈來愈強。那咱們要如何在這種別人誤解的目光下與焦慮感日漸強大的狀況下，練就、保持前端幸福感呢？我總結了一年多以來的經歷和經驗，分紅外在因素和內在因素（技巧、技術提高）兩方面，本文分享外在因素。

重要的幾個點

在說外在因素以前，先看如下一些點：

• 熟知業務，熟悉產品原型
• 積極參加項目評審
• 技術評估，瞭解技術實現的細節，肯定技術邊界
• 全局視野，業務、技術拓展性

不知道你們在平常開發中，有沒有作到或關注到以上這些點。其實可以影響到咱們對一種職業的幸福感的外在因素，基本就是對外合做溝通，而合做比較多的，從產品到UI，後端到測試，那這跟咱們上面講到的幾個點有什麼聯繫呢？

於產品而言

熟知業務需求，明白業務的目標、方向以及核心KPI，這是跟產品溝通最好的方法。

不少時候技術跟產品的撕x，都是由於溝通不暢。

我身邊的同事常常跟產品撕x，但仔細聽來，你會發現，撕x的緣由不是由於產品設計不合理，而是業務比較難實現，可是開發的表達又不到位，沒有基於業務邏輯與產品溝通，只是一味地說不行不行，致使過度撕x，影響工做進度。

前端做爲最接近用戶的開發者，有着自然的優點，是第一個能對項目有總體的體驗和感知。而在熟知業務的狀況下，咱們可以對產品設計不合理之處提出建設性意見，甚至對產品設計遺漏的地方作出補充，防止後期方案不斷變動。在咱們對產品說「不行，作不到」的時候，要說出本身的依據、觀點，最好是能基於數據依據這樣的溝通，產品經理也會樂於聽取咱們的意見，促進產品的完善，也就不會輕易出現「根據手機殼顏色實現不一樣的手機主題」這樣的狀況。

於後端而言

前端跟後端的合做，主要就是接口的對接。熟知業務的狀況下，前端如何作得更好？

• 發現潛在的坑與隱藏的業務，及時讓後端同窗補充接口
• 制定接口文檔規範，提升對接效率
• 接口提供時間節點（很重要！防止接口拖延！）
• 數據模擬，提早對接

這裏講一個感觸比較深的點，前端做爲最接近用戶的第一層，但其實也是項目開發的最後一層，後端提供接口給前端的時候，前端還須要對接，才能完成最後的展現，以前由於後端同窗接口各類拖延，致使進度卡在我這邊，不只要加班，還可能背鍋。因此開發前最好跟後端對一遍接口字段，或者讓後端先寫好接口文檔，經過yApi、mock、easy-mock等工具模擬數據返回，提早對接接口，這樣就算後端有任何邏輯改動，也不會影響到咱們對接的進度，有效防止卡進度和背鍋。

於測試而言

當前端與後端對接完成以後，項目基本就要交給測試童鞋來測試了，這時候也是最痛苦的時候，由於咱們須要對本身生產的bug負責。有一些是邏輯錯誤，但也有一些是比較無厘頭的，包括測試童鞋對操做不熟悉而提出來的bug，這種狀況無疑是既費時又下降雙方的工做幸福感，那咱們能夠怎麼作呢？主動提供複雜的交互測試指引。

不少交互複雜的操做，只有咱們前端才知道具體是怎麼操做的，一種常見的交互可能有幾十種實現方式，操做起來也會有細微的不一樣，這時候主動提供操做指引，既能夠提升測試童鞋的測試效率，也能減小咱們處理無厘頭問題的時間，節省雙方的時間。

結語

最好的證實就是行動，前端不只只是會切頁面，寫頁面而已，前端也能在項目中擔任重要的角色，解決技術和非技術性的問題。同時受限於自身經驗，某些方法可能並非最好的解決方案，但願各位朋友多多留言交流。