Engineering Culture | Learning in LINE — Be a Front End Engineer in LINE for a year
大家好，我是Eric，是一個雜學的前端工程師
雜學的部分是因為技能樹點了Front End、Back End、後端、DevOps、App、Chatbot… 持續擴張中
和大家分享我在LINE這一年學到的一些事情
由於整篇文章有點長，所以我根據主題把文章分成4篇
希望能夠方便大家閱讀🤣
另外，這篇文章也有在LINE Engineering Blog同步發行唷
開發文化篇 Let’s Go
1. Engineering Culture
LINE是一間軟體公司，Engineer可以說是公司主要服務的支柱
為了讓LINE的Engineer們在工作時能夠用正確的心態與想法面對所遇到的問題以及與他人協作，LINE建立了屬於自己的Engineering Culture
Culture的內容大家可以自己看看文字
下面我來說一下我自己體驗到的部分吧
A. Take Ownership
在我曾經參與過的專案中，專案的Project Leader都會給予大家一定的信任&自主權，基本上包含想做哪些task、task處理的順序、應該如何設計&使用哪些技術跟工具，以及task預期完成的時間，都能夠讓大家自己決定，是一個比較美式管理的方法(!?
常見的就是Project Leader跟大家說說這個我們目標在這個Sprint要完成哪些task，然後開放大家自己認領、assign task，剩下的就是自己把負責的task完成💪
而整個過程都是開放大家討論的，不論是技術的或是非技術的問題或是建議，都能隨時都能夠提出來唷
B. Be Open
在LINE內部有許多不同的專案
而這些不同專案的資訊，不論是Meeting、Engineering、Business、Marketing，只要你身為LINER，通常都能夠在Wiki(LINE的Notion)中搜尋一下，應該就能夠找到滿多對應的資料
舉例來說，像是我是以Engineer的身份主要參與某個專案，那麼除了該專案的Repo以外，相對應的Business/Marketing的報表或是文件，通常你也一併能夠存取，有些資訊甚至會直接寄email給你，讓你可以實時的更新產品的最新狀態🤣
而如果是主要參與的專案，雖然不一定能夠直接存取該專案的某些資料，不過只要對該專案有興趣，大多數情況下，在告知負責該專案的Project Leader或是Manager之後，取得Repo/Wiki/Report等等存取權限的機會其實是滿高的！
LINE在內部公開許多專案/產品資訊，不會因為你的身份限制太多你能存取的資訊，讓跨部門/跨專案的資訊取得更加的容易
而資訊取得容易的優點就是，在你對某個專案、某些資訊或是數據有興趣的時候，能夠在阻力很小的情況下，獲得更多的了解，提高了從有興趣到參與專案/開啟合作的可能性
以Engineer來說，在不同的專案都會有許多類似的功能，像是篩選功能、動畫播放…等等，如果在開發某個功能碰到問題時，就能夠參考看看其他的專案是怎麼做的，藉此讓不同專案的經驗能夠互相傳承，減少大家碰到類似問題去survey或是調整所花費的時間
另外，LINE內部也很鼓勵大家去參加研討會、撰寫部落格，甚至是成為講師和大家分享你的知識，這個部分由於內容比較多，在下面「5.提倡分享」我在詳細和大家說說~
C. Trust & Respect
在一開始的背景介紹有提到過，目前我主要參與的專案是DOSI Store
DOSI Store是一個全球化的跨國合作專案，整個產品從Product Owner, TPM, PM, Back End到QA和DevOps都在海外，只有Front End Team在台灣，所以台灣人的只有個位數個，比例超低😆，也就是說，大多數的合作都是跨國溝通
ps. 這也是我工程師人生第二次的跨國合作進行產品開發，在台灣做全球的專案，感覺超酷der
在DOSI Store的跨國合作經驗中，我印象比較深的是，PM真的會去尊重大家對於要做的任務所評估的時間
通常一個產品要進行開發，PM會規劃好要做哪些事情(e.g. 新增賣NFT的功能、多一個設定頁面…)，也就是要做的任務，這些任務我們稱為spec(規格)，當PM給出A版本的spec之後，假設A版本的spec有a, b, c任務，那麼各個team就會評估大概需要多久的時間才能把a, b, c做完，評估完之後和PM說時間，那麼假如PM這樣產品更新/上線會太晚，不能拉這麼長，那就會和大家溝通「如果不做c，那麼少2天可以嗎」，去互相確認彼此評估的時間，進而達到一個平衡，雖然一來一往的溝通很繁瑣，但是確確實實的都是在互相尊重彼此的時間和評估結果
相同的，今天如果PM有多增加spec，那麼也會請你告訴他額外需要多少時間，知道需要花的時間之後再由PM評估、決定要不要做這個spec
大家可能覺得上面這樣不是很正常嗎？本來就應該這樣做呀！
不過在台灣，常見的情況是因為上面長官的壓力，即使PM請你評估時間，你評估需要8天，但是長官覺得太久了，只能給你5天，那麼大家就要崩潰的壓在5天以內做完，連調整spec跟討論的機會都沒有
aka才不管什麼Deadline，時間到給我做完就對了
我個人認為，上述PM來回和大家確認時間，其實就是上方我提到的，LINE企業文化的綜合展現：
- Open-mindedness Communication
- 對彼此時間的尊重
Refs:
2. 支持開源與社群
在軟體工程師的世界中，開源的工具是很重要的，不論公司規模或是服務大小，許多軟體服務的開發、測試、維運，往往都是基於大量的開源工具
如果你不是工程師，不太知道什麼是「開源」，那這邊我以Google Sheet舉個例子、解釋一下開源常見的優缺點
假設你今天用Google Sheet自己做了一個記帳工具，只要符合格式的消費明細全部放上去，就可以幫你產生每年每月的統計圖表、數據等等資訊，然後你把Google Sheet設為公開，分享在自己的FB上，免費讓所有人都能夠瀏覽你做好的記帳工具，包含記帳工具中所有的計算邏輯、表格產生的方式…，甚至大家可以複製一份去自己使用
這個把自己做好的工具免費公開給大家複製、使用的行為，在軟體上稱為「開源」
那開源工具對使用者(軟體工程師們)來說有哪些優點呢？
- 免費：這是最重要的特性，因為是免費的，所以大家使用意願也高了許多(想想你的Google Drive)
- 省時間：不用重複造輪子，你做好的工具，我直接拿來用，如果能夠直接滿足我的需求的話，我肯定是舒舒服服
- 可以基於原版製作自己的版本：由於整個工具包含底層邏輯都是開放的，如果你做的記帳工具，沒辦法完整符合我的需求，假設我會Google Sheet，我自己改一改某部分的邏輯，可能就能夠符合我的邏輯了，說不定可以省下不少時間，讚啦
不過有太陽的地方就會有陰影
由於開源工具往往是免費的，工具是否會持續維護/更新，通常都是基於原作者的熱情，畢竟工具是免費的，原作者沒有責任一定要更新與維護，所以小型的開源工具，比較容易會出現使用者發現工具有問題、壞掉了，回報給原作者，但是原作者不願意花太多時間或是熱情被消磨掉了，導致沒有人去維修、更新的窘境
相較於小型的開源工具，大型的開源工具專案，大多都是在從小專案逐漸壯大的路上，找到志同道合、願意貢獻的夥伴，大家一起組成一個社群/組織/社團，有組織地一同分擔工具開發、更新、維護的工作，讓開源工具能夠生生不息的持續運轉下去，因此大型的開源工具比較不會有無人更新/維護的問題
也因為較大型開源工具的社群人數較多、組織化程度較高，要執行的許多事項也比較多元(比如說給予開發/更新功能、去參與技術研討會推廣開源工具、在某些活動設攤位招募對專案有興趣的夥伴一起加入…)，而這些事項在執行時或多或少都需要一定經費才能順利的執行，因此比較大型的開源工具常常會以基金會的形式運轉
以商業的角度來看，假設軟體公司的主要服務所使用的大型開源工具一旦碰到無人願意繼續更新/維護的情況，那麼將會對有使用該開源工具的服務產生高度的衝擊，小則功能無法正常運作，大則出現資安漏洞，進而導致軟體公司必需投入大量地人力與時間成本尋找適合的開源工具並更換，對公司營運來說不是件好事
為了避免這樣的情況發生，有些軟體公司會主動贊助/支持和公司營運較相關的開源工具專案，讓開源工具/專案能夠持續地運轉下去
當然，LINE當仁不讓的在支持開源專案的公司名單上佔了一個位置
LINE「主要」有贊助的開源工具/專案有這些：
進去各個專案的官網就能夠看到LINE的Logo大大地掛在Sponsors區塊👍👍
而除了上述的開源工具與專案以外，LINE TAIWAN在台灣其實也有透過許多不同的方式持續支持、贊助許多不同的開發者&開源專案社群
另外，LINE在支持外部的開源專案、開發者社群以外，在內部也有鼓勵LINE Engineer們飲水思源，多多參與開源專案、為不同的開源專案創造貢獻，以及提供「教你怎麼根據不同的License使用開源專案」的課程，讓大家能更了解不同License的開源專案的正確使用方式
BTW 根據Open Source Contributor Index的數據
目前LINE在開源專案的貢獻上，在全球落在172名，比飛利普高一點點XD
Refs:
- LINE Engineering — Open Source
- LINE Taiwan x Java 年度盛會：JCConf 2019
- LINE Taiwan x Java 年度盛會：JCConf 2020
- LINE 開發社群計畫: Vue.js Taiwan 006 小聚花絮分享
- LINE 開發社群計畫: 20190806 Vue.js Taiwan @LINE
- Husky — Git hooks
- Open Source Contributor Index
3. 擁抱新技術
「唯一不變的，就是任何事情都在變」
當然，程式語言與工具還有對應的生態系也不例外
過去10年，軟體的載體與開發技術經歷過了許許多多的迭代
從傳統的Win App/Mac App到現在大家常見的Web App、Mobile App
Web App
前端從Pure HTML/CSS/Javascript開始，接著世界希望能靠著JQuery一統天下，不過Backbone.js與knockout.js無法接受，出來力戰群雄，但最終又被Angluar.js/React.js/Vue.js殺出一條血路，到現在進入了三國鼎立的時代
後端的點菜率早期由PHP, Java稱霸，微軟的.Net全家餐也有不少人買回家吃，後面Node.js和Go甚至Python都也陸陸續續被放進菜單中
Mobile App
Native的方面，Android從Java慢慢地轉移到Kotlin，iOS也從Objective C跳到了Swift
Hybrid的方面，早早出現的PhoneGap(Codova)、後起之秀的Ionic都相繼式微，Facebook把React.js推向了ReactNative，號稱和大家搭起友誼的Bridge，可是Google不服氣，也生出Flutter大喊著要革命
而一堆技術的迭代與更新，意味著人們需要持續學習進行知識升級，於是就出現了「求不要更新了，老子學不動了」這種東西哈哈哈哈
很好笑，但是他講的很實際！
程式語言跟技術都持續在更新
那麼軟體公司該如何應對？
而以公司經營和商業的角度來看，某個程度的「穩定」是最重要的，穩定的產品、穩定的業務、穩定的客戶數量、穩定的現金流…，畢竟公司能夠穩定的賺錢，在這個資本主義的社會，才有辦法降低、抵禦外部所產生的各種風險，想想3年前的Covid19的大浪襲來，世界經濟市場開始步入熊市，多少家公司因為資金不足撐不過這一波，只能應聲倒閉
雖然公司在營運上追求相對性的穩定，不過技術的革新並不會因為任何一家公司停下腳步，看看最近的ChatGPT，一項AI技術的突破，就讓搜尋巨頭Google拉起紅色警報。而新出現的技術/工具往往都是為了解決舊技術/工具的問題(然後再創造新問題😅)，進而提高單位時間內的生產力、執行效率，或是降低單位時間內的成本與錯誤率，如果公司希望能在市場上持續保持自身的競爭力，公司理論上勢必要與時俱進，在不同的時間嘗試、導入不一樣的技術與工具，作為風險控管的一種保險投資
不過那只是理論。
實務上，雖然邏輯上大家都知道要學習新知、持續成長，但每個人的時間有限，下班之後大家就是想要躺在床上滑手機耍廢，當個沙發馬鈴薯🥔
許多公司即便知道要適時導入新技術與工具，但是由於技術/工具的更新屬於長期投資、重要但不緊急的工作項目，而且需要花上許多人力物力與經費，基於成本考量，因此往往都會在管理層面上遞延或是作罷
aka 反正現在還能用，先這樣吧，以後再說
以軟體來說，美國銀行使用COBOL開發的系統就是一個滿經典的例子。早期期美國銀行的內部系統有些是使用「COBOL」這款語言開發的，但隨著時代的演變，會COBOL的工程師大多數已經邁入老年、退休。銀行因為沒有持續更新技術、投入經費翻新系統，導致在需要時中無法在市場中找到能夠維護系統的人才，造成系統維護難度大增、企業所承擔的風險升高的問題
講了這麼多，那麼LINE在軟體工程上有很願意導入新技術與工具嗎？
我覺得與其說是「願意」，更好的用詞是「接受」與「擁抱」
LINE在導入新技術上，抱持著滿開放的心態，願意提供資源支持LINER們去探索與嘗試新技術，並且和現有技術做比較，即便最後基於某些原因導致新技術沒有被採用，也能透過內部的分享，將新技術的知識在內部傳播出去，讓有興趣的LINER也了多解該技術，進而提高公司未來向新技術遷移的機會、降低對應的阻力
由於LINE擁抱不同的技術，因此LINE的專案所採用的技術多樣性是很高的，Web App部分，前端有Vue.js也有React.js，後端則是有些使用Java、有些用Go，Mobile App則是有Native也有Hybrid，而不同的語言就會有不同的工具跟生態系，內部擁有技術多樣性的好處是，如果你想學不同的技術的話，可能可以在內部找到技術大神交流，加速上手的速度🤣
而雖然導入新技術的心態是開放的，不過畢竟LINE是一間使用者數量以千萬級別為單位在計算的公司，由於使用者基數大，為了讓絕大多數的使用者都能擁有良好的使用體驗，因此對外提供的服務必須有一定的品質，所以軟體開發上還是必須基於相對成熟、穩定的技術為主，因此不太可能大幅的導入剛冒出頭、嶄新的技術，但當新技術邁入相對穩定期到一個程度時，由於LINE在前期有投入資源進行探索過，在想要導入時就能快上許多
舉例來說，LINE購物的App就是使用Flutter進行開發的，Flutter SKD在2018/12才發布v1.0.0版，而在2020時LINE就採用了Flutter，速度算是滿快的，畢竟採用新技術，往往需要整個Team一起Migration，團隊在技術的學習和轉換上也需要時間
而在LINE內部，決定要不要導入某一個新技術，除了技術本身的熟悉程度與穩定度以外，只要新技術能夠為公司和產品帶來正面的效益、解決掉過往技術的主要問題，即便新技術只有少數人會，也能獲得導入、應用在專案的機會，不過推動者同時也要肩負起推廣新技術的責任就是了😆
在我入職的時候有聽前輩說過，早期有LINER本身是前端工程師，因為對DevOps有興趣，就從一個人開始，在內部推廣DevOps的Best practice與服務，一個人建立起整個DevOps System & Platform給不同的產品用，後續也有獲得內部的支持與資源，把DevOps變成一個Team，超強的！
Refs:
4. 減少重複性工作
相信大家都知道，LINE TAIWAN在台灣當地有推出許多不同的軟體應用與服務(我們稱為Family Service)，常見的像是LINE TODAY, LINE購物、LINE旅遊、LINE熱點、LINE發票管家…etc.
雖然每個軟體服務都是不同的專案，不過各個服務在開發上，往往會有許多共同需求，常見的像是靜態程式碼分析、測試覆蓋率、畫面載入速度、SEO分數、套件升級、弱點掃描、CI/CD… etc.
由於跨專案有著共同的需求，因此LINE內部有稱為Platform Engineer的角色，負責將那些共同的需求平台化、服務化、重用化，讓各個專案不要「重新造輪子(Reinventing the wheel)」，直接使用、串接內部現有的服務即可，同時也避免Engineer在開發專案之餘，還要分心去開發、管理其他額外的服務的情況，讓Engineer能更專注於軟體服務開發，進而提高軟體開發的速度和開發體驗
當然，平台化、服務化聽起來超讚der，當專案有需要的時候，可以直接根據Tutorial和Guideline串接、使用現有的服務就好，不需要從0開始自己建立。不過當需要串接的服務多了之後，其實串接這一大堆服務也是很曠日費時的(工程師就是懶，能自動化就自動化)，所以內部也有推出專門的CLI，在專案建立時就連帶幫你把一堆服務安裝好、把對應的config設定好，將基本的串接的流程自動化，讓開發體驗能夠Booooooooooost🚀
LINE內部常見的Platform Service(for Front End)
- Dependency Upgrade Tool: Renovate
- Security Scanner: OWASP ZAP
- Observability: Sentry, Grafana, OpenTelemetry
- Github PR Preview URL
- CI: Drone/Github Action/Lighthouse CI/Sonarqube
- CD: AgroCD
另外，以公司的角度來看，由於LINE的使用人數在台灣是以千萬為單位在計算，因為如此，基於LINE所提供的每一個Family Service，連帶著也都面臨著幾十萬到幾百萬不等的使用者的使用與挑戰
如果軟體服務有問題/錯誤，輕則影響使用者體驗，重則可能會有資安問題，影響的都是幾十幾百萬的使用者，所以對於LINE來說，LINE必須控管向外推出的每一個軟體服務的品質，以避免、降低軟體錯誤導致的問題與風險
而就像張忠謀說的：「要先管理，必須先量化」
台灣半導體之父張忠謀認為：「沒有辦法數量化的東西就無法管理，或者很難管理，所以即使很難數量化，也要盡量數量化。」
所以其實上述提到的靜態程式碼分析、測試覆蓋率、畫面載入速度、SEO分數、套件升級、弱點掃描…等等環節，都是用數字對軟體品質進行量化，進行軟體品質控管的一個方式
Refs:
5. 提倡分享
加入LINE一年多，我個人的體驗上，LINE是一間重視「分享」的公司，LINE相信分享的力量，並且願意花時間、花資源在分享、管理這些分享的內容上，進行內部知識的散播與傳承
LINE有許多定期的內部會議，在比較大型的會議上除了資訊同步、事物宣達以外，也會有固定的時間給Engineer們進行分享、交流，而我把大家分享的方向分類為「專案」和「技術」2種
- 專案
上面有提到，LINE本身有許多不同的產品，每個Engineer也都會有主要參與、focus的專案，而大家往往都是對自己負責的產品/專案最熟悉、對其他人的專案就沒那麼了解，甚至不太知道其他Engineer在做哪些服務
為了讓LINER們更了解公司內部有哪些專案、彼此在做什麼，內部會透過定期的會議，讓每個專案的成員輪流、互相分享目前專案的內容與進度
2.技術
身為Engineer，那麼大家更常聽到的應該是技術分享，而技術分享大略可以分為這2種：
- 如何解決問題：如何使用哪些技術解決某一個問題
- 踩過的雷跟坑：解決某一個問題時，踩過的雷跟坑，然後是怎麼處理的
由於Engineer在開發產品/專案時，常常會有類似的需求，透過分享「如何解決問題」，可以了解別人是如何解決某個問題的，如果覺得有更好的Practice或是工具，可以學起來，作為現有知識的補充，讓自己的技術或工作效率更上一層樓
至於分享「踩過的雷跟坑」，Engineer應該很理解，大家在開發時肯定碰過「這個功能理論上Code就是這樣寫，邏輯也沒錯，結果功能有Bug，我也不知道為什麼」的坑，每次踩下去少則20~30分鐘，多則2~3天才解決，甚至無法解決都有可能，也因為每次踩坑都要花許多時間，所以內部大家會互相分享踩過的坑、如何處理的，希望可以減少大家踩坑的機會或是踩坑之後需要花費的時間
透過專案或是技術的分享，除了能夠讓大家更了解內部的專案、大家如何解決某些問題或是避開某些坑與雷，更好的是可以激起討論的漣漪，吸引對專案的功能/技術有興趣，或是在開發上有相關經驗的LINER一起做更深入的討論，甚至是參與專案，達到推而廣之的效果
雖然每次的分享內容不一定能夠全部記得，不過分享的內容或多或少都會在大家腦中留下一個「XXX講過某個主題/功能/坑」的印象，當你碰到那個主題相關的問題或是類似的需求時，就能夠在公司的分享紀錄文件中，找到當初分享的內容與講者，詢問當初分享的細節，透過詢問有經驗的人，減少踩過的雷或是學習別人的做法，讓大家能站在巨人的肩膀上走得更快更好更遠
另外，有分享過的朋友就知道「自己所主講的分享，相比我聽別人所分享的，學到的反而是最多的」，其實在一次的分享中，主講者的收穫往往也不小，因為主講者為了在分享時能夠由淺入深、讓聽眾能夠融會貫通，通常會去把整個主題鑽研透徹、把資訊前後邏輯梳理好，而在研究與梳理邏輯時時，除了可能會冒出許多新的知識以外，多次的整理也會加深主講者對於該主題的印象和記憶，多分享一次，就又成長了一些
除了專案和技術為主的分享以外，我在LINE還有體驗到以「投資先備知識」為主體的分享
由於LINE近年開始嘗試Web3 & Blockchain領域、建立LINE自己的Tokenomics和Ecosystem，而要讓自己的生態系壯大，必須要豐富LINE Blockchain上的Dapp應用的廣度、增加Token的流動性，才能吸引使用者參與、加入這個生態系
而豐富LINE Blockchain最直接的方式就是由內部的LINER創新，為了讓LINER能夠在LINE Blockchain上做出創新的服務，LINE知道需要讓大家一起更了解、熟悉Web3生態系中的各種服務與應用、擴大Web3的知識儲備量，提高可行性高的idea產出的可能性
因爲這樣的緣故，於是在LINE內部舉辦了區塊鏈讀書會，讓大家在每週的固定時間輪流分享，多了解鏈上的生態與技術和相關的工具，由於是以知識儲備為主，因此分享的範圍也很廣泛，從Dapp Intro、Case Study、跨鏈的Cosmos、Ethereum、Solidy/Smart Contract都有，算是一個滿特別的體驗與嘗試
開發文化介紹的部分結束啦，如果對篇章的內容有興趣的話，歡迎大家去看看其他篇喔
