大家好，我是前端西瓜哥，今天來看看簡歷中闡述項目經歷的 STAR 法則是什麼。

STAR 法則是什麼？

我們寫簡歷中的項目經歷時，一種常見的思路就是 STAR 法則。

STAR 是四個單詞的首字母和組合。STAR 是一個有意義的單詞 「星星」，更容易記住。類似的還有設計模式中的 SOLID 原則，它們也是不同設計原則名字取首字母的組合。

STAR 的組成為：

• S（Situation）情境；
• T（Task）任務；
• A（Action）行動；
• R（Result）結果

它們組合起來就是：

我遇到了某個場景，場景下出現了哪些問題（S）？此時你承擔的角色或任務是（T）？為此，你做了什麼具體的行動（A）？結果如何（R）？

其實它就是講故事，有上面這些成分可以讓故事更有條理，能讓面試官掌握你做工作及其帶來的價值。同時，STAR 法則能讓你的經歷更精煉，可以在寸金寸土的簡歷上寫上更多的內容。

通過 STAR 法則寫的經歷，能讓面試官或 HR 更好地挖掘應聘者的過去經歷，來預測未來，更好地判斷其是否更適合崗位。

下面以我自己做前端國際化需求為例子，寫一個基於 STAR 法則的描述。

因為首次加載網站時資源太大，用戶體驗較差（S），我做了國際化的性能優化（T），將原本全量加載的語言包優化為按需加載（A），減少了 1M 的壓縮後體積，降低了用戶的等待時間（R）。

關於結果

關於結果，最好用一些數字來闡明，因為人天生對數字敏感，能夠人更直觀的感受。比如

• 重構後，Bug 率下降了 50%；
• 網站首屏加載時間從 3s 優化為 2s；

但大多數人都是打雜前端開發，工作經常都是接產品的活，排期完成需求並交付，和一線用戶還是有一些距離，結果通常並不明確、不透明或不好量化。

有什麼辦法拯救一下呢？

• 去關注功能交付的結果，比如過一段時間詢問下產品，這次交付帶來了什麼好評或是不足，或是在一些用戶群收集一些反饋；
• 對於像是性能優化的工作，我們可以關注一些指標的變化。如果公司有指標系統，可以看看上線功能前後的變化情況。如果沒有，可以自己藉助一些工具，從中提取出數據；

但切忌不要虛構數據，面試官稍微深入問一下就露餡了。

實在沒有結果，那就把結果去掉好了。

結尾

STAR，指的是場景（S）、任務（T）、A（行動）和 R（結果），用於指導我們結構化、精煉地描述自己的項目經驗，是值得學習掌握的法則。

STAR 只是套路，核心還是你過去的經歷細節，所以我們應該多嘗試去做一些有挑戰的事情，這樣才有內容可說。

我是前端西瓜哥，歡迎關注我，學習更多前端面試知識。