筆者跟擔任 Tech Lead 的朋友聊天時,發現我們在幫新人 Code Review、Code Refactoring、Bug Fixing 時遇到了許多類似的問題,針對這個部分我安排了 3 篇文章做講解,而今天這篇文章會針對新手工程師容易卡住的問題來做分享。
大綱➤ 對網頁的元件(tag)、屬性(attr)不熟悉➤ 對 Object、Array 以及 null、undefine、"" 的特性並不熟➤ 不了解「==」跟「===」的差異➤ API 傳參數時遇到各種遇到困難➤ 非同步(Asynchronous)/同步(Synchronous)概念混亂➤ 不了解程式的運作流程➤ 演算法能力需要加強➤ 看不懂 Console 吐出的錯誤
➤ 對網頁的元件(tag)、屬性(attr)不熟悉
通常我們對「按鈕」的認知是「button」這個元件,相關的「click」事件也是由它來觸發;但我曾經遇過下面這個案例:
他將「click」的事件包到「h6」這個元件中,這造成有時候點擊按鈕是沒有反應的,因為 click 事件觸發的有效範圍只在「h6」裡面,而不是整個 button 的範圍。
後來發現這類因為對網頁元件不熟悉而導致的 Bug 還蠻常見的,如果 Debug 遇到類似問題時,可以先到網路上查詢大家通常會用這個元件來做什麼事,可以減少烏龍事件的發生。
筆者曾看過用「table」來做切版的,在電腦螢幕 Demo 時看起來一切正常,但切換到手機的瞬間就崩潰了…
➤ 對 Object、Array 以及 null、undefine、”” 的特性並不熟
前端串接 API 時,通常都會接收到以 json 格式回傳的物件,但假設我們要取得的是 Array 裡面的資料,如果沒有經過驗證就直接使用很容易會產生 Bug。
像下面這個範例,如果回傳的是空陣列,如果沒有先驗證「陣列長度」就直接取用就會噴錯誤。
有時我們會用物件參數的值來判斷要執行哪個程式,但如果用 undefined、空字串、null 來比對,就可能造成程式沒有依照我們想的邏輯去執行。
下面再舉例一個極端物件,大家可以不要急著往下滑看答案,先思考看看印出來會是什麼結果?
從下圖你可以看到除了「陣列、物件」外,其他都不會通過喔~
又或者有時我們在處理字串時會用「include」這個函式來比對,但如果你丟進去的參數是「null、undefine」這類的也會出事喔!
➤ 不了解「==」跟「===」的差異
不知道大家有沒有想過上面提到的「undefined、null、空字串」如果用「==」跟「===」來比較會有怎麼樣的結果。
或者像是數字、字串、布林值這類的比較,有時這類型的的錯誤也常常讓人 Bug 找半天。
➤ API 傳參數時遇到各種困難
許多新手前端儘管可以完成切版,但是在串接 API 時卻遇到非常多的困難,就算看著 API 文件,在操作 GET、POST、PUT 傳遞參數時有很高的機率傳錯格式,像是:
- POST 的參數用 Params 傳,直接變成明碼。
- 不知道 Body 的 form-data 怎麼組成、raw 如何組成 json 格式。
- 常常有缺少或是格式錯誤參數。
這部分我覺得如果後端工程師願意將 Postman 的 Collection 匯出,並在 Description 寫好邏輯直接讓前端工程師來確認,就會稍微減少以上的問題。
➤ 非同步(Asynchronous)/同步(Synchronous)概念混亂
以非同步(Asynchronous)來說,最常見的錯誤就是前端在呼叫 API 時,並沒有等待資料回傳就直接使用它,導致畫面渲染的時候出現各種 Bug。
以同步(Synchronous)來說,有時會設計了太多不必要的等待機制,導致在某個環節卡死無法進行下一步。
➤ 不了解程式的運作流程
新進工程師通常都要維護 Legacy code,但通常他們並不具備掌握程式運作流程的能力。
這塊除了註解以及技術文件可以加快新手的熟練度外,資深工程師願意一起 Pair Programing 也是一個讓新進工程師能力大增的方式。
我在實戰經驗中發現手把手教學(pair programing)的效率比給 hint 的效率高很多,如果只給新手 hint,除發他天賦異稟,不然有大機率是有聽沒有懂。
在幫忙 Debug 時,筆者也發現很多新手工程師並不瞭解自己的程式到底會怎麼跑,這個時候我們可以透過下中斷點(Breakpoint),讓程式執行的每一步慢慢地在我們眼前呈現。
➤ 演算法能力需要加強
很多時候一個結果是需要經過多次運算才會得到,其中可能含有複雜的 and(&&)、or(ll)、not(!)、大於(>)、小於(<)..邏輯。
假設你今天要設計一個打卡系統,如果要判斷一個職員今日出勤是否有異常,在程式設計上就需要考慮到幾個基礎邏輯:
- 公司是否有彈性上、下班時間
- 該名職員上、下班打卡時間是否在彈性上、下班的區間中
- 該名職員上班總時數是否符合公司規定
- 在判斷上下班打卡異常時,是否有考慮到假勤
如果上面的邏輯複雜度已經超過你的腦容量,我強列建議回歸紙筆。
複雜的邏輯用紙筆寫下來會比較容易理解,這是因為大腦在面對電腦時,邏輯容易憑空想像;而用紙筆寫的時候則可以將邏輯具象化,讓大腦放慢一點腳步反而能找到解法。
想提升演算法能力,推薦挑戰 LeeCode easy 等級的題目。
➤ 看不懂 Console 吐出的錯誤
遇到問題卡關時,我們往往會先上網找答案,不管正不正確,先貼回來看看能不能動。
有時候可能真的找到正確解答了,但因為兩者程式執行的環境不同而有報錯,此時很多新人會因為看不懂這個錯誤,轉而找其他的解答複製貼上。
其實如果你將上面的錯誤訊息貼到 Google,就有很大的機率可以得到解答;一直尋找只靠一步就能完成的解答,有時反而是在走遠路。
StackOverflow 上面聚集各種大神,只要善用關鍵字,基本上你遇到的問題以前已經有數不清的人踩過坑了。
➤ 只使用自己會的技能
面對新的問題時,我們會習慣從大腦搜尋已經純熟技能,但有些問題是現有技能無法處理的,或者要花大量時間才能解決。
以前端的 UI Component 舉例,有些人花大量的時間去創造,但往往最後產出的結果遠遠不如現成的框架、套件,甚至還會有各式各樣的 Bug。
下次遇到現有技能很難解決的問題時,不妨先搜尋網路,看看是否有前輩已經提供很好的解決方案;學習新技能所花的時間,有時會比硬要用過去技能解決更省時喔~
這篇文章只是舉出最常見的幾個問題,筆者相信還有很多點沒有提到,如果讀者有想到的話歡迎補充~
下班有約系列文▋ [前端]新手工程師容易卡住的問題(本篇)
▋ [前端&後端]工程師常犯的錯誤
▋ 讓開發團隊更好協作的方式
▋ 談談 Pair Programing
▋ 談談工程師的話語權
▋ 出社會後,新鮮人要及早知道的 5 件事
▋ 面試的性向測驗竟然準到讓人心裡發寒?
▋ 反其道而行的任務分配
▋ 現在的 Daily Scrum 真的適合團隊嗎?
▋ 用低成本也能請到好員工?資深 HR 不想告訴你的秘密!▶︎ 如果這篇文章有幫助到你1. 可以點擊下方「Follow」來追蹤我~
2. 可以對文章拍手讓我知道 👏🏻你們的追蹤與鼓勵是我繼續寫作的動力 🙏🏼▶︎ 如果你對工程師的職涯感到迷茫1. 也許我在iT邦幫忙發表的系列文可以給你不一樣的觀點 💡
2. 也歡迎您到書局選購支持,透過豐富的案例來重新檢視自己的職涯