조건부 논리 빠른 비트: 요구 사항 및 엣지 케이스

우리는 시간이 지남에 따라 논리 조건을 읽고 쓰는 능력을 개발하며, 새로운 언어 기능은 새로운 솔루션을 제공할 수 있습니다. 그러나 모든 솔루션이 동일한 것은 아닙니다. 예시를 간단히 살펴보겠습니다.

설정

여러 위치에 존재할 수 있는 속성이 있고 중첩된 인스턴스의 우선순위를 지정하려고 한다고 가정해 보겠습니다. 가능한 해결 방법은 다음과 같습니다.

// Option A: Ternary
const setting = config.user ? config.user.setting : config.setting;

// Option B: Optional Chaining and Nullish Coalescing
const setting = config.user?.setting ?? config.setting;

// Option C: Destructuring and Nullish Coalescing
const { setting } = config.user ?? config;

차이점을 찾아보세요

기능면에서는 꽤 유사해 보이지만 미묘한 차이가 있습니다. 비즈니스 요구 사항이나 데이터 설계에 따라 이들 중 일부는 버그를 일으킬 수 있습니다.

세 가지 옵션을 살펴보고 결과가 달라지는 다양한 시나리오를 식별할 수 있는지 확인하세요. 각 버전에서는 어떤 가정을 하고 있나요?

운영자 분석

먼저, 사용 중인 특정 연산자를 고려하세요.

• Ternary - truth 검사를 사용하여 어떤 표현식이 사용되는지 결정합니다.
• 선택적 체이닝 - 객체가 nullish인 경우 정의되지 않은 값을 반환하지만 단지 falsy인 경우에는 반환하지 않습니다.
• Nullish Coalescing - 첫 번째 표현식이 nullish인 경우 두 번째 표현식을 사용합니다.

무효가 아님

여기서 삼항 연산자가 눈에 띕니다. 대부분의 실용적인 목적을 위해 객체에 대해 이야기할 때 동일한 방식으로 작동합니다. 차이점은 작업이 작동하지 않을 때 예상되는 값에 따라 결정됩니다.

할당되지 않은 개체는 일반적으로 정의되지 않았거나 null입니다. 그러나 프로젝트에서 false 또는 '아직 객체가 아닙니다!'를 사용하는 경우 삼항으로 가정한 결과 원치 않는 결과가 발생할 수 있습니다. 하지만 이는 매우 극단적인 경우입니다.

의도 이해

가능성이 낮은 "비객체" 시나리오를 무시한다면 옵션 A와 C는 기본적으로 동일합니다.

1. config.user가 존재하는 경우 config.user.setting을 가져옵니다.
2. 그렇지 않으면 config.setting을 가져옵니다.

옵션 B는 뭔가 다릅니다.

1. config.user.setting이 있으면 사용하세요.
2. 그렇지 않으면 config.setting을 가져옵니다.

차이는 작지만 요구 사항이나 기술 설계 결정에 직접적으로 영향을 미칩니다. 사용자가 누락된 경우 config.setting으로 돌아가나요, 아니면 user.setting이 누락된 경우에만 돌아가나요?

둘 다 유효한 가능성이지만 잘못된 가정을 하면 기본값을 기대할 때 아무 것도 얻지 못할 수도 있고, 아무것도 기대하지 않을 때 무언가가 나올 수도 있습니다.

결론

여기에는 목표가 무엇인지 묻는 것 외에는 '정답'이 없습니다. 더 많은 맥락이 필요합니다. 이러한 질문을 명확하게 해달라고 요청하는 것은 프로젝트 구성원에게 현학적으로 보일 수 있지만 기대에 부응하지 못하는 경우 이러한 작은 세부 사항은 매우 미묘한 버그를 만들 수 있습니다.

이 프로젝트에 대한 정답이 있을 수도 있고 회사 전체에 대한 정답이 있을 수도 있습니다. 단일 프로젝트에서 여러 옵션을 사용할 수도 있습니다. 가치에 집중하는 것; 또 다른 하나는 구조에 초점을 맞춘 것입니다. 아마도 아무도 이러한 차이점을 고려하지 않았을 것입니다. 어쩌면 팀에서는 서로 일치하지 않는데도 일치한다고 생각할 수도 있습니다.

묻지 않으면 알 수 없습니다.

위 내용은 조건부 논리 빠른 비트: 요구 사항 및 엣지 케이스의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!