코드 품질 패턴
잘 설계된 자원 및 비용 최적화에 대해 자세히 알아보기 → 코드 조직
이 통합 패턴 페이지에서는 리소스 최적화에 대한 코드 품질 및 유지 관리 가능성 관행을 다룹니다. 표준 및 사용자 정의 코드 결정, 기술 부채 관리, 설계 표준, 문서화 관행, 거버넌스에 대한 지침이 포함되어 있습니다. 이러한 패턴은 개발 속도를 유지하고, 결함 비율을 줄이고, 솔루션의 장기적인 지속성을 지원합니다.
패턴
| 찾을 위치 | 유사성 |
|---|---|
| 규모에 따른 성능 | ✅ 테스트는 선언적 솔루션이 예상 데이터 볼륨에서 성능 요구 사항을 충족하는지 확인합니다. 실제 데이터가 포함된 전체 사본 Sandbox에서 테스트를 로드하면 프로덕션 배포 전에 확장성이 확인됩니다. |
| 서비스 점검 분석 | ✅ TCO 분석은 향후 팀에 대한 업그레이드 노력, 테스트 요구 사항 및 기술 요구 사항을 비롯한 선언적 및 사용자 정의 접근 방식의 장기 서비스 점검 부담을 비교합니다. |
| 혼합 접근 방식 아키텍처 | ✅ 솔루션은 적절한 경우 선언적 및 프로그래밍 방식의 접근 방식을 결합합니다. 플로는 상위 수준 논리를 오케스트레이션하고, Apex 복잡한 계산을 처리합니다. 수식 필드는 단순 파생을 계산하고 Apex 대량 작업을 처리합니다. |
| AppExchange 평가 | ✅ 사용자 정의 코드를 작성하기 전에 유사한 기능을 제공하는 기존 AppExchange 패키지를 평가하십시오. 검토된 패키지, 기능 차이, TCO 비교를 포함한 문서 평가 결과 |
패턴
| 찾을 위치 | 유사성 |
|---|---|
| 백로그 가시성 | ✅ 명확한 레이블을 사용하여 백로그에서 추적되는 기술 부채 항목, 코드를 개선해야 하는 이유를 설명하는 컨텍스트, 처리되지 않은 상태로 남아 있는 비즈니스 영향, 예상 수정 노력이 있습니다. 보이지 않는 부채는 우선 순위를 지정하거나 관리할 수 없습니다. |
| 증분 개선 | ✅ 기능 개발 중 적용된 Boy Scout 규칙: 찾은 것보다 우수한 코드를 남깁니다. 팀은 대규모 전용 리팩터링 프로젝트가 필요하지 않고 관련 기능 작업 중에 부채를 증분적으로 해결합니다. 코드 검토에서 증분 개선 사항을 확인합니다. |
| 예방 및 조치 | ✅ CI/CD의 품질 게이트는 코드가 프로덕션에 도달하기 전에 표준을 적용합니다. 가져오기 요청 유효성 검사에 통합된 코드 스캐너, ApexGuru, 복잡성 메트릭 차단 문제는 해결될 때까지 병합을 방지합니다. |
안티 패턴
| 찾을 위치 | 불만 사항 |
|---|---|
| 백로그 관리 | ⚡️ 기술 부채는 구두로 인정되었지만 백로그에서 추적되지 않았습니다. 부채 누적을 볼 수 없습니다. 부채 해결은 항상 기능 작업을 위해 지연됩니다. 속도가 점진적으로 하락하고 팀은 이유를 설명할 수 없습니다. |
| 품질 게이트 우회 | ⚡️ CI/CD 품질 게이트는 나중에 수정하려는 일정 압박으로 인해 자주 무시됩니다. “나중에”는 발생하지 않습니다. 코드 스캐너 실패는 알려진 문제로 표시되고 무시됩니다. 불량한 구현을 수용하기 위해 제곱된 복잡성 임계값입니다. |
| 수정 수용력 없음 | ⚡️ 기술적 부채 해결을 위한 수용력이 0인 기능 작업에 할당되는 스프린트 수용력의 100%입니다. 부채는 무기한으로 누적됩니다. 전체 분기를 소비하는 18~24개월마다 주요 리팩터링 프로젝트가 필요합니다. |
| 구성 부채 | ⚡️ 정리 없이 사용자 정의 메타데이터 유형 및 사용자 정의 설정이 누적됩니다. 사용하지 않는 구성은 무기한으로 유지됩니다. 프로덕션에는 50개의 메타데이터 레코드가 있으며 실제로는 12개만 사용됩니다. 구성 값의 목적을 설명하는 문서가 없습니다. |
패턴
| 찾을 위치 | 유사성 |
|---|---|
| 트리거 아키텍처 | ✅ 트리거 처리기 패턴이 일관적으로 적용됩니다. 씬 트리거는 처리기 클래스에 위임하고 처리기 클래스는 트리거 컨텍스트별로 논리를 구성합니다(삽입 전, 업데이트 후), 명확한 메서드 이름은 목적을 보여줍니다. 트리거 파일 자체에는 비즈니스 논리가 없습니다. |
| 서비스 계층 구현 | ✅ 컨트롤러, 트리거 및 배치 항목과 구분된 서비스 클래스에 캡슐화된 비즈니스 논리 중복 없이 여러 진입점에서 서비스 클래스를 재사용할 수 있습니다. 명명 규칙 지우기(AccountService, OrderProcessor). |
| 선택기 패턴 | ✅ 개체당 선택기 클래스(AccountSelector, OpportunitySelector)에서 중앙 집중화된 SOQL 쿼리 선택기 메서드는 일관된 필드 집합을 반환합니다. LDV 최적화 변경 사항이 한 번 적용되어 모든 쿼리에 영향을 미칩니다. |
| 리포지토리 패턴 | ✅ 모의 데이터 소스를 사용하여 테스트할 수 있도록 인터페이스 뒤에 추상화된 데이터 액세스 리포지토리 구현은 쿼리 구축, 캐싱, 최적화 전략을 캡슐화합니다. 비즈니스 논리는 구체적인 구현이 아닌 리포지토리 인터페이스에 따라 다릅니다. |
| 구성 요소 설계 표준 | ✅ Lightning 웹 구성 요소는 단일 책임 원칙을 따르고, 구성에 대한 속성을 노출하고, 상위 커뮤니케이션을 위한 이벤트를 발행하며, 구성 및 재사용을 위해 설계되었습니다. 사용 예가 명시된 구성 요소 라이브러리 |
| 코드 조직 | ✅ 논리 패키지 구조는 관련 클래스를 그룹화합니다. 도메인 논리, 데이터 액세스, API 끝점, 통합 어댑터 간의 구분을 지웁니다. 단방향 패키지 종속성 플로 |
안티 패턴
| 찾을 위치 | 불만 사항 |
|---|---|
| 트리거 | ⚡️ 모든 비즈니스 논리가 심층적으로 중첩된 조건, 우려 사항 분리, 처리기 클래스 없이 트리거 파일에 직접 내장됩니다. 확인, 비즈니스 논리, 통합 호출을 혼합하는 300개가 넘는 줄 트리거 파일 효율적으로 테스트할 수 없습니다. |
| 루프에서 쿼리 | ⚡️ 반복 루프 내에서 실행된 SOQL 쿼리. 소규모 데이터 볼륨에서 작동하지만 대량 작업을 처리할 때 100 SOQL 쿼리 제한을 위반합니다. 트리거가 프로덕션에서 대량 데이터 로드에 실행되는 경우에만 검색됩니다. |
| 루프의 DML | ⚡️ 반복 루프 내에서 실행된 DML 문(삽입, 업데이트, 삭제) 대량 작업으로 150 DML 문 제한을 위반합니다. 각 레코드는 효율적인 대량 처리가 아닌 별도의 데이터베이스 트랜잭션으로 처리됩니다. |
패턴
| 찾을 위치 | 유사성 |
|---|---|
| 아키텍처 결정 레코드 | ✅ 버전 관리에 저장된 ADR에 문서화된 중요한 아키텍처 결정 ADR은 컨텍스트(비즈니스 동인, 기술 제약), 결정(선택된 항목), 고려된 대안(거부 이유) 및 결과(거부, 재방문 조건)를 수집합니다. |