前端開發工程師避免加班的可行方法

本文大約2500字，看完本文大概須要10分鐘，若有錯誤，請指正。

這篇文章其實不能說是怎麼避免加班吧，也不是教大家如何偷懶，就是我的的一些經驗，如何高效的利用上班時間，讓你在上班的時候就幹完活了，來減小加班。我會講述一個項目從立項到上線每一個階段中前端的職責和如何更加高效工做。

產品

通常產品會把產品需求整理出來以後，會讓有關人員一塊兒開項目啓動會，告訴咱們要作什麼了，這時候前端就要密切關注產品經理的動向。

爲何要開這個會呢，我相信在座的你們通常都是乙方公司比較多(外包，定製化的需求，等一些作saas系統，包括一些大數據平臺公司)，對於甲方提出的需求，由於有些產品，他不是很懂技術，由於某種緣由，答應了甲方的某種需求，你就須要結合實際狀況，告訴產品，我作這個東西，難度如何、須要協調哪幾個部門、大概要多少時間，甚至是作都作不了的狀況。例如，導出一個幾十萬數據的需求，聽起來很簡單，作後臺的就知道可貴一批，好比你去知網查重一篇論文，知道爲啥要等好久嗎，知道爲何不是你一查重就能導出查重數據嗎？多說一點，產品要有能力去判斷作出這個需求帶來的價值，要能計算出這個需求所帶來的價值比。還有一點就是，需求不要只把功能作出來就好那麼簡單，而是你作出來，有人以爲好用了，而且付費購買了你的產品，纔是真牛逼，就好像不少廣告，瞎起標題，你一點進去，三秒就進入聖賢模式了，那不是白乾一場了嗎，作了還不如不作。因此，產品牛逼，開發確定沒那麼累，加班確定次數會少一點。

還有就是，需求確立以後，我就沒見過不改需求的，有些是被砍掉的需求，那固然是最好，還有一些是修改的，還有就是一些增長的，這是比較麻煩的。儘可能持續關注產品，當他說出，此次改完不再會改了，改了的話就放到下一個版本上，你才能放心。

而後就是跟前端比較切合的，意淫大法，通常需求出來的前兩天，你的任務仍是比較輕鬆的，這時候能夠搭個架子，或者用之前搭好的架子，而後對着交互圖或者原型圖，大概的寫一些頁面佈局，邏輯等，爲後期省時間，別在那瞎等設計圖。

跟後端約定接口，確立字段

這個比較簡單，就是約定接口，是get 仍是post仍是delete等，後端返回2000是什麼意思啊，本身協商一些自定義返回信息，你前端要什麼數據，讓後端給你，就是先後端銜接起來，防止將來你作完，後端改數據，你前端也要跟着改，好的公司，後端不但會給你字段，而且有詳細的api文檔，甚至有一個mock環境，你根本不須要考慮數據問題了，開發起來不要太爽，還有就是差一丟丟的，有字段，有文檔，本身前端mock數據，我也有寫過相應的mock文章，網上也有相似mock的在線工具(要備份好)，而後先後端都開發完聯調一下就行了。最重要的就是，必定要讓api落實到文檔上，後期好維護，開發的時候也減小了低效的頻繁溝通(有些開發很討厭寫代碼的時候老被打斷思路)。

設計

切勿讓設計佔用太多時間(按計劃時間)，爲何這麼說呢，由於項目經理給的時間是死時間，好比說客戶下個月1號就要用到這個功能，你這個月15號才項目立項，設計就花了你十天，你開發+測試也就只剩下5天時間，因此，各個部門要並行執行，邊設計，邊開發。 設計通常是須要挺長的時間去出設計圖的，你要跟設計說好，我要作移動端哪幾個頁面，或者哪幾個組件先給我出設計圖，由於設計是不知道你是先開發哪一個頁面比較順手的不是嗎，設計師出完圖，不要立馬發給前端工程師，拿着設計圖，去找產品經理，我這圖您以爲怎麼樣，產品經理點頭以後，再給前端，前端收設計圖的時候必定要問設計，產品看過這圖沒，防止設計亂改圖，亂拋鍋給你，這裏核心就是，千萬不要讓設計帶你節奏，主動權掌握在本身手上。

設計圖出來後，跟以前寫的邏輯結合。

這個就是初級前端、中級前端、高級前端都會作的事情。切圖，上邏輯。可是作出來的效果卻不太同樣，我這裏說一下，不要拿着ui死磕，要考慮不少ui沒有展示出來的狀況。常見的例若有是否居中，比例怎麼樣，文字超出的狀況。頁面顏色，字體。手機兼容性，例如劉海屏，全面屏幕(設計師壓根不會給你設計這些手機，仍是按照i6的格式)，滾動加載仍是上拉加載，節流，頁面渲染性能，甚至是一些用戶體驗的地方，還有一些就是經驗的問題了，只能慢慢去積累，經驗到了，開發的速度就快了，第二點就是，有一些效果或者特效，作的成本高，實際上是能夠跟設計大佬們協商的，可能人家只是一時衝動想搞搞新玩意，並非特別適合用在本項目上，也有一些狀況只是設計的無意之舉，在前端實現來看卻難到不行的狀況。

聯調

我以爲聯調其實就是自測的一種，保證產品的可用性，也防止一些後端偷偷的改了接口沒跟你說，這時候你就能發現了，通常聯調是算在開發裏面的時間。

測試

通常分爲test,beta階段,test和beta其實只是不一樣的環境，爲何要搞多個環境了，由於中型一點的公司，產品都不止一個，每一個站，互相關聯，又不一樣域名怎麼辦，登錄一個系統全部的系統都自動登錄那就要有sso了。舉個簡單的例子，例如test環境只能夠容許跨域，走的只是http協議，可是beta就不能夠跨域了，還升級成https的協議了,你在test好好的，到了beta就發現不行了,因此這是有必要的。在這裏前端須要去跟後端甚至是運維協商,如何配置靜態路徑，如何配置路由,保證應用的安全性,再根據商量出來的結果寫各類環境的配置文件了，例如會用到gulp webpack等。 這點很重要，否則你切環境花費時間，測試是會停滯不前的，必定要和運維要協調好環境相關問題，跨域啊，http htpps、集羣之類的相關問題，不要每次當前環境測試好好的，一切換到別的環境就gg，我的以爲測試的時候只能在配置環境上節約時間了。還有就是儘可能把問題暴露在測試階段，儘可能少在正式環境出bug。雖然我一直說擠時間，可是在這個階段，節奏應該是放慢的時候，不要趕時間，沒測試好就說測好了。

項目驗收

測試邏輯經過後，就表明這個項目是可以使用的了，立馬進入項目驗收階段，分爲設計驗收(是否按照設計圖的顏色值，邊距值，響應式，適配等)，產品驗收(按照需求文檔，一點一點的過)，運營或者需求方(老闆)驗收，爲何要這樣作呢？由於能夠避免之後被拋鍋。

上線

這一步已經表明這個項目快要完成了，按照上面的作法，估計仍是有充足的時間的，最後 ，再看看有沒有bug,其實在這裏前端犯錯的概率就很小了，就算是有bug出現，通常也只是影響體驗的bug,至少功能是正常的。例如，我曾經就遇到過，在beta環境好好的，一切到正式環境，有一些地區的用戶訪問不了，有一些卻能夠，這種百分之90是服務器運維那塊地問題。上線這部分前端通常都是考慮瀏覽器緩存那塊，還有靜態資源上傳到cdn，就是如何讓頁面快速呈現到用戶眼裏。固然若是用戶羣體很大的話，能夠選擇較少人使用的時間段去發佈等。

監控

通常經過埋點來監測系統的一些加載問題，異常報錯，用戶行爲等數據的收集，例如谷歌的一些api performance onerror等。

總結一下

溝通很是重要，產品經理不要慣着甲方，項目經理不要慣着產品經理，前端不要慣着設計。

答應我別作舔狗好嗎。