前端KM - 在新手期如何跟上專案

在剛轉職成前端工程師後，加入公司拿到電腦後
以下為自身經驗歸納可朝下面三面向準備：

1. 專案環境建立
2. 專案協作流程(git, git flow, code review 等等)
3. 專案開發流程(框架, 套件等)

專案環境建立

就以本身自己是拿到 MAC M2 air ，就立刻根據自身開發需求進行工具安裝
（如果沒有想法也可以參考這一篇 Mac 前端開發環境安裝）

後續再跟據 專案需求 使用 npm / yarn / pnpm 等等

值得一提的是 在公司中可能會處理到多年前專案
因此問清楚目前專案 node 版本是一件非常重要的
如果沒有問清楚 可能會繞了非常多的路 光要將專案run起 就快要吐血

這邊就推薦使用 nvm 這套 node 版本控制工具

可以在 Terminal 使用以下指令

nvm ls // 查看目前已安裝及使用版本
nvm install {對應版本}  // 安裝對應版本
nvm use {對應版本}  // 使用對應版本

透過上述指令可以快速安裝及切換使用版本
也避免繞更多遠路

當然如果公司有文件就可以避免這樣的事情發生XD

---

專案協作流程

將專案能在本地 run 起之後，可能會以為是從解 Bug 開始
但比起解 Bug 更重要的事 - 了解工作協作 git flow

每一個開發團隊都有自己的開發方式
也就會有對應的 git flow

以自身團隊來說 會分成 master dev sit uat feat-XX hot-fix 等分支

master  // 代表目前產品運行分支
hot-fix // 發生營運問題修正測試分支 從 master 拉出
dev // 開發環境主分支
feat-XX // 開發修改個別功能 從 dev 拉出
sit // feat開發完成合併至dev 前端運作無誤後 再合併至 sit 交付給 QA 測試 之分支
uat // QA 測試後 bug 修改完成 交付給 客戶 運行分支

最後再透過 比較 前後版本 uat 將其程式碼更新至 master

就可以完成一個完整的專案開發

其中特別要注意的點：

1. 要 push / merge 程式碼時，先繼續 pull / fetch 目前分支進度，若發生conflict 可在本地先處理，
   若沒有用 pull / fetch 則容易遇到 git檔案差異 導致不知如何解決
2. 如果遇到 conflict 時請用 rebase / merge 解決，千萬不要便宜行事 使用 merge -f 或是 revert ，
   前者會將之前 git flow 歷史紀錄覆蓋， 而後者更可能導致版本混亂、導致無法查明檔案差異。

---

專案開發流程(專案使用套件, code-style)

在了解團隊開發 gitflow 後，通常第一個接到的小任務是
去改一些小bug 或是 去開發一些與產品不直接相關之功能

依稀記得 第一個接到的任務是 去將某一頁表單頁面更換其選項文字內容

在當時 就心急想求表現，就立刻犯了錯誤，被同事說到，記得看一下其他功能怎麼寫，
要符合專案相關 code-style ，因為自身專案是有支援 i18n 多國語言，
所以會有語言包相關檔案，而任何出現 字串文字 內容應該都放在其語言包，
而不應該存留在個別功能檔案，且要了解其功能位階，才能避免重工及造成衝突。

此外也有一些 套件上使用的選擇
例如專案團隊是使用 redux-saga 作為 API 串接，
且因為要方便管理，利用檔案夾分層 以及 利用 selector 來取得全域變數，
雖然會導致 每次串接 API 時，需要在四個檔案(action, saga, reducer, selector)分別寫上對應的 code ，
使得開發速度會受限制，而目前可能有更新更簡潔的寫法，
但需要考量團隊開發人員的技術是否有跟上，或是是否有時間可以開分支導入，
因為每一項新套件、新技術都需要花時間以及相關人員的訓練，
此外也要考量後續人員的便利性，若導入一冷門技術，後續無人維護就得不償失了。

以上就是我到職三個月的心得，很開心能與大家分享轉職前端工程師這條路的所見，
希望未來還有更多機會可以分享，謝謝。