面試被問項目經驗不用慌，按這個步驟回答絕對驚艷

大家好，我是若川。常有小伙伴問，面試時項目經驗怎么回答，經常會分享這篇文章給TA。本文經授權轉載。面試、學習源碼系列、年度總結、JS基礎系列

前言

本篇文章的作者是來自阿里淘系用戶增長前端團隊的“亦遜”，18年作為雙非本科生通過層層面試，校招進入阿里，今天以過來人的身份給大家分享在面試官問起項目經驗時，該如何回答。

說起面試

說起校招面試，大家總會感覺心慌慌。可能是不自信，可能是感覺好多沒準備好。沒關系，既然投遞了簡歷，又通過了篩選，就不要膽怯。首先要知道面試官都是抱著想把你招進來的想法的，只是想多了解你的具體情況。既然面試官愿意花時間和你聊，那么證明自己還是有實力的，有被看中的閃光點，那么有什么好心虛的呢，勇敢自信的面對就好了。

STAR法則

在寫簡歷和面試過程中，都需要描述工作經驗或個人經歷。優秀的面試者往往會用 STAR 法則來建立個人事件，讓面試官可以更好地通過你過去的經歷來判斷你的個人能力和潛質。

重新回顧一下 STAR 法則四要素：

Situation：事情是在什么情況下發生，基于一個怎樣的背景；
Task：你是如何明確你的任務的；
Action：針對這樣的情況分析，你采用了什么行動方式，具體做了哪些工作內容；
Result：結果怎樣，帶來了什么價值，在整個過程中你學到了什么，有什么新的體會。

往往大部分同學一上來就直接介紹做了什么以及實現的過程，條理也比較清晰，內容也頗具技術含量。但很多同學很容易忽略了 Situation 和 Result 的部分也就是背景和結果。或者是在面試官進一步了解追問細節的時候容易驚慌失措。這些原因往往都是由于面試前對自己的經歷沒有將來龍去脈講清楚以及總結不夠全面和深入。

舉個例子：比如有的同學提到了在 XXX 項目過程中實現了一個 Webpack 插件 XXX，這個插件的功能是 XXXX 并且在 Github 上開源了。整個實現過程和思路都比較清晰，面試官聽的也是饒有興致，甚至回想起年輕時某個夜晚加班研究 Webpack 插件的青澀時光。

盡管這樣面試官也同樣希望了解當時項目的背景，是什么原因導致你要想到通過做 Webpack 插件來解決而不是通過其他工具，以及這個插件給項目帶來了怎樣的價值（是構建性能還是其他？）。背景和結果是面試官非常看重的一部分，必須拿出足夠的理由和價值來說服面試官，否則盡管你在這個項目投入了足夠的精力但最終并沒有為你的面試評價加分，這是十分可惜的。

這時候有的同學也會想：我的項目只是個人/學校的練手項目，對于項目結果我想不到非常有吸引眼球的價值。那么這個時候你不妨說一下你在項目中學到內容，比如在這個 Webpack 插件例子中，就可以說一下：

Compiler 和 Compilation 以及它們的區別；
Webpack 是通過什么方式實現了插件之間的關系以及保證它們的有序性；
開發插件時需要依據當前配置是否使用了某個其他的插件而做下一步決定，如何判斷 Webpack 當前使用了哪些插件；
開發插件過程中借鑒了其他插件的思路，我對這個插件源碼的理解；
等等等等。

以上的在實際開發 Webpack 插件過程中大部分都會遇到，這些問題如果你有記錄和總結也能作為 Result。

面試場景還原

下面筆者場景還原一下項目經歷面試的過程，借助 STAR 法則來簡單介紹一下自己之前在做瀏覽器API兼容性檢查器的過程（通過口述將一件事情清楚描述在面試中也是非常重要的，以下均為口述方式，所以沒有圖）。

面試官：

我看到你在簡歷中提到實現了一個檢查瀏覽器 API 兼容性的工具，可以介紹一下么？

我：

（Situation）好的，當時的情況實際上是一次線上的用戶的輿情反饋說頁面白屏/打不開，通過 JSError 日志的排查我發現最近出現大量類似 InterpObserver is not defined 的日志，同時和我最近一次發布的模塊曝光需求時間線是差不多吻合的，所以很快定位到了是當時使用瀏覽器 InterpObserver API 做 DOM 曝光時沒有考慮到兼容性的問題。

面試官：

那問題解決了么？

我：

是的，當時定位到問題后通過增加 polyfill 的方式很快解決了這個問題。（Task）后來我借著這個問題我自己也進行了思考，其實隨著操作系統和瀏覽器的更新，越來越多的 JS/瀏覽器的新特性開始被支持。為前端開發帶來便利的同時，也會帶來一些不可避免的兼容性問題。兼容代碼（polyfill）的忽視很容易造成不可預估的問題。但如果只依賴開發人員人工檢查兼容性問題并不是最優雅的解決方案，畢竟人工的難免會有遺漏。所以我想是不是能夠開發一個集成現有的兼容性檢查規則的工具將這個過程自動化。

面試官：

不錯，詳細介紹一下具體過程吧。

我：

（Action）恩，這個想法誕生之后我就去了解了一下常用的前端兼容性檢查網站：Caniuse 和 MDN 這兩個是我比較常用的。后來發現這兩個網站的檢查數據實際上在 Github 上都對應維護了一份靜態的檢查規則（caniuse-db 和 mdn-browser-compat-data），這些數據都是具有特定結構的 JSON 文件，盡管這兩者對瀏覽器支持程度描述的方式不太一樣，但已經能滿足得到兼容性數據的基本要求。接下來就是對代碼的分析檢查，將代碼和這些規則進行比較。這個過程需要對代碼進行語法邏輯分析，所以我想到了用 Babel 將代碼轉化成 AST 語法樹進行特定遍歷。同時我整理常規的 API 的調用方式我發現不外乎幾種，比如：NewExpression（構造表達式）和 CallExpression（調用表達式）。當這些信息都掌握清楚后我覺得這件事情是具備技術可行性的。

面試官：

恩，這個實現過程有沒有遇到哪些問題？你是怎么解決的？

我：

（Action）恩有的，剛剛提到 Caniuse 和 MDN 維護的靜態 JSON 數據，我在實現過程中將這兩份數據進行了格式的統一，目的是將兩塊數據進行互補同時方便后續進行檢查比較。最終事實上得到了接近 9w 條數據，如果直接拿來對比是很影響效率的，所以當時利用 browserlist 可以配置指定目標檢查的瀏覽器范圍，比如 iOS Safari 9 以上，通過這一層去過濾在該范圍內沒有兼容性問題的數據，從而減少對比提升效率，也為開發者提供靈活的配置能力。第二個問題同樣也是檢查的性能優化，是通過 isReferencedIdentifier 去檢測標識符是否有被真正引用到。

最后是這個工具與如何接入發布流程的管控，由于公司的發布流程采用的是云構建的方式，所以我在發布之前先經過這個工具的校驗，并且將檢查的結果打通消息通知和郵件系統，（Result）幫助其他人在發布前得到項目代碼的瀏覽器 API 兼容性檢查報告，避免了這類問題的再次出現。這次的經驗幫助我加深了對 Babel 和 AST 的理解。

面試官：

那你了解 Babel parse AST 的過程么？

我：

在解析成 AST 過程中有兩個階段：詞法分析和語法分析。

詞法分析階段：字符串形式的代碼轉換為令牌（tokens）流，令牌類似于AST中的節點；語法分析階段：把一個令牌流轉化為 AST 的形式，同時把令牌中的信息轉化為 AST 的表述結構。

面試官：

你項目中說的 AST 遍歷的過程能再詳細說說么？

我：

Babel 在處理一個節點時，是以訪問者的形式獲取節點信息并進行相關操作。這種方式是通過 Visitor 對象來完成的，Visitor 對象中定義了對于各種節點的訪問函數，這樣就可以針對不同的節點做出不同的處理。比如我在項目過程中主要針對 NewExpression 和 CallExpression 進行處理，通過 path 參數對節點以及節點的父子節點以及進行判斷篩選，balabala。