大家好，我是前端西瓜哥，今天来看看简历中阐述项目经历的 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 只是套路，核心还是你过去的经历细节，所以我们应该多尝试去做一些有挑战的事情，这样才有内容可说。
我是前端西瓜哥，欢迎关注我，学习更多前端面试知识。
