Hahow X AppWorks School：學員參訪分享心得 — 前端工程師 David
楔子
我是 David（Shanpig），一個工作剛滿一年的前端工程師。在 AppWorks School 五個月的前端集訓後，順利進入業界，在成員相當精實 Hahow 2B 部門： Hahow for Business 中擔任 Junior Front-End Engineer。
前段時間主管說， AppWorks School 要來我們 Hahow 進行企業參訪，問我和另一位校友要不要來進行經驗分享，恰好我也在 Hahow for Business 工作近一年了，也許可以回饋給學弟妹一些東西。
AppWorks School 的培訓經驗，對我而言是職涯轉捩點一般的存在，有興趣的人可以去看看我寫的 【AppWorks School 培訓，軟體界的入門票 — Batch#13 Front-End Class】。如果當初沒有進入 AppWorks School，也許我的轉職之路不會如此的順利。因此，有機會能夠回饋時，我也希望盡我所能地去分享。
關於參訪對象的那些事
這次來到 Hahow 的學員很有趣，並不是過去像我們一樣的轉職班，而是 AppWorks School Campus Program 的學員。我特地詢問了身邊對於這些學生相對熟悉的朋友，得知這些學員的身份是目前仍然在學的大學 — 研究所學生，且清一色都是資訊相關科系。這意味著他們的起步會比我們更早，對資訊技術的熟悉度可能比我們更加深入。Campus Program 培訓的目標也和轉職班有著一定的差別，轉職班的人相對已經明確知道自己希望的方向，因此班級被很清楚的分成前後端、Mobile、Data Engineer 等，但對於還在完成學業的 Campus Program 而言，更多的是還在尋找志向的學生。
針對這樣的聽眾，我能夠給予什麼呢？
關於準備過程的那些事
我們培訓的那一屆，很可惜遇到了疫情開始升溫的時候，沒有機會到各個企業進行參訪，因此我只能依靠自己的想像，以及詢問朋友得知這些學員會希望聽到的內容。我相信技術肯定不是他們來這裡的目的，因為這些在 Campus 學就行了，有些人的技術掌握度可能還比我更高 😆
在技術沒有任何可講性的情況下，拿我和這些學員進行比對，能夠拿出比較明顯差異的，也許就是這一年以來的工作經驗，以及剛進入職場可以預期會遇到的事情了。畢竟這一年對我而言，也是一個非常巨大的蛻變期，回頭看看過去剛開始準備面試的我，可以明顯感受得到當初的生澀和對未來的迷茫。如果能夠讓同樣迷茫的學員提早認知到可預見的未來，也許對他們來說，便是此行的目的了吧。
分享過程
我將工作上可能會遇到的任務分成四個大主題（當然寫程式這個必然有的任務不算在內）：
- 技術文件（溝通協作）
- Brain Storm 各種使用情境（使用者思維 / 產品思維）
- Code Review（觀摩＆同步）
- 持續學習＆分享（互助）
技術文件
寫技術文件其實是多個工程師在協作時很重要的一環。由於任務和需求眾多且複雜，在敏捷開發的腳步下，會需要頻繁的討論，而在 kickoff 一個 sprint 之前，也會需要針對任務做估點，以便估算每個 sprint 能夠進行的任務總量。因此在 kickoff 之前，針對每一個 feature，都會需要有一份技術文件，其中包含對 feature 的拆分、功能敘述、相關檔案及設計稿的連結、示意圖或截圖等等。
若沒有技術文件，口頭上的討論與修改將會沒有一個共同討論與整理的空間，導致無法完整盤點一些較為複雜的功能，或是遺漏掉已經討論過的結論。這會大大提升任務缺漏以及完成品與預期不符的可能性。
Brain Storm
在產品上線後，將會有真正的使用者實際去使用我們所做的產品，而使用者越多，代表使用情境越複雜。產品團隊其中一個很重要的任務，便是盡可能的想像出大部分的使用情境，並根據使用者的回饋進行調整。這個過程通常不是單純工程師的職責，而是需要橫跨 PM、設計師、工程師、QA 等的團隊協作。
Brain Storm 並不是一個工作流程，而是一個會在整個 sprint 中時而出現的事件。
一般來說，工程師會在設計稿的 design review 階段進行 brain storm，根據設計師設計好的 wireframe 或是 mockup，了解使用者的使用流程與情境後，再次確認是否有缺漏或是技術上較難達到的行為，以及思考其他更好使用流程的可能性。
在實際開發後，工程師也會遇到各式各樣沒有想過的技術問題或是使用流程的問題，此時便會再次與其他人開啟討論（可能是 PM、可能是設計師，也可能是其他前後端、Mobile、QA 等工程師），並重新確認有問題的流程，或是技術上難以達到、難以維護，及效率較低的行為。
然而在使用者實際使用到產品之前，通常很難（亦或者說幾乎不可能）涵蓋到「所有的」使用者流程。很多因素將會影響產品團隊對使用者流程的涵蓋完整度，像是功能複雜度、設備/軟硬體版本與多元性、不同的使用習慣、資訊理解與吸收程度的差異等等，都是讓使用者行為變得難以預測的原因。
另外，有些行為只有在極少數且極端的情況下才會發生（稱之為 Edge Case），若花費大量的人力與時間成本在上面，將會是非常沒有效率的資源使用方式。因此在需要快速交付的新創團隊中，通常不會刻意地將所有的 Edge Case 都通盤處理完才上線，而是將多數主要功能上線後，便交給使用者進行使用，若有急迫需要的功能，才會以 Bugfix 的形式進行修復。
Code Review
看其他人寫的程式碼對工程師而言是一個學習與同步的過程。每個開發團隊都會有自己的開發習慣、coding style，以及過去開發的工具。在剛進入一個團隊時，便需要盡可能快速理解團隊的習慣與邏輯，以便可以有效地開發和避免重複造輪子，相同 coding style 也能夠讓彼此協作時更加順暢，避免寫出互相衝突的程式碼，而 code review 便能達到這個效果。
在剛進入 Hahow for Business 時，因為還不夠瞭解團隊的習慣，以及避免我們不小心重造輪子，我們的每一個 PR 都需要經過其他工程師的 review 才能夠進入到 codebase。由於差距實在太大，常常會發生一個 PR 被來回 review 了一兩週還無法 merge 的狀況，review 回來的 comment 多到改不完 😆 但這也讓我得以快速進入狀況，在短時間內適應團隊的開發方式。
漸漸適應之後，我們也需要開始 review 其他人寫的程式，這又是另一種層面的學習，在看較為資深的工程師寫程式，會看到過去不曾想過的邏輯與架構，或是較新、較有效率的解決方案，可以快速的累積知識與工具，並抓到各種新的關鍵字，以便未來可以繼續延伸做學習。
另一方面，code review 也是團隊協作中很重要的一環。
若一個工程師寫的程式碼只有自己看得懂、只有自己改得動，對於團隊來說是一個認知上與開發上的負擔，且如果該工程師離職、請假、臨時有事，將會導致那一部分的程式碼無人可以維護與改動，這是任何團隊都不希望遇到的狀況。code review 根據流程的不同，可以保證至少有兩位以上的工程師看過與理解該段程式碼，即便臨時遇到情況，也不會造成一人獨挑大樑的窘境。
同時，工程師開發常常會遇到重工的情況，即多位工程師在開發時，同時為了同一個功能、bug、元件、目的，做了相同或不同的修改來達到類似的目的。這相當於同時花了兩倍的成本，卻只完成一件事情，且雙方還會因為改了同一份 code 而導致 conflict，白白浪費更多時間。有了 code review 機制，也能夠讓彼此更清楚開發狀況，並互相提醒與同步，避免重複造輪子與重工。
持續學習＆分享
成為工程師後，旅途才正要開始。剛結束培訓進入職場，我們面對的將是更多的難題，若一直停滯不前，在這個快速演進的時代，將會很快被淘汰。因此，持續學習是每一個工程師都應該具備的基本素養。
剛進入 Hahow 時，工作上除了最基本的前端框架，也用到了很多的工具，無論是開發、討論協作、持續整合與交付（CICD），或是專案管理等等，都有相當多的學習方向，對於一個初階工程師而言，剛踏入公司的那一刻，才是真正開始高強度學習的時刻。
很幸運我在 Hahow 遇到了一個相當重視工程師學習進程的主管，定期會關心我們的學習近況，並給予指導與建議，同時也給予我們相當大的自由。除了學習公司的各種知識以外，也在剛進到 Hahow 半年的時間，便成功 host 了一場 lightning talk，講述 React 18 release 的新 feature 與未來展望；後續也不定時參加了各種內部聚會與外部的講座、技術分享會等。
我相信有效率的學習過程必然需要「輸入」與「輸出」兩個部分。透過多元化的輸入獲得材料，並且將其消化產生輸出，最後透過他人給予或自己得到的反饋，重新調整學習方式，可以達到一個讓自己持續成長的正向循環。過程會有很多嘗試，也會有很多失敗，但是在不斷調適的過程中，也能夠逐步發現自己的缺漏與學習節奏，進而用更有效率的方式進行學習，使自己成為更加出色的 Problem Solver。
分享總結
最後，也不免俗的給來參訪的學員一些未來建議。當初在準備時便注意到 Campus Program 與轉職班學員的差異。轉值班的學員大多數是已經選定了某一個領域，如前端、後端、android、iOS、data 等等，而 Campus Program 相對有更多的人還處於觀望或是不確定的狀態，因此我也羅列了三種學員們可能正在經歷的階段：
我是否真的要走前後端？
可以問自己的是，你是否排斥一整天寫程式的生活？雖然工程師的日常不會一天到晚寫程式，但總有一整天需要思考一個問題、解一個 bug 的時候，此時你能不能夠適應這樣的工作模式？
另外，你是否有曾經使用你所學的知識，來解決你生活中的任何問題？如果有這樣的經驗，也許可以更清楚知道前後端的工作，是否適合你。
我確定要走前後端，但還沒找工作 or 不知道能力夠不夠
網路上有相當多的資源，諸如各種教學，抑或是工程師的 Roadmap 等，都可以讓你在學習的路上有跡可循。假設真的不知道應該學什麼，可以從這些資訊中選擇自己較為不熟的部分進行加強。更甚者，就直接去面試吧！只有和業界的人直接接觸，才會知道當下的實力或專業究竟在業界是否足夠。
覺得自己能力差不多了，但想要再更精進自己
學習是一條沒有盡頭的路。若是覺得想要再更精進自己，可以回頭看看過去的作品，再次打磨，或是寫一些技術文章，以增加自己輸出的質與量。另外，也可以接觸 Open Source，或是拓展更多元化的領域，讓自己的能力不再僅限於「ＸＸＸ工程師」，而是成為真正解決問題的 Problem Solver，或是讓團隊更加精進的 Enabler，這些都將會讓你的能力與價值大大提升。
小結
很榮幸我這一次能夠給學弟妹們分享一些我的小小經驗，也希望能夠幫助到大家，同時，這也是給我自己的一個小小提醒，要記得常常回顧自己的學習軌跡，嚴格審視、隨時調整，以讓自己可以在這條道路上走得更穩更好。
感謝讀到這裡的讀者們，如果有任何問題，也歡迎再和我一起討論，互相交流 😆
