前言
Hi 大家,我是 Central Team 的 TECH FRESH - Morrison Hung ,很高興有機會可以跟大家分享 LINE TECH FRESH 的實習生活以及在這邊學習到的一些開發方 法、流程,接下來就讓我為各位帶來一場我自己認為堪稱烏托邦的實習經歷吧!
簡報:https://speakerdeck.com/line_developers_tw/utopian-journey-my-ideal-internship-experience-at-line
What is Central Team
首先,在開始之前想先跟大家介紹一下 Central Team 是甚麼樣的存在;在整個 Engineer Team 中,有一個團隊叫做 Central team,因為 LINE 內部有許多的商業需求一直萌芽,但在專案初期時可能還沒辦法有固定人力支援,因此這時候就是 Central team 出場的時候了!可以從中加入專案,去協助與提供開發支援,讓商業需求可以被實現出來。
其中經常接觸的專案類別為以下:
- AD 廣告相關
- LINE 官方帳號
- 開發共用 SDK
- 各式各樣活動/商業網站
詳細的話也可以參考這部影片!
A Day of LINE
在每天的生活中主要可以分為三個部分,分別為早上的 Code Review 與 Daily Meeting 時間、快樂的中午實習生午餐聚會 with 飛鏢時光,最後則是下午的 Coding 及各式各樣的讀書會 Workshop Time
在早上的時間裡,通常我會邊吃早餐邊看一下團隊中有沒有需要協助 code review 的地方,多讀別人的程式碼學習一下每個人的開發方式,也當作讓大腦 warm up ;沒有的話就會將昨天做的東西整理一下以便待會開會時回報,在 daily meeting 的過程中通常是我們團隊的進度同步時間,會依序報告自己昨天做了什麼,有沒有遇到什麼問題,今天預計做什麼等等,這個時間也會討論一下彼此現在工作上遇到的問題,可以實作的解法
接著開完會後就會整理一下會議內容,準備去吃午餐!因為實習生們一週通常只會來三天,但我是一週五天都會來的全職實習生(沒錯,只要你有辦法安排好學校進度,是可以五天都上班的!)所以每天上班時的實習生都不盡相同(不變的是都會射飛鏢當作飯後運動哈哈),有一種天天跟不同團隊吃飯的感覺XD
吃完午餐後,下午時光則是以那天的活動有什麼為主
內容涵蓋了
1. D.O.T (Dev Open Talk): 這是一個每月一次的全體工程師月會, CTO 會與我們佈達總部的相關政策與未來發展方針,偶爾會有部門分享自己近期做了什麼,或是開發時遇到什麼坑,讓同伴可以借鑑;最後則是有匿名 Q&A 環節,會有人詢問公司大大小小的事,再由相關的人來解答
2. Study Group: 在工程 師團隊中會有很多人組成讀書會,我們會選擇彼此感興趣的主題,例如前陣子有針對 React Design Pattern (https://www.patterns.dev/react/) 中的內容,做成簡報後互相分享,讓我們有機會接觸更多平時工作外的領域,增廣見聞,也可以將別人分享的內容帶回團隊中實際使用,是個很好的學習機會!
3. Workshop: 這是一個不定期會由不同工程部門舉辦的技術工作坊,內容涵蓋 DevOps 、 DSML(Data Science and Machine Learning)、 LangChain 等,在工作坊中會有一系列相關分享圍繞在主題上,藉此讓大家知道部門的研究成果,多元接觸不同領域知識
4. Coding: 如果當天沒有什麼活動的話,就是一個樸實無華的 Coding Day ~
How We Work
在我們的團隊裡,我們基本上是照著上面的流程來開發和部署我們的應用,這個流程可以分為以下幾個步驟:
- 將我們寫好的程式碼 push 到 GitHub 並發 PR
- GitHub Actions 會自動觸發執行測試,再透過 SonarQube 分析程式碼,並生成測試結果和程式碼覆蓋率
- 團隊內的其他人會針對程式碼進行 Code Review 和進一步測試
- 如果檢查和測試通過,則將程式碼打包成 docker image 推送到我們自己的 Harbor image registry
- 更新應用的 docker image 為最新版本,並修改相關 Kubernetes manifest
- ArgoCD 會監聽 manifest 中資料,如果有變動的話就會將新變動 apply 到 Kubernetes cluster
- Kubernetes 會從 Harbor 上 pull 相關的 image 部署到 Kubernetes cluster 中
- Grafana 蒐集相關 metrics 以便觀測應用的相關資料
About Version Control
看完剛剛的開發流程後,想再跟大家分享一下關於版本控制的相關經驗
在傳統的開發中,常常會使用 Git Flow 來當作一個結構化、可控的版本控制流程。它提供了一個清晰的指導,幫助開發人員管理新功能的開發、版本的釋出以及錯誤的修復。
Git Flow 定義了五個主要的 brach:
- master:生產環境的程式碼
- develop:開發中的程式碼
- feature:開發新功能的分支
- release:準備釋出的版本
- hotfix:修復生產環境的錯誤
我們可以根據這些分支來進行工作。例如可以創建一個 feature 分支來開發新功能。當功能開發完成後,可以將其合並到 develop 分支。最後可以創建一個 release 分支來準備釋出版本。
不過在現今產品快速迭代的日子裡,如果使用 Git Flow 的話反而可能因為有太多的 branch ,而造成分支管理混亂,並增加錯誤的可能性(merge hell),更不利於快速迭代開發
因此 TBD (Trunk based Development) 因應而生,它是一種更現代化的開發流程,專為快速迭代的產品開發而設計。
在 TBD 中,所有開發人員都在同一個分支(稱為 trunk 或 main)上進行工作,並頻繁地提交更改。這種方法強調了頻繁的提交、短期的分支以及快速合併,讓每一次的更改都相對小且容易管理,以降低複雜性並提高軟體的品質。
項目
|
TBD
|
Git Flow
|
---|---|---|
分支管理 | 只有一個主分支 (trunk) | 五個分支:master、develop、feature、release、hotfix |
新功能開 發 | 直接在主分支上開發 | 在 feature 分支上開發,完成後合並到 develop 分支 |
版本釋出 | 從主分支直接釋出 | 從 release 分支釋出 |
錯誤修復 | 在主分支上修復 | 在 hotfix 分支上修復 |
關於 TBD 的詳細內容可以參考文章(https://trunkbaseddevelopment.com/),或是掃描簡報中的 QR Code 也可以~
這時候可能有些人會有疑問,就是 TBD 講求快速的提交程式碼,並快速的合併到 trunk 上,這樣如果有些功能還沒開發完的話該怎麼辦呢? 這時就輪到 Feature Toggle 發揮作用的時候!
Feature Toggle 顧名思義就是一個可以隨時開啟或關閉特定功能的開關。它是一種程式設計技巧,讓我們可以在不改變程式碼的情況下,動態的切換軟體的行為。這種技巧在 TBD 中扮演了非常重要的角色。
我們可以使用 Feature Toggle 來控制 feature 的可見性。當一個新功能還在開發中時,我們可以將其對應的 toggle 關閉。這樣即使新功能的程式碼已經合併到主線上,使用者也看不到這個新功能。只有當新功能開發完成,並且通過了所有必要的測試和驗證、開啟 toggle 後,使用者才可以看到功能的發佈。
Feature Toggle 不僅可以控制新功能的可見性,還可以用於進行 A/B 測試、 canary release 等複雜的部署策略。通過靈活的使用 Feature Toggle,我們可以更好的控制程式的行為,並且加速開發速度。
關於 Feature Toggle 一樣可以參考這邊( https://www.slideshare.net/MilesChou/2019727-branch-feature-toggle )或是簡報內 QR Code ,詳細的 Example 也可以參考正職大大的這篇文章( https://techblog.lycorp.co.jp/zh-hant/deployment-strategies-by-feature-toggle )
How to prepare for an Interview
對於準備面試,我個人建議大家可以在求學期間多寫些 Side Project 、參與校園競賽 or 黑客松等等,都是一個很好累積作品與經驗的方式,例如我個人在大學期間參加了宿舍網路管理小組,提早接觸到了許多課程範圍外的知識,並與團隊成員重構了整個前端頁面,這些經驗都是很值得在面試時主動提出的,除了可以展現對於團隊合作的經驗,也可以藉此引起面試官的興趣,從而讓話題引導到你熟悉的領域。
關於 Side Project 的題目尋找,可能也是一個讓很多人感到迷茫的地方,這邊可以推薦大家觀察生活中有沒有什麼不方便的地方(最常見的就是校務系統 XD),找到問題後就可以開始思考是不是有什麼方式來解決,決定後就可以規劃使用什麼框架來實作,從而一步一步的把一個 project 給建立起來!