前言
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 給建立起來！
有時間的話也建議可以把每個 project 的文件都寫清楚，包括系統架構、使用框架、如何 setup 環境等都可以寫成 Readme 文件，培養自己撰寫文件的能力，在履歷上也可以提供連結，讓面試官可以查看～
在準備面試前，可以把上面提到的內容都統整好，面試前先把所有想 Demo 的服務都開好，讓你可以第一時間 0 間隔的絲滑 present （注意面試時分秒必爭，如果你服務架在像是 Heroku, Render.com 上，你想 Demo 時還要等待它開機就會很尷尬）
這邊也小小跟大家分享一下，可以參考的推薦資源(https://yushenghong.notion.site/799758fbeb69442bb96c6099d0c17e41?pvs=4 )
總結
在這裡的每一天，我都把自己當作海綿，能吸收多少是多少，在 LINE 的生活我深刻體會到「不怕你學，只怕你不學」的精神，團隊一直都願意擁抱新的技術，永遠不用擔心自己不進步。如果對於以上分享的任何一點感興趣的話，我相信在這裡上班一定會很快樂（雙手比讚）
最後，附上一張有著可愛熊大、人生第一次飛鏢三鏢 Bull 以及幫前實習生送機的照片作為一個總結 XD
感謝看到 這邊，希望這篇分享能夠幫助大家更理解實習生活，我們下次見～
