조건부 연결 방지/리팩토링

JavaScript 애플리케이션을 개발할 때 가장 흔한 코드 냄새 중 하나는 조건부 연결이 과도하다는 것입니다. 이번 글에서는 이러한 사례를 아키텍처와 코드를 통해 어떻게 예방할 수 있는지에 대해 논해보고 싶습니다.

목차

1. 소개
2. 조건부 체인의 이해
3. 조건부 체인의 문제점
4. 조건부 체인 리팩토링
5. 아키텍처를 통한 조건부 체인 방지
6. 프런트엔드 개발 모범 사례
7. 결론

조건부 체인이란 무엇입니까?

과도한 조건부 연결은 JavaScript 애플리케이션에서 흔히 나타나는 코드 냄새입니다. 이 문서에서는 향상된 아키텍처 및 코딩 방법을 통해 이러한 사례를 방지하고 리팩토링하는 방법을 살펴봅니다.

조건부 체인은 함수나 메서드에서 조건을 표현하는 데 사용되는 과도한 논리 연산자입니다. React 애플리케이션을 사용한 예를 살펴보겠습니다.

위의 예에서 볼 수 있듯이 이 코드가 렌더링되는 방식을 지정하는 세 가지 조건 체인이 있습니다.
조건은 다음과 같습니다.

1. 스포츠 목록에 요소가 있는 경우 기본 요소를 렌더링해야 합니다.
2. 구성 요소의 로드 상태가 true인 경우 로드 스켈레톤이 렌더링되어야 합니다.
3. 스포츠 목록에 요소가 없으면 빈 상태를 렌더링해야 합니다.

이 코드에는 두 가지 주요 문제가 있습니다.

1. 배열의 길이를 확인하고 "&&" 연산자를 사용할 때 배열의 길이와 관련된 값이 있는 경우 구성 요소를 렌더링해야 한다고 자바스크립트에 지시합니다. 배열이 없는 경우 이 값은 null이거나 정의되지 않아야 합니다. 그러나 배열이 존재하고 길이가 0인 경우 요소 대신 숫자 0이 렌더링됩니다. 왜냐하면 자바스크립트에 연결된 값을 렌더링하도록 요청하기 때문입니다. 배열의 길이입니다.
2. 이 두 요소의 렌더링을 제어하기 위해 체인을 사용할 필요는 없습니다. 구성 요소의 "기본" 상태를 렌더링하기 전에 조건을 추가하면 이 상황을 처리하는 더 우아한 방법이 될 것입니다.

리팩토링

위 코드의 리팩토링 버전은 다음과 같습니다.

이것은 JavaScript의 논리 연산자를 사용하여 조건부 연결을 처리하는 여러 방법 중 하나입니다. 위 코드에서 볼 수 있듯이 코드의 조건부 초과 문제를 해결하기 위해 비공통적인 접근 방식을 사용했습니다.

그!! JavaScript의 연산자는 값을 부울로 변환하는 데 사용됩니다. JavaScript에는 참값과 거짓값이 있다는 사실을 활용합니다. 첫 번째! 연산자는 값을 부정하여 참 값을 거짓으로, 거짓 값을 참으로 바꿉니다. 두 번째! 이를 다시 무효화하여 원래 값의 부울 표현이 생성됩니다. 이는 문자열, 숫자 또는 개체와 같은 값을 진실성 또는 거짓성을 기준으로 부울 값(true 또는 false)으로 변환하는 데 자주 사용됩니다.

예:

!!"Hello"는 비어 있지 않은 문자열이 진실이기 때문에 true로 평가됩니다.
!!0은 0이 거짓이므로 거짓으로 평가됩니다.

아키텍처 결정을 통해 이러한 일이 발생하지 않도록 방지

이것을 원칙으로 삼아서는 안 되지만, 조건부 체인이 생성되는 대부분의 경우 초과된 조건은 동적 값을 구문 분석하고 처리하려고 합니다. 왜냐하면 정적 값을 다루는 경우 구현이 다음과 같은 경향이 있기 때문입니다. 훨씬 더 간단하고 간단해졌습니다.

데이터베이스를 모델링할 때 소프트웨어의 종속성에 대해 몇 가지 우려 사항이 있어야 합니다.

사람들은 일반적으로 IT 대학 공부를 통해 이러한 의존성 연구를 배우는데, 이에 대해 설명하겠습니다.

소프트웨어에는 두 가지 종속성이 있습니다.

1. 기능적 종속성 - 이러한 종속성은 버튼, 화면, 입력, 양식 등과 같이 사용자가 상호 작용하는 기능이므로 사용자에게 직접적인 영향을 미칩니다.
2. 비기능 종속성 - 이러한 종속성은 주로 오류 처리, 조건, 비즈니스 규칙, 유효성 검사 등과 같은 백엔드 종속성이므로 일반 사용자는 일반적으로 알아채지 못합니다.

프런트엔드 과잉 통제 방지

백엔드는 시스템의 모든 논리 부분을 담당해야 하므로 대부분의 기능 종속성은 프런트엔드 화면이나 사용자 상호 작용이 아닌 백엔드 기능에 의해 처리되어야 합니다.

새로운 기능을 개발하기 시작하고 소품, 인터페이스, 매개변수 등 기능이 작동하는 데 필요한 것이 무엇인지 이해하려면 무엇이 필수이고 무엇이 선택 사항이며 무엇이 아니어야 하는지 염두에 두어야 합니다. 사용했습니다.

개발 세션 중에 하지 말아야 할 일의 예로 위의 예를 사용해야 합니다. 보시다시피 이 인터페이스에는 선택적 매개변수만 있지만 이 구성요소에 "어쩌면" 변수만 첨부될지는 의문입니다.

구성 요소를 개발하고 프런트엔드 애플리케이션에 혼란스러운 코드를 푸시하기 전에 구성 요소가 어떻게 작동해야 하는지 이해해야 합니다. 많은 조건을 처리하는 대신 구성 요소에서 사용할 것과 사용하지 않을 것을 결정하면 더 쉽습니다.

더 잘 생각해 보면 다음과 같은 결론이 나올 것입니다.

이제 인터페이스에는 앱 내에서 구성 요소의 전체 수명 동안 확실히 사용될 필수 매개 변수만 있으며, 이전의 구성 요소처럼 정의하거나 사용할 수 없는 많은 선택적 매개 변수는 없습니다.

결론

조건부 체인을 방지하고 리팩토링하면 더 깔끔하고 유지 관리하기 쉬운 코드가 만들어집니다. 구성 요소의 요구 사항을 이해하고, 적절한 경우 논리를 백엔드로 전환하고, 명확한 인터페이스를 설계함으로써 프런트엔드 코드에서 복잡한 조건부 체인의 필요성을 크게 줄일 수 있습니다.

삼성 메모리가 Unsplash에 올린 사진

위 내용은 조건부 연결 방지/리팩토링의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!