Angular 開発者を雇う方法: 探すべき主要なスキルと知識

公開: 2022-09-14

高度にスケーラブルなアーキテクチャを持つ多くの Web 開発チームが、効率的で洗練されたシングルページアプリケーションを作成するために Angular を選択しています。しかし、Angular 開発者を雇うことは、言うは易く行うは難しです。多くの候補者がいますが、シームレスな開発経験の鍵は、ベストプラクティスと高度な技術を適用して高品質のコーディング基準を満たす優れた Angular 開発者を見つけることです。

Google の人気のあるフロントエンドフレームワークの主要な概念を理解することで、自信を持って見込み顧客にインタビューし、最高の能力を持つ開発者 (コードベースを次のレベルに引き上げようと努力している開発者) を雇う準備が整います。この記事では、優れた Angular プロフェッショナルが持つべき重要なスキルと知識について説明します。

TL;DR

高品質の Angular 候補者は、次のような人です。

Angular のコア機能を理解する。
コーディングを始める前に設計します。
Angular アプリケーションのライフサイクルを理解します。
リアクティブプログラミングに関する確かな知識があること。
状態とは何か、その使用方法を理解します。
自動テストに熟練し、サポートします。
最新の Angular リリースに関する最新情報を入手してください。

注: このガイドは、AngularJS として知られなくなった最新の Angular バージョンに適用されます。「Angular」は Angular 2 以降に適用されています。従来の AngularJS Web アプリケーションプロジェクト (1.xブランチ)、How to Hire a Great AngularJS Developer をチェックしてください。

Angular のコア機能を知る

Angular フレームワークはTypeScriptで実行され、アプリケーション内で記述されたすべてのコードは JavaScript にトランスパイルされます。 TypeScript は、プレーンな JavaScript にコンパイルされる JavaScript のスーパーセットです。 Angular コードは、このスーパーセットによって表されます。

多くの開発者は Angular を学んでいますが、JavaScript、TypeScript、HTML、または CSS で必要とされる主要な概念を十分に理解していません。これらの基盤が欠けていると、開発者は不適切な回避策を使用する傾向があり、プロジェクトの技術的負債が増大します。

そのため、候補者に HTML5 と CSS3 の知識があるかどうかを尋ねます。優れた Angular 開発者は、チームの他の誰かが HTML や CSS の専門家である必要はありませんが、次の重要な概念を理解している必要があります。

フレックスボックス
SCSS 変数
spanとdivの違い
CSS の重要なクラス
属性

Angular の開発者は、HTML と CSS のスキルだけでなく、JavaScript と TypeScript についても十分に理解している必要があります。
つぶやき

コーディング前の設計

優れた設計は、優れたアプリケーションアーキテクチャの鍵です。候補者にどのようにデザインを作成したかを尋ね、彼らの考えを次の理想的な考慮事項と比較します。

コードはどこに行きますか？新しいライブラリまたはモジュールが必要ですか?
インプットとアウトプットは何ですか？
再利用可能なコンポーネントまたはディレクティブが必要ですか?
国はどこへ行くのか？ (以下の状態管理で詳しく説明します。)
ビジネスロジックはどこに、つまりどのサービスに組み込まれるのでしょうか。
特定のコンポーネントをライブラリ間で共有して、本質的に UI デザインシステムを作成できますか?

特定のデザインの完全な詳細は、候補者がデザインを作成する習慣があるかどうかよりも重要ではありません。すべてのデザインは一時的なものであるため、ほとんどのアプリケーションでは、正式な文書が必要でない限り、文書はホワイトボード上のスケッチの写真と同じくらい簡単です。後の段階で、開発者は (適切なツールを使用して) コードから技術設計を生成し、すべてのパーツがどのように相互に関連しているかを明確にすることができます。

Angular アプリケーションのライフサイクルを理解する

候補者に、 Angular コンポーネントのライフサイクルについて知っていることを尋ねてください。彼らの答えには、 ngOnInit 、 ngOnChanges 、およびngOnDestroyの 3 つのライフサイクルフックが含まれている必要があります。名前が示すように、 ngOnInitはコンポーネントの初期化時に呼び出され、 ngOnDestroyはコンポーネントが破棄されたときに呼び出され、 ngOnChangesは属性が変更されたときに呼び出されます。後者はngOnInitの前に発生する可能性があります — コンポーネントが完全に初期化される前に属性が既に割り当てられている場合、 ngOnInit の前にngOnChangesが実行されngOnInit 。

候補者がngDoCheck 、 ngAfterContentInit 、 ngAfterContentChecked 、 ngAfterViewInit 、およびngAfterViewCheckedについても知っている場合、彼らはコンポーネントのすべての変更検出フックを知っており、一歩先を行っています。

フックのいずれかについて尋ねる良いフォローアップの質問: 「この変更検出はいつ行われますか?」

下向きの矢印が付いた 5 つのボックスが左側に表示されます。それらはすべて緑色で、4 番目は青色で、右に表示されるさらに 5 つの下向きのボックスに展開するブラケットがあります (最初のボックスは白で、残りは青です)。左のボックスには、上から順に、「constructor、ngOnChanges、ngOnInit、ngDoCheck、および ngOnDestroy」と表示されています。「コンストラクター」から「ngOnChanges」への矢印には「コンポーネントにはバインドされた入力があります」というラベルが付けられ、「コンポーネントにはバインドされた入力がありません」というラベルの付いた「コンストラクター」から「ngOnInit」への追加の矢印があります。「ngOnChanges」から「ngOnInit」への矢印には「最初の実行」というラベルが付いており、「ngOnChange」から「最初の実行ではない」というラベルの付いた「ngDoCheck」への追加の矢印があります。「1+ data-bound input properties change」というテキストの白いボックスが「ngOnChanges」の左上に表示され、それを指しています。右側のボックスには、上から順に、「初めて呼び出されましたか?、ngAfterContentInit、ngAfterContentChecked、ngAfterViewInit、および ngAfterViewChecked」と表示されています。「初めて呼ばれた？」の矢。「ngAfterContentInit」への「はい」というラベルが付けられ、「初めて呼び出されましたか?」から指し示す追加の矢印があります。「いいえ」というラベルの付いた「ngAfterContentChecked」に。「ngAfterContentChecked」から「ngAfterViewInit」への矢印には「初回呼び出し」というラベルが付いており、「ngAfterContentChecked」から「ngAfterViewChecked」への追加の矢印は「初めての呼び出し」というラベルが付いています。 — Angular コンポーネントのライフサイクルの概要。

あまり知られていないライフサイクルはプロバイダーのライフサイクルで、フックはngOnDestroyの 1 つだけです。これは、プロバイダーがコンポーネントレベルでアタッチされている場合にのみ呼び出されます。この場合、プロバイダーはコンポーネントと共に破棄されます。ルートまたはモジュールレベルで提供されている場合、破棄されることはありません。

プロバイダーのコンストラクターは、プロバイダーが初めて使用されるときに実行されるため、コンストラクターが実行されない可能性があります。この可能性について候補者に質問してください。実際のシナリオでは、見過ごされがちなバグの原因になる可能性があります。

リアクティブプログラミングの確かな知識

Angular アプリケーションでは、リアクティブプログラミングが最も理解しにくい部分であることがよくあります。多くの人は、コードのプログラミングを開始するときに、レシピの手順のように、理解しやすく操作しやすいと仮定して、手続き的な方法で考えます。

リアクティブプログラミングには、制御できないものへの反応が含まれ、それは予測できない順序で発生する可能性があります。私たちは毎日このように反応していますが (たとえば、目の前の車が急停止したときにブレーキをかけるなど)、多くの開発者は、プログラミングに対して反応的なアプローチを取るのが難しいと感じています。

ただし、Angular アプリ内で発生するすべてのことは、リアクティブプログラミングに基づいています。たとえば、Angular ショッピングアプリケーションでのリアクティブの例としては、次のようなものがあります。

ユーザーがログインすると、ショッピングカートアイコンの数字が更新され、メニュー項目がより具体的なオプションに変わります。
ユーザーがカテゴリに移動すると、選択したカテゴリに応じて製品が更新されます。
ユーザーが商品をカートに追加すると、ショッピングカートアイコンが商品の数で更新されます。
アイテムが在庫切れになると (バックエンドから現在の在庫数を監視するリスナーを通じて登録されます)、ページ UI が更新されます。

これらは自動的に行われ、表示するためにページを更新する必要がないことに注意してください。面接で、候補者に、開発したアプリケーションにリアクティブプログラミングをどのように適用したかを説明してもらいます。候補者が、ページを更新する、またはChangeDetectorRef.detectChanges()を手動で呼び出してコンポーネントを更新することを含む解決策を説明している場合は、黄色のフラグと考えてください。

Angular での Observable の落とし穴

経験の浅い開発者は、Angular アプリケーションで記述したコードが実行されないことに気付くことがあります。ベテランの Angular 開発者は、共通の原因を特定できます。それは、リアクティブプログラミングの主力オブジェクトタイプであるObservableにサブスクリプションがないことです。サブスクリプションがある場合のみ、バックエンドコールまたはその他の反応が実行されます。

サブスクリプションを作成する方法は 2 つあります。開発者はasyncパイプまたはsubscribeメソッドを使用できます。ただし、注意点があります。開発者が ( subscribeメソッドを使用して) 手動でサブスクリプションを行う場合、 Observableを手動で破棄する必要があります (ただし、デフォルトで発生するエッジケースがいくつかあります)。開発者は、複数の方法でObservablesを破棄できます。

可能な場合はasyncパイプを使用します (これにより、コンポーネントが不要になったときにObservableが破棄されます)。
コンポーネントの有効期間の終了時に、 Observableでunsubscribeメソッドを使用して手動で登録解除します ( ngOnDestroy )。
pipe演算子内のtakeUntil演算子とサブジェクト (つまり、 destroy$のような名前のもの) を使用して、より宣言的な方法で。この場合、サブジェクトはコンポーネントの有効期間 ( ngOnDestroy ) の最後にdestroy$.next()を発行します。 destroy イベントを受け取った後、 takeUntilオペレーターは、バインドされている Observable からのイベントを受け入れなくなり、サブスクライバーロジックがトリガーされなくなります。例については、セクション 2 の takeUntil オペレーターを参照してください。同様の機能をtakeおよびtakeWhileオペレーターで公開できます。
Angular アプリケーションが Ivy コンパイラに切り替わったため、アノテーションも使用できます。コンポーネントが破棄されると、 until-destroyライブラリまたは SubSink のような別のサードパーティライブラリを使用して、オブザーバブルからスムーズにサブスクライブを解除できます。

リアクティブプログラミングのもう 1 つの潜在的な問題点は、メモリリークとバックエンドへの複数の呼び出しです。志願者に、これらの問題を認識しているかどうか、通常はどのように解決するかを尋ねます。上記のようにObservableからのサブスクライブ解除に失敗すると、メモリリークが発生する可能性があります。バックエンド呼び出しでの複数のサブスクリプションによるバックエンドへの複数の呼び出しは、 Observableを共有することで解決できます。

状態とその使用方法を知る

すべての単一ページアプリケーションには状態があり、この状態はフロントエンドのどこかで利用できます。しかし、正確には状態とは何ですか？これには、現在のユーザーエクスペリエンスに固有のすべての変数が含まれています。たとえば、名前やプロフィール画像の URL などの認証済みユーザーの詳細、選択された特定のメニュー項目、ショッピングカートの項目のリストなどの画面上のリストなどです。

Angular アプリケーションでは、考慮すべき 3 つの主なタイプのフロントエンド状態があります。

州	範囲
応用	認証されたユーザー、ユーザーの役割、メニュー項目、ユーザーのショッピングバスケットなど、アプリケーション全体で利用できる一般的な情報。この状態で変更すると、アプリケーション全体が変更されます。
モジュール	サービスが使用されるモジュール全体で利用可能な情報。開発者がプロバイダーでモジュールを再利用するたびに、各プロバイダーの新しいインスタンスが作成されます。状態が破棄されることはなく、特定のプロバイダーが初めて使用されるときにのみ作成されます。
成分	特定のコンポーネントで利用可能な情報。コンポーネントは、アプリケーションの最小部分です。 Angular アプリケーションは複数のコンポーネントの状態を持つことができますが、各コンポーネントを介してのみアクセスできます。状態は、コンポーネントが作成されたときに作成され、コンポーネントが破棄されたときに破棄されます。

Angular 開発者を採用する際に求められる重要なスキルの 1 つは、状態とは何か、状態をいつロードまたはリロードする必要があるかをよく理解することです。チームが候補者によって書かれたサンプルコードを確認する機会がある場合、これは探索するのに最適な領域です。申請者が状態管理のために図書館を使用している場合:

NgRx、Akita、NgXs、または同様の状態管理固有のライブラリの使用を探します。
次に、関連するコードにeffects 、 action 、 reducer 、 store 、およびselectorの通知があるかどうかを確認します。

例として、NgRx のアプリケーション状態の一般的なフロー (Akita や他のライブラリのフローに似ています) を見てみましょう。

左上の白い「セレクター」ボックスは、左下の緑の「コンポーネント」ボックスを指し、このボックスは、白い階層化された「アクション」ボックスを右に指しています。「アクション」ボックスは、白のレイヤー化された「リデューサー」ボックスを指し、右 (点線の矢印) は白のレイヤー化された「エフェクト」ボックスを指します。「レデューサー」ボックスは青い「ストア」ボックスを指し、その左は「セレクター」ボックスを指します。右下の [Effects] ボックスは、左 (点線の矢印) で [Action] ボックスを指し、上は緑色の [Service] ボックスを指しています。「サービス」ボックスは、「効果」ボックスを指し、緑色のシリンダースタックを指します。緑色のシリンダースタックは、「サービス」ボックスを指しています。

開発者がサービスを使用して独自の状態を作成すると、状態管理における開発者の能力を特定するのが難しくなる可能性があります。

stateまたはeffectという単語への参照を検索します。
コードが何らかのアクションに反応しているかどうかを確認します。たとえば、ユーザーがボタン A を押すと、画面 B のテキストが変化するはずです。

インタビュアーが州について尋ねる質問

申請者のコードを調査するだけでは、必要な情報がすべてわかるとは限りません。これらのクエリを質問リストに追加して、潜在的な Angular 開発者が状態をどの程度理解しているかを調査します。

stateをどこで、どのように使用しましたか? これは、状態に関する彼らの経験を理解するための確かな出発点です。詳細を調べることを恐れないでください。
図書館を利用するかどうかをどのように決定しますか? 状態ライブラリをアプリケーションに含めることが常に有用であるとは限らないことを彼らが知っている場合、それは良い兆候です。
州内に何を置き、どこに置き、州管理システムをどのように利用しますか? 彼らが「すべてを自分のグローバルアプリケーション状態に置く」と言った場合、これは開発者が、そのようなシステムがアプリケーションに与える可能性のあるマイナスの影響を認識していないことを示しています。

さまざまな状態の種類を理解している開発者は、次の副作用を回避できます。

1 つのコンポーネントにのみ適用される状態は、他のコンポーネントによって変更または破損される可能性があります。
データはストア内でネストされているため、データを追跡するのが難しくなり、データは人間が判読できなくなります (デバッグ、データ交換などの目的で)。
フォーム内のデータを編集すると、すでにアプリケーションの残りの部分に送信されていますが、データを保存するときにのみストアにプッシュする必要があります。つまり、アプリケーションの残りの部分が無効なデータを消費している可能性があります。

グローバルストアがまとまりのない混乱になるまでにそれほど時間はかかりません。混乱の各部分がどこから発生したのかが明確ではないため、デバッグと保守が難しくなります.

自動テストの重要性を理解する

自動テストは、あらゆる Angular Web アプリケーションのコード品質と同じくらい重要であると考えるべきです。プログラマーがテストを作成する主な理由の 1 つは、コードを文書化することです。新しい開発者が会社に加わった場合、ビジネスロジックと特定の UI フローは、テストスイートの期待に基づいて明確にする必要があります。また、自動化されたテストにより、開発の早い段階でバグが明らかになります。

潜在的な Angular 開発者に 3 つのテスト用の質問をします。

テストについてどう思いますか？ 自動化されたテストを気にしない候補者は、検討を中止する必要があります。テスト駆動開発 (TDD) を使用したくない場合でも、自動化されたテストの価値を理解していない開発者は、会社の手動テストの時間を犠牲にし、さらに悪いことに、アプリに変更が加えられたときにリグレッションが発生すると、エンドユーザーのダウンタイムが発生します。時間とともに。
テストで気をつけていることは何ですか？ 優れた Angular 開発者は、フィールドに値を割り当てたり、特定のテストカバレッジメトリクス (つまり、85% のカバレッジ) を求めたりするなどの基本的な条件をテストするのではなく、コアビジネスロジックのテストに集中する必要があります。
通常、より多くの E2E テストまたは単体テストがありますか? なんで？ フロントエンドアプリケーションとして、Angular アプリは、ユニットテストとエンドツーエンド (E2E) テストの 2 種類の自動テストを利用できます。通常、テストスイートには単体テストが多く、E2E テストは少なくなります。単体テストは小さいため、作成と実行が高速です。 E2E テストは大規模で低速です。公正な警告: すべての開発者が、維持するユニットテストと E2E テストの正しい比率について同じ意見を持っているわけではありません。実際には、テストするアプリの複雑さに依存し、その場合でも答えはある程度議論の余地があります.

フローチャートは左上から始まり、分割された水色と緑のボックスがあります。水色の部分には、「テストについてどう思いますか?」というテキストがあります。緑色の部分には、「候補者は自動テストに関心がありますか?」というテキストがあります。緑の部分から、「いいえ」の矢印は「受験者は適切なテストスキルを持っていません」と書かれた紺色のボックスを指し、「はい」の矢印は別の分割されたボックスを指しています。 2 番目のボックスの水色の部分には、「テスト時に何を重視しますか?」というテキストがあります。緑色の部分には、「候補者は主要なビジネスロジックのテストに重点を置いていますか (コードカバレッジのパーセンテージを超えていますか)?」というテキストがあります。緑の部分から、「いいえ」の矢印は「受験者は適切なテストスキルを持っていない可能性があります」と書かれた紺色のボックスを指し、「はい」の矢印は別の分割されたボックスを指しています。 3 番目のボックスの水色の部分には、「通常、E2E テストまたは単体テストが多いのはなぜですか?」というテキストがあります。緑色の部分には、「候補者は単体テストとエンドツーエンドテストの両方の重要性と目的を理解していますか?」というテキストがあります。緑の部分から、「いいえ」の矢印は「受験者は適切なテストスキルを持っていない可能性があります」と書かれた濃い青色のボックスに向かって右上を指し、「はい」の矢印は「受験者は適切なテストを持っている」と書かれた濃い青色のボックスに向かっています。スキル。」 — Angular 開発者向けのインタビューの質問をテストするためのガイド。

Angular テストフレームワーク

Angular 開発者は、自動テストフレームワークに関して選択肢があります。単体テストは、Jest または Jasmine と Karma を使用して実行できます。すべての Angular 開発者は、Jasmine と Karma に精通している必要があります。 Jest も一般的です。Jest は一般的に高速で、より高度なテストオプションを備えています。

Angular アプリケーションの E2E テスト標準は、Angular CLI によって生成されるデフォルトツールである Protractor です。代替手段は、多くのオプションを備えた有望な E2E テストフレームワークである Cypress です。

候補者が、少なくとも 1 つの単体テストフレームワークと 1 つの E2E テストフレームワークについて深い知識を持っていることを確認してください。

フロントエンドチームのための次世代の優れた Angular 開発者

すべての Web 開発プロジェクトとチームは異なり、Angular 開発者のスキルと知識のさまざまな側面に異なる重要性を置きます。しかし、ここで紹介した基本的なトピックを理解することで、採用担当者は、より技術的な評価であっても、採用に有意義に参加できるようになります。

Toptal Engineering Blog は、この記事で提示された技術的な概念と図をレビューしてくれた Ramazan Yildiz に感謝の意を表します。