Angular 프로젝트를 구성하는 방법은 무엇입니까? 다음 기사는 Angular 프로젝트 관리에 대한 5가지 실용적인 팁을 모아서 공유합니다. 모든 사람에게 도움이 되기를 바랍니다. 
마스터 과정에 대한 프런트 엔드(vue) 항목: 학습 항목 입력
새로운 기능이 출시됨에 따라 Web apps 점점 더 커지고 있습니다. 회사의 DevOps 여정에서 이러한 종류의 릴리스 변경은 매일 발생합니다. [관련 추천 튜토리얼: "Angular 튜토리얼"]
이렇게 빠른 릴리스 주기에서는 코드가 금방 다루기 어려워질 수 있습니다. 특히 NextJS나 Angular와 같이 JavaScript 기반으로 개발된 프로젝트입니다.
가독성, 유지 관리성 및 확장성을 극대화하기 위해 Angular 프로젝트를 관리하는 5가지 모범 사례는 다음과 같습니다.
많은 단일 애플리케이션 코어는 부풀려진 클래스가 포함된 코드 기반입니다. 본질적으로 이러한 비대한 프로그램은 유지 관리가 어렵습니다. 코드 한 줄을 변경하면 전체 프로그램에 치명적인 영향을 미칠 수 있다는 점에서 취약합니다. 단일 책임 원칙은 이러한 문제를 방지할 수 있습니다.
단일 책임 원칙은 구성 요소가 하나의 기능만을 갖는다는 것을 의미합니다.
이 접근 방식을 사용하여 애플리케이션을 구축하면 애플리케이션이 이러한 코드 블록을 통해 함께 연결되는 모듈식 프레임워크가 생성됩니다.
이 접근 방식을 사용하면 프로그램을 더 읽기 쉽고 유지 관리하기 쉽게 만들 수 있습니다. 또한 응용 프로그램에서 지정된 기능을 쉽게 찾을 수도 있습니다.
귀하의 코드가 이 요구 사항을 충족하는지 확인하려면 다음 질문을 스스로에게 물어보십시오.这代码是干什么的？ 답변에 and 키워드가 포함된 경우 코드를 단일 책임 코드로 리팩터링해야 합니다.
Angular 애플리케이션을 구축하고 확장하는 것은 지속적인 연습입니다. 시간이 지남에 따라 단일 책임 원칙을 사용하여 프로젝트를 구성하면 애플리케이션이 깔끔하고 읽기 쉽고 유지 관리 가능해집니다.
Angular 의 모듈은 단일 원칙을 구현한 것입니다. Angular 에서 각 모듈은 별도의 독립적인 기능을 나타냅니다.
Angular 논리적으로 그룹화하거나 구성하는 방법을 지정하는 여러 유형 모듈을 제공합니다.
핵심
Core 모듈은 애플리케이션을 인스턴스화하고 전역 사용을 위해 핵심 기능을 로드하는 데 사용되는 NgModule 입니다.
따라서 모든 싱글톤 서비스는 코어 모듈에서 구현되어야 합니다. 머리글, 바닥글 또는 탐색 표시줄은 이 유형의 모듈입니다.
애플리케이션당 인스턴스가 하나만 있는 모든 서비스(싱글톤 서비스)는 핵심 모듈에서 구현되어야 합니다. 예를 들어 인증 서비스 또는 사용자 서비스입니다.
특징
함수 모듈은 애플리케이션 기능을 구축하는 코드를 나타냅니다. 예를 들어, 온라인 쇼핑 애플리케이션에서는 장바구니에 품목을 추가하는 기능과 결제를 위한 별도의 모듈이 있습니다.
공유됨
공유 모듈은 새로운 기능을 생성하기 위해 결합될 수 있는 모듈로 구성됩니다. 예를 들어 검색 기능은 플랫폼의 여러 기능에 사용될 수 있습니다.
이런 방식으로 코드를 구조화하면 항목을 더 쉽게 찾을 수 있고 코드 재사용 가능성이 높아집니다.
스타일 파일은 공통 구조를 따르지 않으면 빠르게 정리되지 않을 수 있습니다. 일반적인 모범 사례 패턴 7-1 패턴은 아래와 같이 7 폴더와 1 파일을 사용합니다.
앱 - 프로젝트의 기본 폴더
Abstract - 모든 변수, 믹스인 및 유사한 구성 요소를 포함하는 추상 섹션입니다.
Core - 전체 사이트에 대한 레이아웃, 재설정 및 상용구 코드가 포함되어 있습니다.
구성 요소 - 버튼, 탭, 모달 등 웹 사이트용으로 생성되는 모든 구성 요소에 대한 스타일이 포함되어 있습니다.
레이아웃 - 머리글, 바닥글 등 사이트 레이아웃을 정의하는 데 필요한 파일이 포함되어 있습니다.
페이지 - 각 특정 페이지에 대한 스타일을 포함합니다.
공급업체 - 이 선택적 폴더는 bootstrap 과 같이 프로젝트에서 사용하는 부트스트랩 프레임워크에 적합합니다.
특정 폴더에 대한 모든 할당이 포함된 각 폴더에 새 all.scss 파일을 만듭니다.
많은 서비스가 전 세계적으로 실행되도록 설계되었습니다. 그런 다음 구성 요소에 서비스가 필요한 경우도 있습니다. 전통적인 코딩 구성 요소 관행에서는 단일 책임 원칙을 권장합니다.
이 접근 방식에서는 서비스와 구성 요소가 별도의 프로젝트로 작성됩니다.
하지만 이러한 서비스의 구성 요소 제거를 고려하면 어떻게 될까요? 결국에는 데드 코드가 발생하여 창고가 더욱 복잡해집니다. 이 경우 가장 좋은 방법은 서비스를 구성 요소 내부에 배치하는 것입니다.
이렇게 하면 구성 요소와 서비스를 유지 관리하는 것이 더 쉬워집니다.
중첩된 파일 구조는 모든 코드 파일을 하나의 디렉터리에 저장하는 플랫 파일 시스템보다 본질적으로 탐색하기가 더 쉽습니다.
그러나 프로젝트가 가까워질수록 프로젝트의 파일 구조가 상당히 복잡해질 수 있습니다. 이렇게 하면 코드를 더 쉽게 찾을 수 있지만 import 문을 작성할 때 문제가 발생합니다.
디렉토리 구조가 3~4개 수준 이상으로 커지기 시작하면 import 문이 매우 길어져 읽기 어려울 수 있습니다.
이 문제를 해결하기 위해 tsconfig.json 파일에서 경로의 별칭을 구성할 수 있습니다. 이 파일에는 compilerOptions 라는 배열이 있습니다. 이는 애플리케이션에서 구성하는 경로 별칭입니다.
코드가 컴파일되면 이 배열에 정의된 경로 별칭이 실제 경로로 대체됩니다. 각 경로의 값은 실제 경로와 별칭을 포함하는 키-값 개체입니다.
Angular 애플리케이션을 구축하고 확장하는 것은 지속적인 연습입니다.