因為經歷高度相似，所以我們遇到的選擇、機遇、困境也很雷同。

自認記憶能力有限，所以透過文字紀錄彼此的觀點。

珍惜願意與你分享真實資訊的朋友 💡

這次聚會讓我深刻體會到，能交換「真實」資訊的朋友是多麼珍貴。

隨著年紀增長，我們學會了保護自己；因此總是語帶保留、點到為止。

但很多時候，最重要的就是那些「被保留」的關鍵資訊。

有些人覺得網路這麼發達，什麼資訊都能找到；但實際上很多資訊都是碎片化，或是被人為美化的。

拿著片面資訊做決策，你可能會搞死自己。

定價策略與市場認知 📈

聊到課程接洽的經驗時，我們討論了與管顧公司合作的利弊。

如果是你自己跟企業洽談，可能收入為 8000 元/小時。

但如果改由管顧公司來接洽，也許收入會下降到 6000 元/小時。

從帳面上來看，每小時少賺 2000 元；但管理顧問公司的抽成往往有 4 成左右，也就是在企業眼中，你的價值是 10000 元/小時。

把時間拉長，這種合作能提升講師的市場價值與知名度；日後有企業來找你時，你也能很自然的提高報價。

不同窗口用不同的報價策略 🔄

企業可能透過內部的 HR、業務（特助）來邀請講師。

如果對話的窗口是 HR，那報完價後，可以詢問一下是否符合他們的預算。

因為 HR 找人時往往有多個名單，最後沒有選擇你有可能只是預算上的考量。

但如果對話的窗口是業務（特助），你可以放膽報高一點的價格。

因為他們來找你，通常不是因為這個主題需要一個講師，而是希望由「你」來當這個主題的講師。

即使報價超過預算也會與你商議，因此你有更高的機率爭取到不錯的講師費。

都會踩到坑，只是遲與早 🎯

講師的授課能力，基本上與授課次數成正比。

因為只有踩到足夠多的坑，才知道發生意外時要如何應對，或是向誰尋求協助。

像在這次聚會中我才知道，原來 Google Drive 上的檔案如果在短時間內被大量下載會卡死。

人生路上有很多坑，如果提早知道就能事先找出對策。

堅守品質與道德底線 🌟

我們一致認為，堅持自己的底線非常重要。

有些自媒體為了增加曝光度與收入，會透過誇張不實的標題與封面來吸引點閱率、促購。

但這種做法實際上是在損害讀者對你的信任（雖然總是有新的韭菜）。

因為自媒體對我們來說只是斜槓，所以我們更在意內容與標題的一致性，不想做出違反內心的決策。

希望大家遇到能與自己深度交流的朋友 🤝

希望這篇文章能讓更多人意識到，並珍惜生活中那些寶貴的連結。

透過真誠的分享和交流，彼此都能共同進步和成長 ✨

推薦大家追蹤資安大佬 HackerCat，不定時會分享很棒的文章！

如果你對目前的職涯感到迷茫，想從不同視角檢視自己的選擇，相信《工程師下班有約》這本書能為你帶來靈感與啟發：

今天想跟大家分享一個特別的用餐經驗，他讓我體會到了勇敢提出需求的重要性。

其實我們很困擾 😨

上週跟朋友預約了一間餐廳吃飯。

進門後，服務生把我們安排到一張有點小的桌子；擺上菜單後，甚至快要沒有放水杯的空間。

對兩個食量不小的男生來說，我們實在不確定這個桌子是否能容納我們點的食物。

勇敢提出需求 💡

就在這時，朋友向服務員招了招手，有禮貌地詢問：「不好意思，我們點的東西有點多；如果可以，能幫我們換到大一點的桌子嗎？」

聽到需求後，服務員先是一愣，然後轉頭看了一下周圍，發現餐廳其實還有一些空位，於是說：「稍等一下，我跟同事做個確認。」

獲得更好的體驗 🎉

幾分鐘後，服務員便邀請我們換到寬敞舒適的沙發座位，這讓我們的用餐體驗上升了好幾個檔次。

老實講，原本的座位除了桌子小外，椅子坐起來也不太舒服。

因此在坐上沙發的那一刻，我深刻體會到：「只要勇敢提出需求，很多事情都可能變得不一樣。」

打破規則並不是要你為難別人 🚫

我跟朋友預約的時間，已經是餐廳最晚能預約的時段；除非有人遲到，不然接下來不太會有新客人進門。

所以在看到有更舒適的空位時，朋友才向服務生提出了需求。

這次經驗讓我反思：「在生活中，我們是否太過順從現狀，而忽略了爭取更好選擇的機會？」

打破規則並不是要你為難別人，而是要你質疑現狀，尋找更好的解決方案。

如果害怕麻煩別人，那受苦的只有自己 🤕

最後我想從這次用餐經驗中帶出幾點反思：

• 勇於表達需求：很多時候，只要我們提出需求，就能獲得更好的結果。
• 觀察周圍環境：留意周圍的情況，可能會發現更多可行的選擇。
• 不要害怕被拒絕：即使被拒絕，我們也沒有損失，反而可能獲得意想不到的驚喜。

下次當你遇到不理想的安排時，不妨試著提出需求，看能否有更好的選擇。

畢竟，絕大多數的機會，都是從勇敢詢問開始的。

如果你對目前的職涯感到迷茫，想從不同視角檢視自己的選擇，相信《工程師下班有約》這本書能為你帶來靈感與啟發：

同時為了避免老闆＆HR 對內容有過度期待，這邊事先聲明文中的方法僅適用於尋找「初階人才」；用香蕉不可能請到老虎，但有機會請到「幼虎」。

擁有 30 年招募經驗的總經理是如何挑選人才的？

一間公司是否能長久經營，除了產品很重要外，「人才」更是重中之重。

筆者有幸認識一位在資訊產業的中小企業老闆，公司每一位工程師都要經過他的面試才能錄用。

而他所錄用的工程師，無論初階人才還是中階人才，大概有 6 成的人在入職半年後展現了超高的 CP 值；因為覺得很不可思議，所以我便向他請教這是如何辦到的？

本篇文章先探討「初階人才」，之後再找時間分享這位老闆尋找「中階人才」的心法。

先搞清楚自己要找到哪一類型的人才

這位老闆的公司業務量穩定，也沒有想繼續擴張的野心。

他了解自己只是中小企業，論名氣、發展性遠遠不如其他大公司，所以在人才方面，他瞄準的是「市場不看好，但有潛力的人才」。

對他來說，公司是有時間培養人才的（應屆畢業生可），因此是否具備專業能力並不重要（只找非本科），而態度則是他最重視的人格特質（服從性）。

在履歷篩選上另闢蹊徑

根據上方的需求，儘管為資訊產業，公司要找的也是工程師，但為了壓低用人成本，他加入了如下條件：

1. 不找本科系的畢業生（資工、資管、電資畢業的直接過濾）
2. 一定要是「國立」大學（中字輩以上）
3. 一定要是「理工」科系（特別偏愛土木、大氣、物理）
4. 工作經驗 3 年以內，無經驗可
5. 年齡 28 歲以下
6. 如果目前是租屋更好（老實講這點很地獄 😨）

上面履歷的篩選邏輯，可以說跟絕大多數資訊產業的同行相反；但正是因為這個與眾不同的策略，讓他有非常多「淘寶」的機會。

用這位老闆的話說：「只要是本科系，就很難用低於市場的薪水錄取；這樣我還不如用更低的薪水多錄取幾個感覺有潛力，但沒有相關背景的新人；而有經濟壓力的人，相對來說服從性更高。」

透過面試觀察人格特質

透過剛剛條件篩選下來的履歷，大部分的「天賦」都有一定水準；因此在面試時，主要觀察求職者的人格特質（因為專業能力不行是打從一開始就知道的）：

1. 服裝儀容是否整潔（自我要求，以及對這場面試的重視程度）
2. 過往團隊合作時擔任的角色、執行的任務（了解團隊溝通能力，以及對交付任務的執行力）
3. 面對邏輯考題的反應速度（專業能力可以不行，但邏輯絕對要清晰）
4. 對資訊產業的了解程度（根據回答的內容，判斷進入這個產業的意願＆積極性）
5. 遇到不會問題時的應對進退（看對方的反應是硬撐、討論、瞎掰、放棄，還是直接生氣😠）

透過試用期確認自己的眼光

這邊特別提醒，如果在試用期被資遣，雇主是需要付資遣費的喔！

跟希望人才馬上成為即戰力的公司不同，老闆選擇讓剛入職的新人在前 3 個月自我精進，每個月用工作上會用到的技能完成一份 Side Project，並在月底向所有員工 Demo，同時解釋自己是如何發想、規劃、執行。

因為題目與難易度完全是自由選擇，所以能從這些 Side Project 中看到一個人的潛力，進而評估是否讓他成為公司的一份子。

因為「非本科系、無相關經驗、應屆畢業生」這幾個條件，大幅降低公司的試錯成本，在經過這些層層篩選後，往往留下來的都是有成為工程師天賦的人。

上面的策略聽起來不錯，但一切有這麼順利嗎？

一路聽下來，我覺得老闆分析的很有道理，且實際執行的成效也很棒，於是我便向他詢問：「這個方法聽起來很棒，它有什麼缺陷嗎？」

老闆笑了笑說：「你不是第一個向我詢問這個問題的，實際上有些朋友在聽完我的分享後，回去就立馬在公司執行看看，但我目前還沒有聽到其他人的成功案例。」

接下來老闆分享了許多成功與失敗細節，筆者大致統整如下：

1. 上面的流程之所以可以完美執行，是因為他本身就是老闆，從面試人才、錄用人才到培養人才，每個環節都抓得很緊，因此成功率才會如此之高。
2. 公司可以在「一開始」用低成本請到好員工，但通常在「8~16」個月後，人才也會意識到自己的薪水低於市場價格，如果沒有適當的調整可能會就導致人才流失。
3. 因為你對人才有知遇之恩，所以通常員工跟你的關係會更為緊密，如果對方入職滿兩年且能力符合需求，公司會分給他「股票」，把他跟公司的利益結構綁在一起（公司如果有盈餘，依照持股比例分紅）。
4. 許多人回去執行後，都打電話抱怨說他們找到的是「雷包」，不是每個老闆、HR、主管都有挑選人才的天賦，就算把秘訣都告訴你；相同的方法，在每個執行者的手上也會有完全不同的結果。

別人的經驗，我們可以借鑑，但是否適用於自己的公司真的要謹慎評估；在這次聊天中，老闆也跟我分享他找「中階人才」的心法，這部分筆者會再獨立一篇與大家分享。

這種公司也許在某些人眼中是不合格的，但它的存在給許多想轉職又沒經驗的人一個機會，有能力的人自然可以用它為跳板向上挑戰。

瞭解資方的策略與想法，有時對我們職涯的選擇也會有所幫助。

如果你對目前的職涯感到迷茫，想從不同視角檢視自己的選擇，相信《工程師下班有約》這本書能為你帶來靈感與啟發：

下班有約系列文
▋ [前端]新手工程師容易卡住的問題
▋ [前端＆後端]工程師常犯的錯誤
▋ 讓開發團隊更好協作的方式
▋ 談談 Pair Programing
▋ 談談工程師的話語權
▋ 出社會後，新鮮人要及早知道的 5 件事
▋ 面試的性向測驗竟然準到讓人心裡發寒？
▋ 反其道而行的任務分配
▋ 現在的 Daily Scrum 真的適合團隊嗎？
▋ 用低成本也能請到好員工？資深 HR 不想告訴你的秘密！(本篇)

大綱
一、不要只讓 Junior 工程師去做已經會的事情
二、小公司的 Junior 工程師通常戰力較強
三、透過反其道而行的任務分配讓 Junior 工程師快速成長
四、通常只有絕望的人才會珍惜他人的建議
五、筆者心得

一、不要只讓 Junior 工程師去做已經會的事情

不要讓工程師在 Junior 的階段停留太久

工程師的 Junior 跟 Senior 並不是用年資來判定的，而是從技術、溝通能力、行業理解度三個面向來綜合評價。

如果一直分配 Junior 工程師能力範圍內的任務，那他就只能在已知的世界中持續熟練；以健身舉例，如果拿 1 KG 的啞鈴來重訓，無論你重訓多久都很難練成巨巨。

二、小公司的 Junior 工程師通常戰力較強

如果孤立無援，就只能強迫成長

即使都是掛 Junior 的職稱，在大多數的狀況下，小公司出來的工程師會有更全面的技能，且抗壓能力較高。

因為小公司往往是這片天我一個人撐起，一個人就要負責一個、甚至多個專案；且因為公司每個人都很忙，遇到問題很難有前輩願意抽空協助。

在這種自生自滅的狀況下，能堅持下來的往往是優秀的人才；因此我朋友在面試時也更傾向找小公司，尤其是外包公司出身的工程師。

三、透過反其道而行的任務分配讓 Junior 工程師快速成長

比起將會的事情變得更熟練，還不如讓他挑戰那些沒有做過的事情

因為團隊人數較多，所以對大公司來說較少遇到小公司那種這片天我一個人撐起的情境。

但透過反其道而行的任務分配卻能達到類似的效果，且能刺激人才成長。這邊我舉個案例，讓大家了解他實際上是怎麼運作的：

1. 將任務的困難度分成「基礎、進階、地獄」三種，通常基礎的任務會佔據 75%，進階的大約 20%，地獄一般來說不會超過 5%。
2. 讓 Senior 工程師來做「基礎」任務可以保證系統一定的穩定性。
3. 假設今天系統上有「單筆查詢」跟「批量查詢」的功能，會請 Senior 工程師在短時間先將「單筆查詢」完成，然後請 Junior 工程師去實作「批量查詢」。
4. 儘管是進階一點的功能，但因為有類似的範例可以參考，Junior 工程師並不會一籌莫展，先讓他嘗試用自己的方式來解決這個任務。
5. 如果 Junior 工程師能順利解決問題，那他會非常有成就感，對寫程式更有自信；並且開始建立屬於自己面對難題的 SOP，朝著 Senior 工程師邁進。

「地獄」級別的任務會交由 Senior 工程師來做，畢竟如果任務難度完全超過 Junior 工程師的世界觀，讓他們來嘗試反而是浪費時間。

四、通常只有絕望的人才會珍惜他人的建議

聽來的都是故事，自己走過的才叫經驗

不過 Junior 工程師也可能在嘗試一切錯誤的方法後還是卡關，此時 Senior 工程師的任務就來了。

Senior 工程師要先判斷 Junior 工程師研究的方向是不是正確的，如果方向是正確，且只差臨門一腳，就給予適當的提示，讓他自己完成最後一步；但如果方向完全錯誤，則利用 Pair Programing 的方式來讓他了解該怎麼完成。

一定要等 Junior 工程師用盡全力嘗試後再幫忙，如果 Senior 工程師太早出手相救，那 Junior 工程師永遠長不大；人不會珍惜直接給予的答案，只有在經過反覆思考與淬煉後，才了解這答案多來之不易。

這個道理就跟父母給你的建議常常被當耳邊風，但如果你花 10 萬塊去上一堂課會覺得講師說的話跟黃金一樣珍貴。

五、筆者心得

過去都是把基礎的任務給 Junior 工程師、進階的任務給 Senior 工程師。因此筆者也發現不是每個 Junior 工程師都會去研究 Senior 工程師寫的程式。

會造成這樣的結果可能是因為任務難度與性質的不同，或是 Junior 工程師看不懂、覺得自己還不需要懂。

而這種反其道而行的任務分配就解決了這個問題，在強制 Junior 工程師突破舒適圈的同時，還讓 Senior 工程師有更多與 Junior 工程師溝通的時間，建立彼此的革命情感。

當然這套方案是否合適，還是要看公司 Senior 工程師是不是能夠順利解決這些卡住的問題，以及 Engineer Manager 能否為開發團隊爭取適當的時間。

如果你對目前的職涯感到迷茫，想從不同視角檢視自己的選擇，相信《工程師下班有約》這本書能為你帶來靈感與啟發：

下班有約系列文
▋ [前端]新手工程師容易卡住的問題
▋ [前端＆後端]工程師常犯的錯誤
▋ 讓開發團隊更好協作的方式
▋ 談談 Pair Programing
▋ 談談工程師的話語權
▋ 出社會後，新鮮人要及早知道的 5 件事
▋ 面試的性向測驗竟然準到讓人心裡發寒？
▋ 反其道而行的任務分配(本篇)
▋ 現在的 Daily Scrum 真的適合團隊嗎？
▋ 用低成本也能請到好員工？資深 HR 不想告訴你的秘密！

大綱
一、為什麼有些人這麼重視這份測驗?
二、我要偽造自己的性格來獲取 Offer 嗎？
三、反映性向測驗的現實案例：我就是生來顛覆
四、反映性向測驗的現實案例：每個人都有自己的優點
五、總結

一、為什麼有些人這麼重視這份測驗?

「我以為這個東西大家都是亂填的沒啥參考價值，但在部門物是人非後，發現它根本準到令人心寒。」 ── 一位歷經滄桑的主管悲嘆

通常受過傷的人才會特別重視這項測驗，有朋友就曾表示當組織誕生問題兒童時，他會先回去翻他入職時的性向測驗，此時往往會發現，這些「問題兒童」的誕生並非偶然。

性向測驗並非「玄學」而是「科學」，只要求職者用直覺去選擇答案，他就有相當大的參考價值。

跟用星座決定是否錄取的老闆相比，性向測驗實在科學太多了 XD

二、我要偽造自己的性格來獲取 Offer 嗎？

有部分心理系出身，或是對心理學有所研究的人，他們可以輕易地在性向測驗上偽造自己的性格。（筆者相信大部分的人都是善良且誠實的，這頂多算是潛意識的習慣？）

但除非他們連在面試現場的表現都能偽造的天衣無縫，不然肯定會被面試官、HR 覺得這個人怪怪的，而錄取「怪人」往往會給組織帶來許多未知的風險。

況且每間公司在不同職位上需要的人才不同，你怎麼能肯定自己偽造出來的性格就是該公司需要的？

如果每個求職者都表現出強大的積極性，那想要找穩紮穩打人才的公司就會很困擾。

性向測驗的結果沒有絕對的好壞，就是看你與面試公司的氣場是否合適。

雖然話是這樣講，但大部分公司還是傾向打保守牌，如果受測者的「情緒穩定度、服從性」分數超級低，用人主管還是會好好評估的。

三、反映性向測驗的現實案例：我就是生來顛覆

如果錄取一個不合適的人，影響到的可能是全公司的收益。

在一個適合借酒澆愁的夜晚，擔任部門主管的朋友跟我分享了一個血淋淋的案例。

當時公司有個職位空缺太久，在一直找不到適合人選的狀態下，部門主管挑選了一個勉強堪用的求職者。

原本也沒期待她能夠有多大的輸出，只求能夠完成本分的事情就夠了；但隨著時間推移，組織內部的氣氛越來越奇怪。

直到某一天，她突然無預警的被開除，大家才知道裡面發生了一個怎麼樣的故事，也了解為什麼用錯了一個人會導致整個部門完全失去向心力。

STEP 1：利用人喜歡聽八卦的本性

在公司與人建立聯繫最快的方式就是聊八卦，而八卦的內容儘管無法確認真假，卻能潛移默化的影響一個人看待他人的目光。

最開始她先用無傷大雅的八卦與同事建立聯繫，並且製造各種巧合讓這些八卦一一被印證，讓大家相信她的情報是有價值的。

STEP 2：告訴你無法與本人確認真假的八卦

而下一步，她向團隊成員散播不利於所有人的八卦消息，而這些八卦訊息你是很難跟本人求證的，舉例：

1. 在主管最近無理由的挺她、幫她說話的狀況下；跟你說主管對她有意思，還想要約她出去玩，並附上對話截圖。
2. 如果發現其他女同事跟大家相處愉快，就跟主管打小報告說這個同事作風不檢點，想用不正當手段在職場生存，害她被排擠。
3. 用誘導的提問方式讓你說其他人的壞話，並將其錄音、截圖給本人。

如果你是下屬，會不會懷疑主管跟她有不可告人的秘密？

如果你是主管，會不會用不一樣的角度來解讀這個女同事的所作所為？

如果你收到錄音、截圖，會不會與他人產生猜忌？

上面這些涉及個人隱私的內容，相信大多數人都不可能與本人求證。

STEP 3：用資訊不對等製造內部糾紛

在心態改變後，一句再普通不過的話語都可能被視為挑釁。

經歷了上面的步驟後，已經有許多成員被影響；而那些沒被影響的成員更慘，因為被重點抹黑。

團隊成員不信任彼此的狀態下，只要小小的摩擦，就足以產生燎原的野火。

故事尾聲

點火的人就如開頭所說，事跡敗露後被開除了，但她給部門製造的傷害除了績效上的損失外，間接導致的部門形象受損、人才流失的影響更為深遠。

後來朋友回去看這個人的性向測驗，發現她在「情緒穩定、服從性」的指標接近為 0。

四、反映性向測驗的現實案例：每個人都有自己的優點

上面的案例是鬼故事，接下來這個案例應該就是「天生我材必有用」？

朋友公司有個成員的做事速度較慢，因此他把這個情況向主管匯報，希望主管可以跟他溝通一下，不要拖到大家的進度。

不過主管在了解狀況後並沒有選擇跟做事較慢的組員溝通，而是拿出了性向測驗結果，跟朋友說道：「其實他做事比較慢這點我很早就發現了，也曾經想著有沒有要去跟他溝通；但在發現他性向測驗的敏捷性是 0，可是細緻性是接近滿分後，我思考良久，就沒有多說什麼了；畢竟組織中如果每個人都在往前衝，那也是很危險的一件事情。」

「一個方案的好壞，不要只看激動人心的部分，反而要注意風險的控制。 」— 理想之城

五、總結

在性向測驗時做自己，比較有機會進入與自己契合的工作環境。

技術、知識都可以透過後天教育和學習成長，但人的性格是長期養成出來的。

想要改變一個人的性格極為困難，就算當下勉強改了，也有很高的機率故態復萌（就像渣男劈腿一次的通常會劈腿第二次？）。

與其戴上面具，改變自己的性格去工作，還不如去找一份跟自己性格匹配的工作。

再次提醒，性向測驗的結果沒有絕對的好壞；勉強自己的後果可能會導致被放到不對的位置。

如果你對目前的職涯感到迷茫，想從不同視角檢視自己的選擇，相信《工程師下班有約》這本書能為你帶來靈感與啟發：

下班有約系列文
▋ [前端]新手工程師容易卡住的問題
▋ [前端＆後端]工程師常犯的錯誤
▋ 讓開發團隊更好協作的方式
▋ 談談 Pair Programing
▋ 談談工程師的話語權
▋ 出社會後，新鮮人要及早知道的 5 件事
▋ 面試的性向測驗竟然準到讓人心裡發寒？(本篇)
▋ 反其道而行的任務分配
▋ 現在的 Daily Scrum 真的適合團隊嗎？
▋ 用低成本也能請到好員工？資深 HR 不想告訴你的秘密！

大綱
➤ 保留太多無用的 console.log
➤ 沒有註明輸出的 console.log 要做什麼事
➤ 忽視 Console 吐出的警告、錯誤
➤ 不同函式共用「命名相同的全域變數」
➤ 大量存取不必要的 API
➤ 將很多用不到程式碼註解而非刪除
➤ 沒寫註解，或是寫沒有意義的註解
➤ Copy & Paste 後，Function、Variable 命名沒有改
➤ 沒有寫 try catch
➤ 在他人協助下完成功能後，沒有真正了解原理
➤ 沒有做 Refactoring
➤ 詢問別人前沒有自己嘗試
➤ 詢問的問題不夠精確
➤ 管理者權限與使用者權限混在一起

保留太多無用的 console.log

為了追蹤資料流向，我們會用 console.log 來確認程式是否依照我們的想法在執行；但有不少人只會一直增加新的 console.log，而不把已經不需要的 console.log 給移除。

沒有註明輸出的 console.log 要做什麼事

筆者曾在按下 F12 開啟開發人員工具幫人 debug 時，看到 Console 這個分頁下印出一堆 API 回傳的 response data，但命名完全一樣都叫「result」，這樣我完全無法知道這些 result 是由哪個 API 回傳的ＱＱ

不然就是很多意義不明只有自己才知道是什麼意思的 console.log（這類型的往往一個月後連本人都不知道在做什麼…）

忽視 Console 吐出的警告、錯誤

有些網頁看似運行的很正常，但在按下 F12 開啟開發人員工具後，你會看到一排讓人血壓上升的紅色 Error Message，如果沒有及時處理遲早有一天會業力引爆的。

不同函式共用「命名相同的全域變數」

像是 Vue 框架下用來儲存變數資訊的 「Vuex」，裡面 State 的資訊是可以在多個頁面共同使用，下面舉例幾個不夠謹慎會造成的問題：

• 如果在 loading 資料前沒有清空先前的 state 資訊，會導致進入頁面時會閃現上一次進入的資料。
• 如果把第幾頁(page)、分頁筆數(per-page)這些參數在多個頁面共用，那你就會看到有些頁面明明是第一次進入，卻跳轉到其他頁數。

大量存取不必要的 API

這裡舉出兩個常見的例子：

• 登入後就「一次呼叫所有的 API」，但許多 API 回傳的資料可能使用者根本還用不到。

這邊提醒一下，適當的「預載」可以增加使用者體驗，但如果在系統首頁就全部載入，除了會消耗使用者的資源外，一旦大量使用者同時上線，對伺服器端會造成很大的壓力。

• 有些搜尋功能會隨著使用者填入的文字去呼叫 API 來即時顯示搜尋結果或是建議關鍵字（ex：Google），但如果沒有把呼叫 API 的時間間隔設定好（debounceTime），使用者又不停更改搜尋列文字，那就會呼叫非常多不必要的 API。

將用不到程式碼註解而非刪除

在開發階段有時會想到很多的解決方案，因為不確定哪個效能較高，所以就把每個演算法實現出來。

但有些人在決定使用某個解決方案後，依舊沒把其他的方案刪除，這樣的做法容易造成未來維護的困難度。

沒寫註解，或是寫沒有意義的註解

雖然有神人說過：最好的註解就是程式碼本身

但我想：「絕大多數的人都難以到達這個境界，所以要乖乖地寫註解ＸＤ」

let mode = 0;

// do somethings ...

if (mode === 0) {
  // excute logic 1
} else if (mode === 1) {
  // excute logic 2
} else if (mode === 2) {
  // excute logic 3
}

原始碼：bad_remark_example.js（GitHub Gist）

像是上面這段 Code，我們可以知道 mode 這個變數應該是應用在某個狀態的判斷上；但具體在哪個地方使用、總共有哪些狀態、各自代表什麼意義，在沒有註解的狀態下只能一行一行的閱讀，沒辦法第一時間理解程式。

👍 註解的好處

1. 交代前因後果：為什麼這樣寫?遇到了什麼困難?解決了什麼問題?
2. 作為文件說明：有些技術是需要被學習後才能夠看得懂的(ex:引入的模組、套件)，你的註解能讓他快速理解這些工具怎麼使用

🙅 請不要有註解如下

1. 毫無意義的牢騷(ex:我好崩潰啊，這段程式我寫了一個禮拜…)
2. 把註解當成版本控制(ex:2020/08/23 完成此函式)
3. 說明這段程式是誰寫的(簽名檔)
4. 把舊的程式碼註解起來怕以後會用到(但通常再也不會用到，而且這個問題用版控就能解決)

Copy & Paste 後，Function、Variable 命名沒有改

如果寫專案時發現之前做過類似的功能，我們會複製過來再做微調，以此加快開發的速度。

但請修改 Function、Variable 命名！這不會花你太多時間，但在未來當你需要維護專案時，你會感謝現在的自己。

筆者之前曾在幫忙 Debug 時，於Ａ系統裡面看到一堆Ｂ系統的命名，當下還以為自己開錯專案了…

沒有寫 try catch

程式在缺乏 try-catch 的機制下是非常脆弱的，只要發生例外事件就容易崩潰。

如果你直接假定 API 只會回傳正確的資訊，而沒有撰寫 try-catch 去捕捉可能的 400、500 系列錯誤，就很可能導致系統許多行為錯誤如：

1. 跳轉到無權限的頁面
2. 程式進入無限迴圈
3. 瘋狂 Call 某隻 API 直到變成 429 錯誤（Too Many Requests）

在他人協助下完成功能後，沒有真正了解原理

我相信大部分的人都是樂於幫助別人解決問題的，但同時也相信，沒有人希望再次被「相同的問題」打擾。

我這邊強烈建議請他人協助問題前，先 commit 一版，這樣無論對方成功還是失敗，你都有一個記錄在。

如果對方成功解決這個問題，一定找時間回到當時 commit 的那版，用自己的邏輯把功能完成；請記住，別人完成的任務不會自動成為你的知識。

沒有做 Refactoring

演算法相關的 Refactor 有一定的難度，但有一些很基礎的 Refactor 我認為是有必要的，像是變數命名這一塊。

我們先來看一個不好的範例：

let result = responseData;
if (result[result.length - 1]) {
  if ("check_in" in result[result.length - 1] && result[result.length - 1].check_in !== null) {
    state.check_in = result[0].check_in.toString();
  }
}
if (result[result.length - 1]) {
  if ("check_out" in result[result.length - 1] && result[result.length - 1].check_out !== null) {
    state.check_out = result[result.length - 1].check_out.toString();
  }
}

原始碼：need_refactor.js（GitHub Gist）

上面這個是要取得回傳的「最後一筆」資料做邏輯處理，但是全部都使用「result[result.length -1]」來表示，相信大家都會看得有點眼花。

下面我們做個簡單的 Refactor，看起來就會舒服很多：

let result = [];
let last_record = result[result.length - 1];
if (last_record) {
  if ("check_in" in last_record && last_record.check_in !== null) {
    state.check_in = last_record.check_in.toString();
  }
}
if (last_record) {
  if ("check_out" in last_record && last_record.check_out !== null) {
    state.check_out = last_record.check_out.toString();
  }
}

原始碼：after_refactor.js（GitHub Gist）

詢問別人前沒有自己嘗試

有些人在遇到問題時沒有先從網路找資料，而是遇到問題先問同事、前輩。

儘管這樣可以最快速得到解答，但卻少了很多自我思考的部分，長期來講對工程師職涯是非常不健康的。

詢問的問題不夠精確

有時會收到主旨模糊的問題，像是：「這個搜尋功能常常會 fail，可以幫我看看嗎？」

如果可以，收到問題的人會希望問題敘述微調一下：「在人資系統中，我如果在職員列表頁面的搜尋條件中加入部門篩選，會發現搜尋出的結果不合預期，有時會找出其他部門的人員，可以幫我看一下是不是資料庫語法錯誤呢？」

結構為：哪個系統->哪個頁面->你調整了哪些參數->錯誤結果為何->初步判定錯誤來源

管理者權限與使用者權限混在一起

很多系統都會分成前台（一般使用者）以及後台（管理者），有時後端為了增加程式共用率，而讓他們使用同一隻 API 存取資料，如果權限有設計好那沒問題，但如果沒設計好可能就出大包了。

以人資系統來說，假設有一隻 API 是用來存取個人資訊的，API 格式為：「users/{user}」

假使把這隻 API 共用，一般使用者透過修改中間的「user id」就有可能看到其他人的隱私資訊，這在資訊安全上是非常危險的。

因此建議將一般使用者與管理者的 API 切割清楚，避免讓使用者看到權限外的資料。

筆者曾經犯過文章中許多錯誤，沒有人一開始就是強者，但至少要走在變強的道路上。

如果你對目前的職涯感到迷茫，想從不同視角檢視自己的選擇，相信《工程師下班有約》這本書能為你帶來靈感與啟發：

下班有約系列文
▋ [前端]新手工程師容易卡住的問題
▋ [前端＆後端]工程師常犯的錯誤(本篇)
▋ 讓開發團隊更好協作的方式
▋ 談談 Pair Programing
▋ 談談工程師的話語權
▋ 出社會後，新鮮人要及早知道的 5 件事
▋ 面試的性向測驗竟然準到讓人心裡發寒？
▋ 反其道而行的任務分配
▋ 現在的 Daily Scrum 真的適合團隊嗎？
▋ 用低成本也能請到好員工？資深 HR 不想告訴你的秘密！