Angular 개발자를 고용하는 방법: 찾아야 할 핵심 기술 및 지식

확장성이 뛰어난 아키텍처를 통해 많은 웹 개발 팀이 효율적이고 정교한 단일 페이지 애플리케이션을 만들기 위해 Angular를 선택합니다. 그러나 Angular 개발자를 고용하는 것은 말처럼 쉽습니다. 많은 후보자가 있지만 원활한 개발 경험의 핵심은 고품질 코딩 표준을 충족하기 위해 모범 사례와 고급 기술을 적용하는 훌륭한 Angular 개발자를 찾는 것입니다.

Google의 인기 있는 프론트엔드 프레임워크에 대한 핵심 개념을 이해하면 자신 있게 잠재 고객을 인터뷰하고 코드베이스를 한 단계 끌어올리기 위해 노력하는 최고 수준의 개발자를 고용할 수 있습니다. 이 기사는 프리미엄 Angular 전문가가 갖추어야 할 중요한 기술과 지식을 설명합니다.

참고: 이 가이드는 더 이상 AngularJS로 알려지지 않은 최신 Angular 버전에 적용됩니다. "Angular"는 Angular 2 이후로 적용되었습니다. 레거시 AngularJS 웹 애플리케이션 프로젝트(1.x 브랜치)에서 훌륭한 AngularJS 개발자를 고용하는 방법을 확인하세요.

Angular의 핵심 기능 알기

Angular 프레임워크는 TypeScript 에서 실행되며 애플리케이션 내부에 작성된 모든 코드는 JavaScript로 변환됩니다. TypeScript는 일반 JavaScript로 컴파일되는 JavaScript의 상위 집합 입니다. 각도 코드는 이 상위 집합으로 표시됩니다.

많은 개발자가 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 이전에 발생할 수 있습니다. 구성 요소가 완전히 초기화되기 전에 속성이 이미 할당된 경우 ngOnInit 이전에 ngOnChanges 가 실행 ngOnInit .

후보자가 ngDoCheck , ngAfterContentInit , ngAfterContentChecked , ngAfterViewInit 및 ngAfterViewChecked 에 대해서도 알고 있다면 구성 요소에 대한 모든 변경 감지 후크를 알고 있으며 한 발 앞서 있습니다.

후크에 대해 묻는 좋은 후속 질문: "이 변경 감지는 언제 발생합니까?"

덜 알려진 수명 주기는 ngOnDestroy 후크가 하나만 있는 공급자 수명 주기 입니다. 공급자가 구성 요소 수준에서 연결될 때만 호출되며, 이 경우 구성 요소와 함께 소멸됩니다. 루트 또는 모듈 수준에서 제공되는 경우 절대 소멸되지 않습니다.

공급자의 생성자는 공급자가 처음 사용될 때 실행되므로 생성자가 실행되지 않을 수 있습니다. 이 가능성에 대해 후보자에게 퀴즈를 내십시오. 실제 시나리오에서는 종종 간과되는 버그 소스가 될 수 있습니다!

반응형 프로그래밍에 대한 확실한 지식

Angular 애플리케이션에서 반응형 프로그래밍은 종종 이해하기 가장 어려운 부분입니다. 많은 사람들은 코드 프로그래밍을 시작할 때 레시피의 단계처럼 이해하고 작업하기가 더 쉽다고 가정하고 절차적인 방식으로 생각합니다.

반응형 프로그래밍은 우리가 통제할 수 없는 일에 반응하는 것을 포함하며, 이는 예측할 수 없는 순서로 발생할 수 있습니다. 우리는 매일 이런 식으로 반응하지만(예: 앞차가 갑자기 멈출 때 제동) 많은 개발자가 프로그래밍에 반응적인 접근 방식을 취하는 것이 어렵다는 것을 알게 됩니다.

그러나 Angular 앱 내에서 일어나는 모든 일은 반응형 프로그래밍을 기반으로 합니다. 예를 들어 Angular 쇼핑 애플리케이션의 반응성에 대한 몇 가지 예는 다음과 같습니다.

• 사용자가 로그인하면 장바구니 아이콘의 번호가 업데이트되고 메뉴 항목이 보다 구체적인 옵션으로 변경됩니다.
• 사용자가 카테고리로 이동하면 선택한 카테고리에 따라 제품이 업데이트됩니다.
• 사용자가 장바구니에 제품을 추가하면 장바구니 아이콘이 제품 수로 업데이트됩니다.
• 상품이 품절되면(Back End에서 현재 재고 수량을 모니터링하는 리스너를 통해 등록) 페이지 UI가 업데이트됩니다.

이러한 작업은 자동으로 발생하며 페이지를 새로 고칠 필요가 없습니다. 인터뷰에서 후보자에게 자신이 개발한 애플리케이션에 반응 프로그래밍을 어떻게 적용했는지 설명하도록 요청하십시오. 후보자가 페이지를 새로 고치거나 ChangeDetectorRef.detectChanges() 를 수동으로 호출하여 구성 요소를 새로 고치는 것과 관련된 솔루션을 설명하는 경우 노란색 플래그를 고려하십시오.

Angular에서 Observable의 함정

경험이 부족한 개발자는 Angular 애플리케이션에 작성한 코드가 실행되지 않는 경우가 있습니다. 노련한 Angular 개발자는 일반적인 원인을 식별할 수 있습니다. 반응형 프로그래밍의 주요 개체 유형인 Observable 에 대한 구독이 없습니다. 구독이 있는 경우에만 백엔드 호출 또는 기타 반응이 실행됩니다.

구독을 만드는 방법에는 두 가지가 있습니다. 개발자는 async 파이프 또는 subscribe 방법을 사용할 수 있습니다. 그러나 주의 사항이 있습니다. 개발자가 수동 구독( subscribe 메서드 사용)을 수행하는 경우 Observable 을 수동으로 삭제해야 합니다(기본적으로 발생하는 일부 극단적인 경우가 있음에도 불구하고). 개발자는 여러 가지 방법으로 Observables 을 파괴할 수 있습니다.

• 가능한 경우 async 파이프를 사용합니다(구성 요소가 더 이상 필요하지 않을 때 Observable 을 파괴합니다).
• 구성 요소( ngOnDestroy )의 수명이 끝날 때 Observable 에서 unsubscribe 메서드를 사용하여 수동으로 구독을 취소합니다.
• pipe 연산자 내부에 takeUntil 연산자를 사용하고 주제(예: destroy$ 와 같은 이름)를 사용하여 보다 선언적인 방식으로. 이 경우 주체는 구성 요소의 수명이 끝날 때( ngOnDestroy ) destroy$.next() 를 내보냅니다. 파괴 이벤트를 수신한 후 takeUntil 연산자는 구독자 논리가 더 이상 트리거되지 않도록 바인딩된 Observable의 이벤트를 더 이상 수락하지 않습니다. 예를 들어 섹션 2의 takeUntil 연산자를 참조하십시오. take 및 takeWhile 연산자를 사용하여 유사한 기능을 노출할 수 있습니다.
• Angular 애플리케이션이 Ivy 컴파일러로 전환되었기 때문에 주석도 사용할 수 있습니다. until-destroy 라이브러리 또는 SubSink와 같은 다른 타사 라이브러리를 사용하여 구성 요소가 파괴되면 관찰 가능 항목을 원활하게 구독 취소할 수 있습니다.

반응형 프로그래밍의 또 다른 잠재적인 문제는 메모리 누수와 백엔드에 대한 다중 호출에서 비롯됩니다. 후보자에게 이러한 문제를 알고 있는지 그리고 일반적으로 어떻게 해결할 것인지 물어보십시오. 위에서 설명한 대로 Observable 에서 구독 취소에 실패하면 메모리 누수가 발생할 수 있습니다. 백엔드 호출에 대한 여러 구독으로 인해 백엔드에 대한 여러 호출은 Observable 을 공유하여 해결할 수 있습니다.

상태를 알고 사용하는 방법

모든 단일 페이지 애플리케이션에는 상태가 있으며 이 상태는 프런트 엔드의 어딘가에서 사용할 수 있습니다. 그러나 국가란 정확히 무엇입니까? 여기에는 현재 사용자 경험과 관련된 모든 변수가 포함됩니다. 예를 들어 이름 및 프로필 이미지 URL과 같은 인증된 사용자 세부 정보, 선택한 특정 메뉴 항목 또는 장바구니 항목 목록과 같은 화면 목록입니다.

Angular 애플리케이션에는 세 가지 주요 유형의 프런트 엔드 상태를 고려해야 합니다.

상태가 무엇인지, 언제 로드하거나 다시 로드해야 하는지를 잘 이해하는 것은 Angular 개발자를 고용할 때 찾아야 할 핵심 기술 중 하나입니다. 이것은 팀이 후보자가 작성한 몇 가지 예제 코드를 검토할 기회가 있는지 탐색할 주요 영역입니다. 신청자가 상태 관리를 위해 라이브러리를 사용하는 경우:

• NgRx, Akita, NgXs 또는 유사한 상태 관리 관련 라이브러리의 사용을 찾습니다.
• 그런 다음 관련 코드에서 effects , action , reducer , store 및 selector 에 대한 알림이 있는지 확인합니다.

NgRx에서 애플리케이션 상태의 일반적인 흐름(아키타 및 기타 라이브러리의 경우와 유사)을 예로 살펴보겠습니다.

개발자가 서비스로 자신의 상태를 만드는 경우 상태 관리 역량을 식별하기가 더 어려울 수 있습니다.

• state 또는 effect 라는 단어에 대한 참조를 검색합니다.
• 코드가 어떤 동작에 반응하는지 확인하십시오. 예를 들어 사용자가 버튼 A를 누르면 화면 B에서 텍스트가 변경되어야 합니다.

면접관이 상태에 대해 묻는 질문

신청자의 코드를 조사하여 알아야 할 모든 것을 항상 알 수 있는 것은 아닙니다. 잠재적인 Angular 개발자가 상태를 얼마나 잘 이해하는지 조사하려면 다음 쿼리를 질문 목록에 추가하세요.

• state 를 어디에서 어떻게 사용했습니까? 이것은 국가에 대한 그들의 경험을 이해하기 위한 확실한 출발점입니다. 세부 사항을 조사하는 것을 두려워하지 마십시오.
• 도서관 이용 여부는 어떻게 결정하시나요? 애플리케이션에 상태 라이브러리를 포함하는 것이 항상 유용한 것은 아니라는 것을 알고 있다면 좋은 신호입니다.
• 국가 내부에 무엇을 넣고 어디에 넣을 것이며 국가 관리 시스템을 어떻게 활용합니까? "모든 것을 내 전역 응용 프로그램 상태에 넣었습니다"라고 말하면 개발자가 그러한 시스템이 응용 프로그램에 줄 수 있는 부정적인 부작용을 인식하지 못하고 있다는 확실한 신호입니다.

다양한 상태 유형을 이해하는 개발자는 다음과 같은 부작용을 피할 수 있습니다.

• 한 구성 요소에만 적용되는 상태가 다른 구성 요소에 의해 수정되거나 손상될 수 있습니다.
• 데이터는 저장소에 중첩되므로 데이터를 추적하기 어려워지고 데이터는 사람이 읽을 수 없게 됩니다(디버깅, 데이터 교환 등을 위해).
• 양식 내부의 데이터를 편집하면 이미 나머지 응용 프로그램으로 데이터가 내보내지지만 데이터를 저장할 때만 저장소로 푸시해야 합니다. 즉, 나머지 응용 프로그램에서 잘못된 데이터를 사용할 수 있습니다.

전역 저장소가 엉망이 되는 데 오랜 시간이 걸리지 않고 혼란의 각 부분이 어디에서 발생하는지 명확하지 않아 디버그 및 유지 관리가 더 어렵습니다.

자동화된 테스트의 중요성 이해

자동화된 테스트는 모든 Angular 웹 애플리케이션의 코드 품질만큼 중요하게 간주되어야 합니다. 프로그래머가 테스트를 작성하는 주요 이유 중 하나는 코드를 문서화하는 것입니다. 새 개발자가 회사에 합류하면 비즈니스 로직과 특정 UI 흐름이 테스트 제품군의 기대치를 기반으로 명확해야 합니다. 또한 자동화된 테스트는 개발 초기에 버그를 드러냅니다.

잠재적인 Angular 개발자에게 세 가지 테스트 질문을 하세요.

• 테스트에 대해 어떻게 생각하십니까? 자동화된 테스트에 관심이 없는 후보자는 고려를 중단해야 합니다. 테스트 주도 개발(TDD)을 사용하지 않는 것을 선호하더라도 자동화된 테스트의 가치를 깨닫지 못하는 개발자는 회사의 수동 테스트 시간을 낭비하게 되며, 더 나아가 앱이 변경될 때 회귀가 나타날 때 최종 사용자 다운타임이 발생합니다. 시간이 지남에 따라.
• 테스트할 때 중점을 두는 부분은 무엇인가요? 필드에 값을 할당하거나 특정 테스트 커버리지 메트릭(예: 85% 커버리지)을 위해 노력하는 것과 같은 기본 제공 사항을 테스트하는 대신 훌륭한 Angular 개발자는 핵심 비즈니스 로직 테스트에 집중해야 합니다.
• 일반적으로 더 많은 E2E 테스트 또는 더 많은 단위 테스트가 있습니까? 왜요? 프론트 엔드 애플리케이션으로서 Angular 앱은 단위 테스트와 종단 간(E2E) 테스트의 두 가지 주요 자동화 테스트를 활용할 수 있습니다. 일반적으로 테스트 스위트에는 많은 단위 테스트와 더 적은 수의 E2E 테스트가 있습니다. 단위 테스트는 작기 때문에 작성 및 실행이 빠릅니다. E2E 테스트는 더 크고 더 느립니다. 공정한 경고: 유지해야 할 단위 및 E2E 테스트의 올바른 비율에 대해 모든 개발자가 동일한 의견을 갖는 것은 아닙니다. 실제로는 테스트하는 앱의 복잡성에 따라 달라지며, 그렇다고 해도 답은 어느 정도 논란의 여지가 있습니다.

각도 테스트 프레임워크

Angular 개발자는 자동화된 테스트 프레임워크에 대해 선택할 수 있습니다. 단위 테스트는 Jest 또는 Jasmine 및 Karma를 통해 수행할 수 있습니다. 모든 Angular 개발자는 Jasmine과 Karma에 익숙해야 합니다. Jest도 일반적입니다. 일반적으로 더 빠르고 고급 테스트 옵션을 제공합니다.

Angular 애플리케이션의 E2E 테스트 표준은 Angular CLI에서 생성한 기본 도구인 Protractor입니다. 대안은 다양한 옵션이 있는 유망한 E2E 테스트 프레임워크인 Cypress입니다.

응시자가 최소한 하나의 단위 테스트 프레임워크와 하나의 E2E 테스트 프레임워크에 대한 심층 지식을 가지고 있는지 확인하십시오.

최신 Angular 릴리스 정보 받기

Great Angular 개발자는 다양한 이유로 개발 시 최신 버전을 사용하지 않을 수 있지만 변경 사항을 파악하고 전환할 준비를 할 수 있도록 Angular 릴리스 일정을 알아야 합니다. 이를 평가하는 한 가지 방법은 후보자에게 Angular의 릴리스 전략에 대해 잘 알고 있는지 묻는 것입니다. Angular는 일반적으로 2월과 5월에 6개월마다 주요 릴리스를 목표로 합니다. Angular 릴리스는 릴리스 날짜 후 첫 6개월 동안 "능동 지원" 상태이며 릴리스 날짜 이후 12개월 동안 "장기 지원" 상태입니다. 이는 다른 기술에 비해 상당히 촉박한 일정이므로 최신 상태를 유지하는 것이 특히 중요합니다.

또한 최신 버전의 Angular에 대해 조사하고 후보자에게 이러한 새로운 기능의 이점에 대해 물어볼 수도 있습니다. 예를 들어 Angular 14가 출시될 즈음에 지원자에게 다음과 같은 질문을 했을 수 있습니다.

• Angular 모듈의 필요성을 줄이는 독립 실행형 구성 요소. 독립 실행형 구성 요소는 기존 NgModule 에서 선언되지 않으며 자체 종속성을 직접 관리합니다. 결과적으로 중간 NgModule 필요 없이 직접 의존할 수 있습니다.
• Typed Forms, Angular Reactive Forms의 기본값으로 엄격한 입력을 설정하는 Angular 14의 또 다른 주요 업데이트입니다. 형식화된 양식은 FormControls , FormGroups 및 FormArrays 내부의 값이 전체 API 표면에서 형식이 안전한지 확인합니다. 이것은 특히 깊게 중첩된 복잡한 경우에 더 안전한 양식을 가능하게 합니다.

프론트엔드 팀을 위한 차세대 Angular 개발자

모든 웹 개발 프로젝트와 팀은 다르며 Angular 개발자의 기술과 지식의 다양한 측면에 대해 다른 중요성을 부여합니다. 그러나 여기에서 제시한 기본 주제를 이해하면 고용 관리자가 더 많은 기술 평가에서도 고용에 의미 있게 참여할 수 있습니다.

Toptal 엔지니어링 블로그는 이 기사에 제공된 기술 개념과 다이어그램을 검토한 Ramazan Yildiz에게 감사를 표합니다.