跨部門與共同協作之經驗

培訓計畫接近尾聲，回首數算一下這六個月我遇到的功能與需求，內部專案是開發給面試者使用的測試網站，有前台與後台的開發，兩者有滿大的不同，簡單紀錄一下改變我前端轉戾點的階段：

看懂規格書

在這裡的第一個專案有完整的開發規格書可以看，真的非常幸福，但也僅此於這次(哈)，有圖文並茂的流程說明，清楚的 API 開發文件，前後端要定義的屬性名稱與類型都固定好，在開發上有個共同依據。

UI 協作

前台有跟 UI 設計師合作，UI 會交付切好的靜態網站，使用的技術需要看專案而定，然而前端工程師切版基礎要會的手刻能力外，CSS 框架也一定具備一個，如果不知道要先掌握哪一個的話，推薦可以先掌握最多人使用的 Bootstrap，而要把 UI 切好的版面陸續放到前端框架內（當時培訓是使用 Angular），套好版後就去串接 API，此時會發現如果有 UI 切好版會省下許多切版的時間，而且版型也都很好看。

Git 版控

再來就是多人協作經驗，有用功能分類、也有用頁面分類的，這個就要看專案需求而定，沒有一定的規則。而多人協作基本的 Git 指令操作就很重要，最常用的就是那幾個，如果是多人協作一定不要貿然的合併分支，建議要再三跟共同協作的工程師確認後再進行合併，畢竟解麻煩的衝突真的是很累人的事情。

後端溝通

這算是第二個大魔王，因為後端沒有畫面，只能按照資料流或是架構來想呈現的結果，而前端因為有畫面，有時候會跟後端想像的不同，又這次前後端開發團隊都是參加培訓計畫的同學，所以我們都「一樣菜」，來回溝通的內容有時候是非常「不專業」，但其實大家很努力的想把功能完成，所以就算有些意見不合，稍微有點火藥味，但大家共同的目標其實就是想搞懂功能並將其實作完成。

學到的是可以把畫面截圖給後端知道會呼叫 API 的地方有哪些，若呼叫 API 有問題時，也要把 console 或 network 的資料傳給後端，並附上陳述的文字，可以讓後端更明確知道前端的問題是什麼。

提問前先檢查前端有沒有問題

人在遇到問題時，都會想先找到答案，尤其是在工作上更是，但工程師應該要先檢查自己的部分，比如說串接 API 時應該先檢查狀態碼，確認資料呈現是否正確，或是哪個環節出錯而無法顯示，若有需要用到 post 方法給後端，如果是狀態碼是 400 或 403 要確認一下是否送出的資料有不符後端所需要的欄位。

狀態碼 500 跟 CORS 可以直接問後端。

資深也是從資淺來的

除了技術面能力外，商業邏輯也是需要學習的重要環節之一，在開發過程需要考量到使用者體驗的操作，前端工程師新手對於這塊不用特別厲害，但要判斷是否合理，可以把自己當作是一個普通人來看自己的開發功能，這樣在開發時可以更貼近使用者的角度做出更好的操作流程。而我都會把每一次的學習記錄下來，什麼方式都好，下次遇到一樣的問題，能夠幫助自己的就是好方法。

如果專案當中有資深工程師可以分享技術或是願意回答問題一定要把握機會，並且要整理好問題提問，不要都沒準備就問，只會浪費彼此的時間，而且透過跟資深工程師的合作，成長的速度真的會很快。我個人覺得是思考模式帶動了技術的成長，有好的思考模式，才知道用什麼技術跟方法解決問題，然而資深工程師就是遇到了許多五花八門的需求，造就了現在的能力。

專案開發有跟資深工程師一起開發的時候，是最好學習的機會，因為專案是要上線運作的，所以追求的一定是要正常運作且可讀性高的程式碼，此時可以向資深工程師多討教，若可以在專案每週建立一個 code review 的時間，聽聽資深工程師怎麼開發跟解釋所撰寫的程式碼，且也透過說明來分享自己的程式碼與開發思維，再藉由資深工程師給予建議修改，這段時間真的會進步得很快，因為看了資深的程式碼，對自己也是一種學習。

曾經一起協作的資深工程師說，前端就是不段的學習，讓自己保持成長的動力，並且有坑就跳進去，只要活著爬出來就是成長了！

慢慢努力，一點一點的累積，並且樂意去分享當作輸出練習，會發現回頭已經走了很長的路。

你起初雖然微小，終久必甚發達。約伯記 8:7