如何僱用 Angular 開發人員：需要尋找的關鍵技能和知識

已發表: 2022-09-14

憑藉其高度可擴展的架構，許多 Web 開發團隊選擇 Angular 來創建高效、複雜的單頁應用程序。 但是，僱用 Angular 開發人員說起來容易做起來難。 雖然有很多候選人，但無縫開發體驗的關鍵是找到一位優秀的Angular 開發人員，他應用最佳實踐和先進技術來滿足高質量的編碼標準。

了解有關 Google 流行的前端框架的關鍵概念將使您準備好自信地採訪潛在客戶並聘請最優秀的開發人員 - 那些努力將代碼庫提升到新水平的人。 本文列出了高級 Angular 專業人員應具備的關鍵技能和知識。

TL;博士

高質量的 Angular 候選人將是那些：

  • 了解 Angular 的核心功能。
  • 在他們開始編碼之前進行設計。
  • 了解 Angular 應用程序生命週期。
  • 對反應式編程有紮實的了解。
  • 知道什麼是狀態以及如何使用它。
  • 熟練並支持自動化測試。
  • 隨時了解最新的 Angular 版本。

注意：本指南適用於不再稱為 AngularJS 的最新 Angular 版本——“Angular”自 Angular 2 起就適用。如果您正在招聘維護或升級舊版 AngularJS Web 應用程序項目（1.x分支），查看如何聘請優秀的 AngularJS 開發人員。

了解 Angular 的核心功能

Angular 框架在TypeScript上運行，並且在應用程序中編寫的所有代碼都被轉換為 JavaScript。 TypeScript 是 JavaScript 的超集，可編譯為純 JavaScript。 Angular 代碼由這個超集表示。

許多開發人員學習 Angular，但對 JavaScript、TypeScript、HTML 或 CSS 所需的核心概念缺乏很好的理解。 如果缺少這些基礎，開發人員往往會使用不適當的解決方法，從而增加項目的技術債務。

因此，請詢問候選人是否了解 HTML5 和 CSS3。 一個優秀的 Angular 開發人員不需要是 HTML 或 CSS 專家，只要團隊中的其他人是，但他們應該了解以下關鍵概念：

  • 彈性盒
  • SCSS 變量
  • span和div的區別
  • CSS中的重要類
  • 屬性

Angular 開發人員應該對 JavaScript 和 TypeScript 以及一些 HTML 和 CSS 技能有深入的了解。

鳴叫

編碼前設計

好的設計是好的應用架構的關鍵。 詢問您的候選人他們是如何進行設計的，並將他們的想法與這些理想的考慮因素進行比較：

  • 代碼將去哪裡？ 是否需要新的庫或模塊？
  • 輸入和輸出是什麼？
  • 是否應該有任何可重用的組件或指令？
  • 國家將何去何從？ （在下面的狀態管理下進一步討論。）
  • 業務邏輯將走向何方——即，在哪個服務中？
  • 是否可以在庫之間共享某些組件以創建本質上的 UI 設計系統？

特定設計的全部細節不如候選人是否有製作設計的習慣重要。 所有設計都是臨時的，因此對於大多數應用程序，除非需要正式文檔，否則文檔可以像白板上的素描照片一樣簡單。 在稍後階段，開發人員可以從代碼（使用正確的工具）生成技術設計，以明確所有部分如何相互關聯。

了解 Angular 應用程序生命週期

詢問你的候選人他們對Angular 組件生命週期的了解。 他們的答案應該包括三個生命週期鉤子： ngOnInit 、 ngOnChanges和ngOnDestroy 。 顧名思義，在組件初始化時調用ngOnInit ，在銷毀組件時調用ngOnDestroy ，在屬性更改時調用ngOnChanges 。 後者可以發生在ngOnInit之前——如果在組件完全初始化之前已經分配了屬性，那麼ngOnChanges在ngOnInit之前執行。

如果候選人還知道ngDoCheck 、 ngAfterContentInit 、 ngAfterContentChecked 、 ngAfterViewInit和ngAfterViewChecked ，那麼他們知道組件的所有變更檢測鉤子，並且領先一步。

關於任何鉤子的一個很好的後續問題：“這種變更檢測何時發生？”

左側出現五個帶有向下箭頭的框。除了第四個是綠色的之外，它們都是綠色的，它是藍色的，並且有一個括號擴展成五個向下的盒子，出現在右側（第一個是白色的，其餘的是藍色的）。左邊的方框從上到下依次為：“constructor、ngOnChanges、ngOnInit、ngDoCheck 和 ngOnDestroy”。從“constructor”到“ngOnChanges”的箭頭標記為“Component has bound inputs”，還有一個從“constructor”指向“ngOnInit”的箭頭，標記為“Component沒有綁定輸入”。從“ngOnChanges”到“ngOnInit”的箭頭標記為“首次運行”，還有一個從“ngOnChange”指向“ngDoCheck”的附加箭頭標記為“未首次運行”。一個帶有文本“1+ 數據綁定輸入屬性更改”的白框出現在“ngOnChanges”的左上方並指向它。右側的方框從上到下依次為：“第一次調用？、ngAfterContentInit、ngAfterContentChecked、ngAfterViewInit 和 ngAfterViewChecked。” “第一次打電話？”中的箭頭到“ngAfterContentInit”標記為“是”，並且有一個額外的箭頭指向“第一次調用？”標記為“否”的“ngAfterContentChecked”。從“ngAfterContentChecked”到“ngAfterViewInit”的箭頭標記為“第一次調用”，另外一個箭頭從“ngAfterContentChecked”指向“ngAfterViewChecked”，標記為“不是第一次調用”。
Angular 組件生命週期的概述。

一個鮮為人知的生命週期是提供者生命週期，它只有一個鉤子： ngOnDestroy 。 僅當提供程序附加在組件級別時才會調用此方法，在這種情況下，它會與組件一起被銷毀。 如果它是在根或模塊級別提供的，它將永遠不會被破壞。

提供者的構造函數將在第一次使用提供者時執行，因此構造函數可能永遠不會被執行。 向你的候選人詢問這種可能性——在現實世界的場景中，它可能是一個經常被忽視的錯誤來源！

反應式編程的紮實知識

在 Angular 應用程序中，反應式編程通常是最難理解的部分。 許多人在開始編寫一段代碼時以程序化方式思考，假設它更容易理解和使用，就像食譜的步驟一樣。

反應式編程涉及對我們無法控制的事情做出反應，並且可能以不可預測的順序發生。 儘管我們每天都以這種方式對事物做出反應——例如，當我們前面的汽車突然停下時剎車——但許多開發人員發現很難採用反應式編程方法。

但是，Angular 應用程序中發生的一切都是基於反應式編程的。 例如，Angular 購物應用程序中的一些反應性示例可能包括：

  • 當用戶登錄時，購物車圖標上的數字會更新，並且菜單項會更改為更具體的選項。
  • 當用戶導航到某個類別時，產品會根據所選類別進行更新。
  • 當用戶將產品添加到他們的購物車時，購物車圖標會隨著產品數量而更新。
  • 當商品缺貨時（通過從後端監控當前庫存數量的監聽器註冊），頁面 UI 會更新。

請注意，這些事情會自動發生，不需要頁面刷新即可出現。 在面試中，要求應聘者描述他們如何在他們開發的應用程序中應用反應式編程。 如果候選人描述了涉及刷新頁面或手動調用ChangeDetectorRef.detectChanges()來刷新組件的解決方案，則認為這是一個黃色標誌。

Angular 中 Observables 的陷阱

經驗不足的開發人員有時可能會發現他們在 Angular 應用程序中編寫的代碼沒有被執行。 經驗豐富的 Angular 開發人員可以確定一個常見原因：沒有訂閱Observable ，這是響應式編程中的主要對像類型。 只有訂閱才會執行後端調用或其他反應。

創建訂閱有兩種方法：開發者可以使用async管道或subscribe方法。 但有一點需要注意：如果開發人員手動訂閱（使用subscribe方法），則需要手動銷毀Observable （儘管默認情況下會發生一些極端情況）。 開發人員可以通過多種方式銷毀Observables ：

  • 盡可能使用async管道（這會在不再需要組件時破壞Observable ）。
  • 在組件的生命週期結束時（ ngOnDestroy ）使用Observable上的unsubscribe方法手動取消訂閱。
  • 在pipe操作符中使用takeUntil操作符，並使用主題（即類似destroy$的名稱）以更具聲明性的方式。 在這種情況下，主體在組件的生命週期結束時發出destroy$.next() ( ngOnDestroy )。 在接收到 destroy 事件後， takeUntil操作符將不再接受它所綁定的 Observable 的事件，因此它的訂閱者邏輯將不再被觸發。 例如，請參閱第 2 節中的 takeUntil 運算符。使用take和takeWhile運算符可以公開類似的功能。
  • 由於 Angular 應用程序切換到 Ivy 編譯器，我們也可以使用註解。 until-destroy庫或其他第三方庫（如 SubSink）可用於在組件被銷毀後平滑地取消訂閱 observables。

反應式編程的另一個潛在痛點來自內存洩漏和對後端的多次調用。 詢問候選人是否知道這些問題，以及他們通常會如何解決這些問題。 如上所述，未能取消訂閱Observable可能會導致內存洩漏。 可以通過共享Observable來解決由於後端調用上的多個訂閱而導致的多個後端調用。

了解狀態以及如何使用它

所有的單頁應用程序都有一個狀態，這個狀態在前端的某個地方是可用的。 但是，究竟什麼是狀態？ 它包含特定於當前用戶體驗的所有變量。 例如，經過身份驗證的用戶詳細信息（如姓名和個人資料圖像 URL）、所選的特定菜單項或屏幕列表（如購物車項目列表）。

在 Angular 應用程序中，需要考慮三種主要類型的前端狀態：

狀態範圍
應用整個應用程序可用的一般信息，例如經過身份驗證的用戶、用戶角色、菜單項或用戶的購物籃。 在此狀態下發生的任何變化都會在整個應用程序中發生變化。
模塊對使用服務的整個模塊可用的信息。 每次開發人員使用提供者重用模塊時，它都會為每個提供者創建一個新實例。 狀態永遠不會被破壞，只會在第一次使用給定的提供者時創建。
零件特定組件可用的信息。 組件是應用程序的最小部分。 Angular 應用程序可以有多個組件狀態，但它們只能通過每個組件訪問。 狀態會在組件被創建時創建，在組件被銷毀時被銷毀。

很好地理解什麼是狀態，以及何時應該加載或重新加載，是招聘 Angular 開發人員時要尋找的關鍵技能之一。 如果您的團隊有機會審查候選人編寫的一些示例代碼，這是探索的主要領域。 如果申請人正在使用庫進行狀態管理：

  • 尋找使用 NgRx、Akita、NgXs 或類似的特定於狀態管理的庫。
  • 然後查看相關代碼中是否有effects 、 action 、 reducer 、 store和selector的通知。

我們以 NgRx（與 Akita 等庫類似）中應用程序狀態的大致流程為例：

左上角的白色“選擇器”框向下指向左下角的綠色“組件”框，該框向右指向白色的分層“動作”框。 “Action”框指向一個白色的分層“Reducer”框，右側（帶有虛線箭頭）指向一個白色的分層“Effects”框。 “Reducer”框指向一個藍色的“Store”框，它向左指向“Selector”框。在右下角，“效果”框向左（帶有虛線箭頭）指向“操作”框，然後指向綠色的“服務”框。 “服務”框向下指向“效果”框，向上指向綠色圓柱體堆棧。綠色圓柱體堆棧指向“服務”框。

如果開發人員使用服務創建自己的狀態，他們在狀態管理方面的能力可能更難識別：

  • 搜索對單詞state或effect的引用。
  • 查看代碼是否對某些操作做出反應，例如，如果用戶按下按鈕 A，則屏幕 B 上的文本應更改。

面試官要問的關於國家的問題

通過調查申請人的代碼，您並不總能找到您需要知道的所有內容。 將這些查詢添加到您的問題列表中，以調查潛在的 Angular 開發人員對狀態的理解程度：

  • 你在哪裡使用過state ——以及如何使用？ 這是了解他們的狀態體驗的堅實起點； 不要害怕探究細節。
  • 你如何決定是否使用圖書館？ 如果他們知道在應用程序中包含狀態庫並不總是有用，這是一個好兆頭。
  • 你會在 state 裡面放什麼，你會把它放在哪裡，以及你如何使用 state 管理系統？ 如果他們說，“我把所有東西都放到了我的全局應用程序狀態中”，這是一個明確的跡象，表明開發人員沒有意識到這樣的系統會給應用程序帶來的負面影響。

了解各種狀態類型的開發人員將避免這些副作用：

  • 僅適用於一個組件的狀態可能會被其他組件修改或破壞。
  • 數據嵌套在存儲中，因此很難跟踪數據，並且數據變得不可讀（出於調試、數據交換等目的）。
  • 在表單中編輯數據已經將其發送到應用程序的其餘部分，而它應該只在保存數據時被推送到存儲區——換句話說，應用程序的其餘部分可能正在使用無效數據。

用不了多久，全局存儲就會變得雜亂無章，而且不清楚每個部分的混亂來源，使得調試和維護變得更加困難。

了解自動化測試的重要性

對於任何 Angular Web 應用程序，自動化測試都應該被視為與代碼質量一樣重要。 程序員編寫測試的主要原因之一是記錄他們的代碼：如果新開發人員加入公司，業務邏輯和某些 UI 流程應該根據測試套件的期望明確。 此外，自動化測試會在開發早期發現錯誤。

問你潛在的 Angular 開發者三個測試問題：

  • 你對測試有什麼看法？ 任何不關心自動化測試的候選人都應該停止考慮。 即使他們不喜歡使用測試驅動開發 (TDD)，如果開發人員看不到自動化測試的價值，也會花費您公司的手動測試時間，更糟糕的是，當對應用程序進行更改時出現回歸時最終用戶停機時間隨著時間的推移。
  • 測試時你關注什麼？ 一個優秀的 Angular 開發人員應該專注於測試核心業務邏輯，而不是測試能夠為字段分配值或爭取特定的測試覆蓋率指標（即 85% 的覆蓋率）等基本給定條件。
  • 通常有更多的 E2E 測試還是更多的單元測試？ 為什麼？ 作為前端應用程序，Angular 應用程序可以利用兩種主要的自動化測試：單元測試和端到端（E2E）測試。 通常，一個測試套件將包含許多單元測試和較少的 E2E 測試。 單元測試很小，因此可以快速編寫和執行。 E2E 測試更大更慢。 公平警告：並非所有開發人員都對單元測試和端到端測試的正確比例保持一致。 實際上，這取決於被測試應用程序的複雜性，即便如此，答案在某種程度上還是值得商榷的。

流程圖從左上角開始，帶有一個分開的淺藍色和綠色框。淺藍色部分有文字“你對測試有什麼想法？”綠色部分的文字是“候選人是否關心自動化測試？”從綠色部分，一個“否”箭頭指向一個深藍色的框，上面寫著“候選人沒有合適的測試技能”，一個“是”箭頭指向另一個拆分框。第二個框的淺藍色部分有文字“你在測試時關注什麼？”綠色部分的文字是“候選人是否專注於測試關鍵業務邏輯（超出代碼覆蓋率）？”從綠色部分，一個“否”箭頭指向一個深藍色的框，上面寫著“候選人可能沒有合適的測試技能”，一個“是”箭頭指向另一個拆分框。第三個框的淺藍色部分有文字“通常有更多的 E2E 測試還是更多的單元測試？為什麼？”綠色部分的文字是“候選人是否理解單元測試和端到端測試的重要性和目的？”從綠色部分開始，一個“否”箭頭指向右上方的深藍色框，上面寫著“候選人可能沒有合適的測試技能”，一個“是”箭頭指向右上方的深藍色框，上面寫著“候選人有合適的測試技能”技能。”
為 Angular 開發人員測試面試問題的指南。

角度測試框架

Angular 開發人員在自動化測試框架方面有很多選擇。 可以通過 Jest 或 Jasmine 和 Karma 執行單元測試。 每個 Angular 開發人員都應該熟悉 Jasmine 和 Karma。 Jest 也很常見——它通常更快，並且具有更高級的測試選項。

Angular 應用程序的 E2E 測試標準是 Protractor，這是 Angular CLI 生成的默認工具。 另一種選擇是 Cypress，它是一個有很多選擇的有前途的 E2E 測試框架。

確保候選人對至少一種單元測試框架和一種端到端測試框架有深入的了解。

隨時了解最新的 Angular 版本

偉大的 Angular 開發人員可能由於各種原因並不總是在開發中使用最新版本，但他們應該知道 Angular 的發佈時間表，以便他們能夠及時了解變化並準備好切換。 評估這一點的一種方法是詢問候選人是否熟悉 Angular 的發布策略。 Angular 的目標是每六個月發布一次主要版本，通常在二月和五月左右。 Angular 版本在發布日期後的前六個月內處於“積極支持”狀態，並在發布日期後的 12 個月內處於“長期支持”狀態。 與其他一些技術相比，這是一個相當緊迫的時間表，因此保持最新狀態尤為重要。

你也可以對 Angular 的最新版本進行一些研究，並向你的候選人詢問這些新功能的好處。 例如，大約在 Angular 14 發布的時候，你可能問過候選人：

  • 獨立組件，減少了對 Angular 模塊的需求。 獨立組件沒有在任何現有的NgModule中聲明，它們直接管理自己的依賴項。 因此，可以直接依賴它們而無需中間NgModule 。
  • 類型化表單，Angular 14 中的另一個重大更新，它將嚴格類型設置為 Angular 反應式表單的默認設置。 類型化的表單確保FormControls 、 FormGroups和FormArrays中的值在整個 API 表面上都是類型安全的。 這可以實現更安全的表單，尤其是對於深度嵌套的複雜案例。

您的前端團隊的下一個偉大的 Angular 開發人員

每個 Web 開發項目和團隊都是不同的，並且會對 Angular 開發人員的技能和知識的各個方面給予不同的重視。 但是了解我們在此介紹的基本主題將使招聘經理能夠有意義地參與招聘——即使是技術性更強的評估。

Toptal 工程博客感謝 Ramazan Yildiz 審閱了本文中介紹的技術概念和圖表。