本文大約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等。
總結一下
溝通非常重要，產品經理不要慣著甲方，專案經理不要慣著產品經理，前端不要慣著設計。
答應我別做舔狗好嗎。