前言 #
Wells 助教是我在 ALPHA Camp A+計畫的 mentor。Wells 在轉職工程師之前曾任客服中心主管，而且當時就開始自學程式了，從 ALPHA Camp 大航道課程畢業後，順利進入 微碧愛普科技擔任後端工程師，擅長 Ruby on Rails 及 JavaScript。 訪談內容包含了 Wells 助教現職、轉職的經驗以及給轉職者的求職建議，以下訪談內容是用第一人稱及一問一答的方式呈現，盡量保留原話的意思。
現職 #
-
我：請問 Wells 目前公司的架構及擔任的角色是？
Wells：我們是一間小公司，組織架構扁平，以做自己的產品為主，職務劃分沒有那麼明確，基本上碰到問題就是要自己解決。 工程團隊大概是 App 2 人、Web 4 人，Web 有 2 個前端 front，2 個後端，通常一個人會負責 1~2 個專案，不過我們的後端其實是當成全端來做，我的職責是開 API 、部署還有客服。
-
我：開 API 的工作流程是？會有 API 文件嗎？
Wells：在實際寫 API 之前會先看 UI&UX、wireframe 需要哪些資料，並跟前端討論，看他希望畫面怎麼動。 畫面操作時可能有好幾個動作，但可能可以共用同一支 API，這些都需要經過討論才會知道。 再來就是資料的需求，例如註冊帳號要驗證電話，會需要簡訊驗證碼，那這個服務國外能不能使用？可以使用就需要國碼，資料結構也就不同。基本上都是先了解前端的需求後，再去思考要怎麼做，最後寫完 API 後直接用 Postman 產出 API 文件。
-
我：那部署的部分呢？
Wells：部署不外乎就是寫腳本、CI/CD 及自動化部署。我們公司的服務原本是使用 AWS EC2，之後改成 AWA ECS，也就是用 Docker 來做。 剛開始專案規模小，用戶不多也就沒有大量 request 處理的問題，所以根本不需要在意一些架構面的東西像是 Load Balance, Microservices。 但隨著業務量變大，專案就需要調整架構。例如 POS 機有店家、交易、發票等資料要處理，當店家越來越多時，要處理的事情就變多了，程式碼也越寫越長，這支 API 就應該拆出去單獨管理，避免讓程式碼之間相互耦合太嚴重，盡量降低相依性，這樣日後要擴充功能才會比較容易，不然彼此之間綁死就很難修改了。 你可能會覺得那為什麼不一開始就設計大一點的架構，其實道理很簡單，業界實戰首重成本，在用戶數沒有增加、公司沒有實際獲利之前，老闆不可能讓你花錢去搞這些，因此程式的架構都是從小變大。
-
我：客服的部分呢？
Wells：處理客戶遇到的問題，實際上就是查 bug，用 log 追蹤用戶做了什麼事情，檢查程式有沒有照順序跑，如果沒照順序跑就要看是卡在哪裡，過程中也要跟 App 端合作。
-
我：請問專案運作的方式是？
Wells：我們也沒有所謂 PM，其實就是自己管自己，一個禮拜會跟老闆開會檢討一次。通常後端的進度要比前端快 1~2 週，例如前端已經做好註冊頁面，卻沒資料給他，那也沒有用。所以我通常會根據前端的進度，來決定自己要做新的需求，還是維護舊的。 還有一個很重要的是程式碼重構，重構的時機大概有這幾種： \1. 已經預期架構有問題(超前部署)，例如 websocket 一開始只做 100 個 user，但開會時發現 user 現在已經增長到 200、300 了 \2. 過了三個月後(大概)回頭看之前寫的程式碼，自己都看不懂，代表寫得不好，就會重構 \3. 產品的服務超過一定使用率時(server 會寫 warning 寄信通知) \4. server 每天例行的 job 有沒有跑完，request 有沒有掉，或是有問題(大概一週看一次)
-
我：後端工程師的一天是怎麼度過的呢？
Wells：進公司就開始寫 code 啊 (誤 進公司會先規劃今天要做什麼事，評估需要花多少時間，決定事情的先後順序。 通常一進公司業務都會來問問題，所以早上多半是在解決業務的問題，到了下午才開始實際的開發工作，然後快下班時通常老闆會問問題，所以要準備好回答。到了晚上如果有靈感，或是在趕專案，也會寫一下 code。
轉職 #
-
我：從 Wells 的 Medium 文章中得知，你曾經自學過一陣子，你覺得當時自學的困難點是什麼？
Wells：一開始自學技術，你可能會知道「怎麼用」，但要怎麼樣才能把技術「用得好」，你不會知道，你也無法衡量什麼是「好」、所以需要多看別人的 code 和技術文章。 初學者都是這樣嘛，一開始照著教材寫，多練習幾次到不需要看教材也寫得出來，這就真的只是入門，代表你會寫，但不代表你寫的程式能夠運作得好。 這個時期要把程式寫到能讓面試官看得上眼，其實比較困難，因為不僅要跳脫出教材，還要有實用的地方，而且不能看起來像是作業。所以困難點就是要怎麼把之前所學整合運用，還有查閱技術文件。
-
我：常常講到想成為優秀的軟體工程師最重要的是終身學習，Wells 轉職成功後自學的方式是什麼？
Wells：讀原始碼和官方文件。像是很多人用的套件，如果這個套件常常有在維護，就會去看他是怎麼寫的。 例如 passport 是如何處理登入或驗證？常用的東西要去深挖，除了看他怎麼寫，也要思考為什麼他要這樣設計，是為了涵蓋多數使用情境嗎？還是有其他的理由?可以從 GitHub 的 PR 或 issue 去看大家討論的內容。再來就是補足資工基礎像是資料結構和演算法。
-
我：好奇你學習 Ruby on Rails 和 JS 的過程？ 對於學習第二種語言的建議？
Wells：Ruby on Rails 和 JS 都是腳本式語言，所以兩個其實很像。我原本是用 Ruby on Rails 做前後端，後來做前端畫面為了用 Vue 所以學了 JS，之後再延伸到 node.js。基本上第一種語言學得起來，再學第二種就比較輕鬆。會建議先把第一種語言學深，完全搞懂，之後真的遇到瓶頸，例如這個語言無法解決的問題時，再去學別的語言來解決。 然後也要知道語言的優勢和劣勢，最近很流行的 Serverless Computing 像是 AWS Lamda 和 Google Cloud Function，他的費用是依請求數量和程式碼執行持續時間來計算，這時就要選一個消耗記憶體少、執行快速的語言才能降低成本(如 Golang)。
求職 #
-
我：Wells 當初求職時是怎麼介紹自己在 ALPHA Camp 的學習經驗？
Wells：因為不是本科系也沒有相關經驗，而且面試官不見得聽過或瞭解 ALPHA Camp，所以展現學習過程的價值就很重要，例如： 「你為什麼要學」不是在網路上隨便看、隨便學了就來面試。 「你怎麼學」、「你在什麼樣的學習環境」是有架構的學，不是半路出家隨便學。 這些問題都要自己先想過，才能夠回答得好，也可以在合適的時候自己講出來讓面試官知道。
-
我：有些職缺會要求後端工程師懂前端，Wells 認為要懂到什麼程度？Wells：其實就像是我前面說得，在開發過程中要會看 UI&UX, wireframe，知道前端怎麼運作，這樣後端就知道要怎麼配合。 舉個我自己的例子，在串接第三方 API 像是藍新或政府的 API, 就會很直接感受到寫的人有沒有認真在看待這件事情。 Call API 會有成功跟失敗，你有沒有讓使用者知道失敗的原因，以及失敗時該怎麼呈現都很重要。 我曾經串過一支 API，錯誤時會回傳值一個用逗號分開的字串，看起來就是用陣列轉過來的，第一碼代表錯誤碼，我第一眼看到就覺得很 tricky，再來是每個錯誤碼後面的長度又不同，心想這到底在寫什麼，同時也警惕自己寫的時候不要這樣。 錯誤碼正確才能讓前端好串接，再來是資料格式要對，例如傳 0 會變成 falsy，可能導致執行的結果不同，這就要特別注意；也可能 App 端不能吃 null，你還傳 null ，App 端就會認為你在搞他。 所以其實不只前端，App 也會 call API，要知道對方語言的特性，還有他們需要什麼樣的資料結構和資料型別(或是用 GraphQL 讓前端自己決定要帶哪些資料回去也是一種方式)。
萬分感謝 #
非常感謝 Wells 助教在萬惡的補班日下班後還讓我訪談，每個問題都回答得相當詳細，讓我認識後端工程師的工作模式和眉眉角角，能聽到資深工程師分享自己的見解與想法，真的是機會難得，再次感謝 Wells 助教！