[面試][設計模式]Code Review 會注意哪些事?會依照什麼原則對程式做 Refactoring?
「沒有最好的程式,只有更好的程式。」在完成功能後 Code Review 是非常重要的事情;不只看自己的程式碼,也要多觀摩其他人的程式碼,這個動作除了可以優化程式碼品質外,還可以幫助團隊了解彼此的工作進度。
TOPIC ・ 主題
Career Growth
從技職生到外商工程師、作家與講師的真實經歷,聊職涯選擇、自我經營,以及那些沒人說出口的職場現實。
共 128 篇文章
「沒有最好的程式,只有更好的程式。」在完成功能後 Code Review 是非常重要的事情;不只看自己的程式碼,也要多觀摩其他人的程式碼,這個動作除了可以優化程式碼品質外,還可以幫助團隊了解彼此的工作進度。
網路商城特賣會常常會推出特定商品限量 1 組的搶購活動,在搶購過程除了會產生高併發的問題外,同時也需要考慮到「商品會不會超賣」,在現實生活中聽起來很不可思議;但在網路的世界裡,如果SQL邏輯沒有設計好,真的可能發生明明只限 1 組卻賣了 10 組商品的超賣事件。
除非你的實戰經驗超級豐富,不然在面試時一定會遇到不熟悉的議題;面對無法回答的問題,我個人會老實向面試官表明自己沒有這方面的經驗,會持續學習,瞎掰答案容易讓對方覺得你以後進來公司也會這樣做事。
如果公司有專門的 DBA,後端工程師就可以把心力放在資料邏輯的處理上;但筆者詢問周圍的朋友,似乎有不少公司都是讓後端工程師兼任 DBA...
工程師真的很難,會得不多會被問為什麼沒學,會得很多還要被質疑專業程度;這種比較類型的問題,除非你有事先做功課,不然就算你都會用也未必能在現場對答如流。
回想當年還是前端菜鳥時,我完全信任後端前輩回傳的資料;記得當年有個產品上線前的測試一切正常,但上線幾天後 PM 就接到客戶回報系統上有頁面顯示不全的 Bug;因為網頁前端是我負責的,所以第一個被抓去興師問罪。
除非你是草創成員,不然進入一間公司後,往往都是跟著前輩訂下的規則走;大部分的前輩在交接的時候只會說要這樣做,而不會告訴你為什麼要這樣做。