前情提要

非本科出身，自學轉行，進入前端業界。聊聊新手上路幾個月以來的經驗，希望可以幫助有類似背景的朋友，對實戰中會遇到的挑戰能先有個心理準備。先說在前頭，以下列出的問題，有些我也還沒有解法，但我相信如果帶著這個前提，知道要往哪個方向找答案、補強哪些部分，可以多少縮短一些摸索的時間。

幾個面向

技術

• 大家第一個會擔心的應該就是技術面，沒用過的套件、工具，但其實技術一直在演變，這個部分我相信即使是有經驗的工程師轉換工作也會遇到。

與人合作

• git：
  glt flow 的觀念，主要的分支、修 hotfix 時的分支等。 另外也會用到一些初學者比較少用的指令，例如 rebase、stash。

• 開發環境有分測試站、正式站：
  code 會先上測試站，沒問題再上正式。需要和後端合作，如果有「會影響使用者操作」的功能，會需要前後端同時上線。

• 看別人的 code、習慣專案的架構、學習團隊的風格：
  自學的時候很少有機會看到別人的 code，新手不太可能一進去就接手重要的功能，可能會從修 bug 開始，這時候就需要找到要改的頁面的「檔案」在哪(哪個目錄)，也要看懂裡面的邏輯，才有辦法改動。

• 公司組織分工：
  PM、業務、前端、後端中間如何銜接。各個角色在乎的點不同，知道對方想要什麼，可以幫助溝通。PM 希望 RD 可以趕快把功能做出來，測試沒 bug；RD 希望有合理的開發時程，PM 開出來的需求技術上可實現、操作流程合乎邏輯；業務希望功能好操作，容易教育客戶、能針對客戶的回饋盡快改善產品。

• 既有的規範：
  專案會有一致的 UI 規範，是團隊長時間逐步累積下來的，但對新進的人來說，在不了解背後脈絡的情況下，要一下子熟悉整份文件，不是件容易的事。

• 清楚描述問題：
  工作中一定會遇到需要向人請教的時候，不管是在網路上發問，或是當面跟人討論，清楚描述問題可以讓別人更知道怎麼幫助你，我要達到什麼目的 → 我的假設 → 我已經嘗試哪些作法 → 哪邊行不通...。

新手比較缺乏跟人合作、做大型專案的經驗，像我一開始光是找 code 在哪裡就要花一些時間，後來也漸漸摸索出自己的方法，找到檔案後，會先小改一下 code，確定改的檔案就是目前看的畫面，以避開改半天其實根本改錯檔案的烏龍。而當要做新的需求時，通常也會拿類似的檔案來改，這時候就會遇到：我要拿哪個檔案來改？到底哪些是會用到的、哪些要刪掉？這個寫法是新的嗎？(同一個專案裡面可能混雜各個朝代的寫法)等問題。

另外，在做自己的專案時，都是一個人搞定前後端，也沒有分測試跟正式環境，會對這個觀念不夠有意識，但這其實還滿重要的，有時候畫面有問題是因為兩個站的資料不一樣(是兩個不同的資料庫)，如果沒有這個概念，就無法重現問題，更別說 debug；或是用來做判斷的條件在測試站適用，在正式站就不正確，我自己就踩過這個坑。

業務邏輯

• 要有辦法跟別人解釋公司在做什麼，客戶是誰、要解決客戶的什麼問題，以及更進一步到我們團隊在做的部分、我自己在做的部分。
• domain knowhow 沒先弄清楚，就很難搞懂 PM 開出來的需求。
• 通常一個產品會有後台、前台，要分別搞清楚每個專案的使用者是誰，2B 的產品後台可能又分為自己公司的後台、客戶公司的後台。

我喜歡在跟朋友聊天時，趁機練習介紹公司是做什麼的，尤其是轉行者如我，身邊的朋友大多沒有相關背景，要用白話文讓別人聽懂(而且不失去興趣 😅)真的需要練習，也可以在不同的聚會中嘗試不同的版本介紹，逐步優化「講稿」。

公司通常都會有 domain knowhow 的文件，但我的經驗是，如果直接讀，其實也不太能夠理解，最好可以搭配上前一點：要幫客戶解決什麼問題－試著把自己放在客戶的位置，去想像客戶會遇到的問題，有助於理解 domain knowhow；人腦喜歡聽故事，有故事性(前因後果)，理解起來就會比較快速。

聽不懂別人要幹麼、我的反應好慢、我是工程師嗎？

• 去習慣一些慣用說法：「打」API，「進」開發，「上」版，「吃」到值...
• PM 開了需求，也給了大概的畫面，但我還是覺得模模糊糊...

可能因為以前的專案都是自己發想的，流程也比較簡單，在實戰中會缺乏「將需求轉化成功能」的敏銳度。前端要做的事情通常可以劃分為兩大部分：畫面以及資料流，可以練習把大概的畫面及流程畫出來，然後逐步拆解，到自己可以在腦海中掌握整個流程：進到這個頁面時，畫面長什麼樣子？我需要拿到什麼資料？要判斷什麼？要記錄什麼？要送什麼資料出去？頁面跳轉的順序？等熟悉之後反應就會越來越快。

一些心得分享

心態

• 不要被 junior 的身份自我設限。
• 抱著「我就是要把工作做好」的心態，只要是覺得對自己工作有幫助的事，就開口詢問。
• 以開放的態度看待他人的回饋，甚至主動尋求他人的回饋。
• 接受自己的不足，一開始的挫敗是難免的，反應比有經驗的人慢，底子沒有本科系的人紮實，都是正常的，把握機會學習才是重點。

身為 junior，不知道大家會不會跟我一樣，習慣去腦補：才剛進來是不是不要意見太多？不要亂問問題？講求輩份，報告時習慣讓 senior 先報告...等等。但我自己的體會是，這種自我設限會限縮自己成長的速度，試著多參與，一方面會讓別人把你視為團隊的一份子，同時自己也會比較快融入團隊。

舉個尋求他人回饋例子：團隊的 leader 要離職前，我請他給我一點建議，也向他提到：我覺得工程師是個比較沒有「正回饋」的工作，因為功能做完後，如果沒問題，只會默默上線，有問題才會收到 bug 單 😂。leader 給我的建議很棒，他說他會把自己做的畫面操作給 PM 看，跟他說：「怎麼樣？不錯吧？」順便跟 PM 提出調整的方案等等。

另外，人很難不去跟別人比較，但如果沒有真正理解到所有的能力都需要時間培養、不足是正常的，就會陷入負面情緒。接受事實，正面看待「可以被比自己厲害的人環繞」是很棒的事，會比較有信心面對每一天的挑戰。

跟以前工作不同的地方

• 流程導向 vs. 目標導向：

以往的工作大都有一套標準作業方法，當然可以透過優化 SOP 來追求更高效率、更低錯誤率，但中間的流程不會有太大的變動，這件事本質上跟工程師的工作很不一樣，工程師的工作比較是：先列出最後要達到的目標，中間要用什麼方法是很有彈性的，甚至目標本身都可能會不斷調整。

• 每一步都走對 vs. 逐步優化：

其實這也是學 coding 以來對我的一大衝擊，我已經很習慣一次就把事情做對、做好，但是這個習慣對 coding 反而是一大阻礙，沒有人是一行一行打字般的從上到下寫好一份檔案，而是：描述問題 → 簡化問題 → 嘗試 → 修正，如果追求「下筆時」每一行 code 都要全對，反而會讓人不知如何動手，這也是我覺得 coding 有趣的地方。

另外，先打通大環節(整個流程)，再解決小問題－畫面調整、加入防呆，這種先有大綱，再把每個細部做好的方式，也是一種逐步優化。

• 加入一個變動中的團隊：

以往加入一間公司時，通常公司已經到穩定期，工作內容也很固定，就是需要一個人來填補這個位子；但在軟體界比較有機會加入一個變動中的團隊，這邊說的變動，可以是產品本身在變，還沒上線，還不穩定；可以是團隊成員的變動；也可以是標準作業流程的變動，因為各種因素(時間、人事)所以還沒走到一個穩定期，要有心理準備，試著去習慣各種改變。

• 珍惜、重視過程：

過往的經驗讓我很看重產出與結果，但 coding 中，讓我體會到過程其實是更重要的－研究了好幾個小時別人的寫法，一行 code 都沒寫，看起來好像沒有產出，但實際上就是產出前的必要過程。debug 時檢查了 A，B，C，都沒有解出來，但是最後是改了 E，code 就可以跑了，如果沒有前面做的 A，B，C...，也不會想到 E 其實才是問題所在。在前往 senior 的路上，如果沒有前面菜鳥時期的累積，就不會有成為 senior 的一天。

感謝收看

轉職是我人生很特別的體驗，我用記錄的角度，蒐集一路上遇到的難題以及體會。也希望以上的分享可以幫助到跟我有類似背景的人，在正式開始上班時少一點恐慌，多一點確定感，enjoy the ride。

有任何想法都歡迎跟我討論 😃，在Linked可以找到我。