프런트엔드 프로젝트를 향상하기 위한 다른 언어 및 프레임워크의 패턴

저는 12년 동안 프로그래밍을 해왔고 다양한 언어로 작업해 왔습니다. 여기에는 C , C++ , Java , Python , C# 및 마지막으로 JavaScript가 포함됩니다. 모든 언어나 프레임워크에는 고유한 규칙이 있습니다. 예를 들어 Rust는 함수 이름에 뱀 대소문자를 사용합니다.

그러나 내가 이해하게 된 특정 규칙, 도구 및 패턴이 있습니다. 나는 이것을 내 프런트엔드 애플리케이션에 통합합니다. 이러한 규칙은 저에게 더 큰 공감을 불러일으키고 코딩 과정을 더욱 원활하게 만들어줍니다. 제가 특히 선호하는 몇 가지 사항은 다음과 같습니다.

함수형 프로그래밍

나의 첫 번째 팁은 내가 처음 배운 언어인 C에서 나왔습니다. 우리가 클래스를 사용하여 React를 작성했던 때를 기억하시나요? 생각만 해도 소름이 돋네요. React가 기능적 구성요소로 전환하자 코드를 더 쉽게 읽을 수 있을 뿐만 아니라 테스트도 더 쉽게 만들었습니다.

또한 함수형 프로그래밍의 원칙과도 더 잘 맞습니다.

이 접근 방식은 재사용 가능한 코드 조각을 만드는 데 중점을 두기 때문에 프런트엔드 프레임워크에서 잘 작동합니다. 프론트엔드 개발에서 함수형 프로그래밍을 사용하는 것은 제가 이 개념을 이해하고 새로운 프론트엔드 기능을 구축하는 데 항상 도움이 되는 전략이었습니다.

함수형 프로그래밍 원칙을 따르는 것은 모든 프런트엔드 애플리케이션에서 필수입니다.

함수형 프로그래밍에 익숙하지 않다면 더 자세히 살펴보는 것이 좋습니다. 이 지점은 이유 없이 이 목록의 시작 부분에 있지 않습니다. 개발 프로세스에 가져올 수 있는 이점은 상당합니다.

코드 포맷터

처음 프로그래밍을 시작했을 때는 코드 형식에 크게 신경을 쓰지 않았습니다. 내 생각엔 모든 것이 흰색 테마의 멋진 CodeBlocks IDE 에서 C++를 배우고 있던 대학에서 시작된 것 같습니다.

GitHub에서 2016년의 이전 코드를 되돌아보면 서식 지정에 공백만 사용했음을 알 수 있습니다. 나는 이것을 자동으로 처리하기 위해 어떤 도구도 사용하지 않았습니다.

이제 나는 그것이 실수였다는 것을 깨달았습니다. 프로젝트에서 무언가를 자동화할 수 있다면 반드시 자동화해야 합니다. 이제는 모든 프로젝트 시작 시 항상 Prettier 와 ESLint를 설정합니다. 이에 많은 시간을 소비하고 싶지 않다면 Airbnb 에서 제공하는 것과 같이 미리 만들어진 구성을 사용할 수 있습니다.

나를 믿으십시오. 후회하지 않을 것입니다!

아, 그리고 IDE에서 파일 저장 시 자동 서식 지정 작업을 설정하는 것을 잊지 마세요!

사전 커밋 작업

이제 멋진 포맷터가 있으므로 자동화해 보겠습니다. 언제 사전 커밋 후크를 사용하기 시작했는지 잘 기억나지 않지만 내 프로젝트에 큰 도움이 되었습니다. 모든 커밋 전에 자동화할 수 있는데 왜 수동으로 포맷해야 합니까? Husky 및 Lint-staged 와 같은 도구를 사용하면 이러한 자동화가 가능합니다.

파일 이름에 대한 Kebab 사례

Angular 에는 많은 팬과 비평가가 있지만 저는 긍정적인 면에 집중하는 것을 좋아합니다. Angular는 대기업과 대규모 애플리케이션에서 가장 먼저 선택되는 경우가 많습니다. 내 생각에 Angular에서 내린 많은 결정은 유지 관리를 쉽게 하기 위한 것이었습니다.

그래서 나는 모든 프론트엔드 프로젝트에 kebab-case를 사용하기로 결정했습니다. 다음과 같은 몇 가지 이점을 제공합니다.

• 단순성 : pascal-case, camel-case 또는 snake-case(원하는 경우) 중 무엇을 사용할지 걱정할 필요가 없습니다. 케밥 케이스에는 옵션이 하나뿐입니다.

• 일관성 : 팀으로 작업하는 경우 kebab-case와 같은 단일 명명 규칙을 채택하면 모든 사람이 동일한 페이지에 있고 프로젝트가 체계적으로 유지되도록 하는 데 도움이 될 수 있습니다. 유니콘 패키지를 사용하여 eslint 규칙을 통해 kebab-case를 강제로 사용할 수 있다는 점을 잊지 마세요.

 'unicorn/filename-case': [ 'error', { case: 'kebabCase', }, ],

• 플랫폼 간 호환성 : 운영 체제에 따라 파일 이름을 다르게 처리합니다. 예를 들어 Windows는 대문자 사용에 관심이 없지만 Linux는 그렇습니다. 소문자와 하이픈을 사용하는 kebab-case를 사용하면 문제가 발생하지 않습니다.

• Git 문제 없음 : Git에서 파일 이름을 소문자에서 대문자로 바꾸는 데 문제가 있습니다. 케밥케이스를 사용하면 그런 걱정은 안하셔도 됩니다.

나는 일을 단순하게 유지하는 것을 좋아합니다. 내 삶을 더 쉽게 만들고 그로부터 약간의 혜택을 얻을 수 있다면 나는 전적으로 그것을 지지합니다.

파일 형식에 태그 사용

내가 Angular에서 빌린 또 다른 것은 파일 이름을 지정하는 방법입니다. Angular는 기능과 유형을 반영하는 방식으로 파일 이름을 지정할 것을 권장합니다. 나는 그것이 프로젝트의 구조를 탐색하고 이해하는 것을 더 쉽게 만든다는 것을 알았습니다. Angular에서 파일 이름은 일반적으로 기능 영역, 파일 역할, 파일 유형의 세 부분으로 구성됩니다.

예를 들어, heroes.component.ts 는 해당 파일이 heroes 기능의 구성 요소이고 TypeScript 파일임을 보여줍니다. heroes.service.ts heroes 위한 서비스입니다.

나는 services 별로 좋아하지 않지만 React 구성 요소에 비슷한 구조를 사용합니다. 예는 다음과 같습니다.

 my-component ├── my-component.component.tsx ├── my-component.type.ts ├── my-component.style.css ├── my-component.spec.tsx └── my-component.story.mdx

나는 또한 후크와 기능에 이 패턴을 사용합니다. 이 패턴은 또한 테스트와 관련된 파일 옆에 테스트를 배치하는 방법을 알려줍니다.

코드 생성 자동화

앞서 언급한 패턴은 매우 유용하지만 자동화를 통해 더 나은 패턴을 만들 수 있습니다. Angular CLI를 사용하면 사용자가 자동으로 코드를 생성할 수 있으며 저는 항상 plop을 사용하여 동일한 작업을 수행합니다. Plop의 템플릿 시스템은 매우 강력하지만 가장 중요한 것은 시간을 절약해 준다는 것입니다.

자동화를 사용하면 구성 요소의 기본 구조에 대해 생각하는 데 많은 시간을 소비할 필요가 없습니다. 이 작업은 자동화될 수 있으므로 내가 정말로 하고 싶은 일에 집중할 수 있습니다.

'도메인' 사용

여기서는 domain 이 무엇인지 자세히 설명하지 않겠습니다. 이에 대해 더 자세히 알고 싶다면 이 기사를 읽어 보시기 바랍니다. 지금 저는 풀스택 개발자 팀과 함께 일하고 있는데 프런트엔드 프로젝트에 도메인 계층을 갖는 것이 정말 유용하다는 것을 알게 되었습니다.

여기에 모든 주요 유형과 작업을 배치합니다. 이는 우리 앱에서 '진실의 원천' 역할을 합니다.

내 앱에서 '도메인'을 처리하는 방법을 보려면 이 문서를 확인하세요. 저는 이 주제를 설명하는 데 많은 시간을 보냅니다.

아키텍처 테스트

Kotlin을 사용하면서 도메인 내부 저장소에 정의된 유형을 사용하는 등 여러 계층에 걸쳐 논리가 혼합되는 문제에 직면한 적이 있습니다. 이는 클린 아키텍처 관점에서 볼 때 불가능한 일이지만 누구나 실수를 합니다.

그때 우리는 아키텍처 단위 테스트를 위한 도구인 ArchUnit을 발견했습니다. 기본적으로 우리가 아키텍처를 올바르게 준수하고 있는지 확인합니다.

특정 아키텍처를 유지 관리하는 경우 어느 시점에서 손상되지 않았는지 확인하는 도구를 갖는 것이 유용할 수 있습니다. 이와 관련하여 dependency-cruiser 와 같은 도구는 매우 중요할 수 있습니다.

이것으로 프런트엔드 프로젝트를 향상시키기 위한 다른 언어 및 프레임워크의 필수 패턴 목록을 마칩니다. 이 정보가 도움이 되기를 바라며, 이러한 전략 중 적어도 하나가 귀하의 작업에 이를 구현하도록 영감을 주었기를 바랍니다.