1.1　為什么你總是下不了班

如果你是一個(gè)初級前端開發(fā)人員，很有可能并不知道Mock.js是什么技術(shù)，我們先拋開對技術(shù)的理解來看看一個(gè)初級前端開發(fā)人員的工作具體包括哪些內(nèi)容。一個(gè)任務(wù)被拆分為前端和后端兩個(gè)部分后，前端和后端開發(fā)者通常會先商議接口細(xì)節(jié)并編寫相關(guān)文檔，然后團(tuán)隊(duì)的成員就會開始自己的編碼工作。當(dāng)前端開發(fā)人員寫完頁面靜態(tài)部分的代碼時(shí)，后端開發(fā)人員很有可能還沒有準(zhǔn)備好后臺的接口。這種情況下，團(tuán)隊(duì)的項(xiàng)目經(jīng)理往往會要求前端開發(fā)人員先使用虛擬數(shù)據(jù)把頁面填充起來看一下效果，調(diào)整一下樣式，等到后端開發(fā)完畢后再進(jìn)行聯(lián)調(diào)，這也是非常合理的。對此，開發(fā)者通常都會選擇如下幾種處理方式。

• 將數(shù)據(jù)直接寫在所使用的代碼段附近，等后臺的接口開發(fā)完畢并進(jìn)行聯(lián)調(diào)之后再來修改。這是初級前端開發(fā)人員最容易想到也最常使用的方式，雖然選擇這種方式本身并沒有什么問題，但可以確定的是，將來重構(gòu)代碼時(shí)的工作量將會非常大，因?yàn)樾枰謩?dòng)改寫每一段虛擬數(shù)據(jù)，將它們的獲取方式改為從后臺請求。這里還需要注意的一點(diǎn)是，數(shù)據(jù)的返回是異步的，如果依舊像對待靜態(tài)數(shù)據(jù)一樣來編寫代碼，那么很有可能后續(xù)的邏輯會在獲得數(shù)據(jù)之前先被執(zhí)行，這時(shí)得到的結(jié)果往往不是自己所期望的，而初級前端開發(fā)人員卻不能理解到底發(fā)生了什么。
• 將需要的數(shù)據(jù)寫入JSON文件，從本地引用或請求。稍有經(jīng)驗(yàn)的前端開發(fā)人員會更容易接受這樣的方式，相對于前一種方案而言，它的“侵入性”更小，虛擬數(shù)據(jù)可以保存在獨(dú)立的文件中，像普通模塊一樣被引入，在聯(lián)調(diào)結(jié)束后將其移除即可。但以這種方式引用的數(shù)據(jù)仍然是同步獲得的，而聯(lián)調(diào)階段需要對接的是后端開發(fā)人員提供的接口，它是異步返回?cái)?shù)據(jù)的，如果聯(lián)調(diào)過程不順利，則很有可能還需要在虛擬數(shù)據(jù)和真實(shí)接口之間來回切換，那么這種方式的協(xié)作效率問題就會暴露出來。例如，聯(lián)調(diào)時(shí)發(fā)現(xiàn)接口出現(xiàn)問題，在后端開發(fā)人員修復(fù)的這段時(shí)間內(nèi)，前端開發(fā)人員自然也需要做一些其他工作，而不是一直等待?？墒?，聯(lián)調(diào)階段的代碼已經(jīng)改成前端異步請求后端數(shù)據(jù)的方式了，后端的接口一直報(bào)錯(cuò)會導(dǎo)致前端的整個(gè)頁面白屏，為了修復(fù)與用戶界面（UI）相關(guān)的其他問題，前端開發(fā)人員又不得不將代碼改為使用虛擬數(shù)據(jù)的方式，因此通常只能先把寫好的請求代碼小心翼翼地注釋掉。另外，頁面使用的虛擬數(shù)據(jù)很有可能需要前端開發(fā)人員手動(dòng)準(zhǔn)備，面對數(shù)組或是嵌套結(jié)構(gòu)較深的對象，手動(dòng)準(zhǔn)備這些測試數(shù)據(jù)也會消耗大量的時(shí)間。
• 等待后端開發(fā)人員開發(fā)完畢后提供接口。這種方式的確會比較省力，但潛在的風(fēng)險(xiǎn)卻很大，因?yàn)榍岸碎_發(fā)人員不得不面對這樣一種可能，并非每一位合作的后端開發(fā)人員都是專業(yè)且友好的，如果他提供的接口一切正常，那自然是皆大歡喜，前端開發(fā)人員只需要進(jìn)行一些字段的檢驗(yàn)和調(diào)整就可以宣告聯(lián)調(diào)成功了。但如果與你合作的后端開發(fā)人員恰好是位新手，那么聯(lián)調(diào)的過程可能就會變成反復(fù)刷新頁面、協(xié)助測試接口、抓取請求log_id等無聊的工作。可能幾個(gè)小時(shí)下來，你除了不停地刷新頁面以外，幾乎什么進(jìn)展都沒有。如果與你配合的后端開發(fā)人員比你更有話語權(quán)，或者恰好是你的領(lǐng)導(dǎo)，那么他們極有可能會坐在你的電腦前進(jìn)行各種調(diào)試，而你盡管有其他任務(wù)在身也只能耐心等待。最終的結(jié)果就是，你需要寫很多額外的代碼來解析和重組后端返回給你的數(shù)據(jù)，甚至還有可能因?yàn)閿?shù)據(jù)結(jié)構(gòu)的變化而導(dǎo)致前端的整個(gè)邏輯需要進(jìn)行重構(gòu)。最后，別人的工作都做完了，你卻不得不留下來加班。

你為什么總是加班？開發(fā)經(jīng)驗(yàn)的欠缺只是原因之一，更重要的解決方法是，我們需要學(xué)習(xí)在團(tuán)隊(duì)作戰(zhàn)中如何高效地完成自己的任務(wù)，以及如何更有效地與他人合作，這從來都不是一個(gè)靠妥協(xié)和忍讓就能解決的問題。工作流程的優(yōu)化對任何團(tuán)隊(duì)來說都是一件重要但不緊急的事情，你可以置身事外等待隊(duì)友來處理，也可以躬身入局自己來推進(jìn)問題的解決（并不是讓你獨(dú)自一個(gè)人來實(shí)現(xiàn)的意思），而后者不正是我們作為軟件工程師的本職工作嗎？