開發前溝通清楚所有細節，包括和產品對需求的溝通、和後端開發對接口和數據格式的溝通。

這裏特別要說的是和後端的溝通，最近好幾次提測之後，才發現犯了一些因為和後端沒溝通好字段導致的低級錯誤。比如今天的字段的值的問題，本來為空時需求要求前端渲染顯示‘／’，而後端給前端返回的是null。後端也沒有事先給前端說這個null就代表要顯示的‘／’，當我看到後端返回的null的時候，以為除了‘／’以外還會顯示另外一種情況——什麽都不顯示（這裏我腦子裏疏忽了產品給的完善的原型圖，原型圖裏面並沒有體現頁面上有空值的情況，只有顯示數據值和‘／’的情況）。

開發前作為前端我沒有事先去和後端溝通這個值的問題：後端會怎麽處理這個‘／’值，是應該前端處理還是後端直接返回這個‘／’給前端渲染。然後就直接按照自己的思維慣性，以為後端會返回‘／’和null這兩種情況去寫了邏輯。

我總是以為這種數據就應該後端弄好需要的格式直接返回給前端就好，這是後端的責任。當我知道後端使用的go語言對類型要求很嚴格，不像js這種弱語言，定義一個變量支持多種不同類型的值賦值，我才知道我這種按照以往經驗來定義當下做的事情的思維方式是多麽可怕。

做事之前的溝通確認一定是必走的一個環節，每一個實現的細節在做之前應該都是想清楚了邏輯的。後端在接口文檔中沒有詳細的文檔說明，給的mock數據格式和渲染需要的數據格式不一致時，停下來想一想，我想要的數據後端mock數據中怎麽沒給。做為前端一定要主動去和後端確認好接口的使用。

總之，開發前前後端一定要先溝通清楚接口的使用，確保兩個人對接口的使用的理解是一致的，開發前解決掉這個問題可以減少5%的提測之後的bug量。還需要說的一點是，當後端更改開發語言的時候，前端如果對這門語言不了解也是有必要去簡單了解一下的。

目前公司用的go語言不同於之前的php語言，前者屬於靜態強類型語言，後者屬於動態弱類型語言；前者在編譯階段類型就已經確定了，而且定義的變量類型不能再切換，而後者屬於動態類型弱類型語言，變量的類型在運行時確定，定義之後的變量還可以切換類型。這也就是為什麽後端使用php開發的時候可以在給同一變量賦值不同類型的數據，而在go裏面只能統一賦值一種類型的數據的原因。

溝通協作：避免犯低級錯誤，開發前溝通清楚所有細節