데이터베이스 스토리지 엔진을 속도와 호환성을 해치지 않고 고치기

## 오류와 동시성을 올바르게 다루는 읽기 쉬운 코드 작성 의미 있는 이름을 사용하고 명확하지 않은 불변 조건에는 주석을 달아 명료하고 자체 문서화되는 코드를 작성하십시오. 한계가 작은 속도 향상만 제공하는 영리한 기법보다 읽기 쉬운 제어 흐름을 우선하십시오. 저장소의 포매터, 명명 규칙, 구조적 패턴을 따르십시오. 프로젝트의 표준 상태 또는 오류 타입을 일관되게 사용하십시오. 실패한 작업을 식별할 수 있도록 충분한 맥락과 함께 실패를 전파하십시오. 오류나 확인하지 않은 상태 값을 절대로 아무 알림 없이 버리지 마십시오. 프로덕션 경로에서 복구 가능한 실패를 처리하는 데 단언문을 사용하지 마십시오. 잘못된 입력, 리소스 고갈, 입출력 실패, 손상, 부분 진행을 다루십시오. 키 순서, 스냅샷 가시성, 내구성, 복구 동작과 같은 데이터베이스 의미 체계를 보존하십시오. 동기화 가정은 그 가정이 보호하는 데이터 옆에 문서화하십시오. 잠금, 원자적 연산, 메모리 순서, 경쟁 상태 위험, 교착 상태 위험을 함께 검토하십시오. 성공, 오류, 취소, 종료 경로 모두에서 리소스 정리를 명시적으로 처리하십시오. 주석은 특정 호출자의 현재 근거보다 로컬 계약에 초점을 맞추십시오. 공유 추상화가 안정적이고 일관된 책임을 가질 때 반복되는 로직을 중복 제거하십시오. 실패 경로와 동시성 동작을 테스트하기 전에는 정확성에 민감한 변경을 병합 준비 완료로 표시하지 마십시오. ## 실행 빈도에 맞춰 최적화하고 벤치마크로 확인 성능에 대한 고려를 스토리지 엔진 작업의 필수 요건으로 다루십시오. 처음부터 건전한 알고리즘과 데이터 구조를 선택하되, 미세 최적화보다 먼저 정확성을 확립하십시오. 영향을 받는 코드를 실행 빈도에 따라 분류하십시오. - 핫 경로에서는 모든 할당, 복사, 분기, 캐시 미스의 비용이 빈번한 작업 전체에 걸쳐 누적됩니다. - 웜 경로에는 명료성과 속도 사이의 측정된 균형이 필요합니다. - 콜드 경로는 프로파일링에서 유의미한 비용이 확인되지 않는 한 유지보수성을 우선합니다. 성능 주장은 벤치마크와 프로파일링 데이터로 뒷받침하십시오. 적절한 기준선과 비교하고 워크로드, 구성, 변동성을 보고하십시오. 정당한 경우 재사용, 사전 할당, 아레나 또는 메모리 풀을 통해 핫 경로의 동적 할당을 줄이십시오. 불필요한 복사보다 이동, 뷰, 참조, 제자리 연산을 우선하십시오. 지역성을 높이도록 데이터와 접근 패턴을 배치하고 거짓 공유를 피하십시오. 불변 작업을 반복 구간 밖으로 옮기고, 반복 작업을 일괄 처리하며, 예측하기 어려운 분기를 줄이십시오. 분기 가능성 힌트는 일반적인 구성이 아니라 실제로 드물거나 비용이 큰 경우에만 사용하십시오. 명시적 내장 함수를 사용하기 전에 적절한 데이터 배치를 통해 컴파일러 벡터화를 활성화하십시오. 명시적 SIMD는 지원되고 효과가 측정되며 유지보수 가능한 경우에만 사용하십시오. 낮은 오버헤드를 유지하면서 누수를 방지하려면 RAII와 명확한 소유권을 적용하십시오. 재현 가능한 이점이 없는 복잡한 최적화는 유지하지 마십시오. ## 한 가지 역할만 하는 옵션으로 호환되는 API 설계 상위 수준 정책은 호출자나 정책 계층에 두십시오. 하위 계층에서는 정확하고 재사용 가능한 메커니즘을 제공하십시오. 범용 코드가 특정 호출자의 정체성이나 근거에 의존하게 하지 마십시오. 각 플래그나 매개변수에 일관된 하나의 동작만 부여하십시오. 소유권, 캐싱, 입출력 모드, 프리페치를 한데 묶는 불리언은 명시적 필드나 옵션 객체로 대체하십시오. 캐시 핸들이나 리더 상태 같은 부수적인 구현 세부 사항에서 정책을 추론하지 마십시오. 계약을 강제할 수 있도록 단언문, 더 좁은 인터페이스, 더 명확한 이름을 사용하십시오. 새 API는 기존의 명명법, 매개변수 순서, 반환 타입, 오류 처리 방식과 일관되게 만드십시오. 적절한 경우 고정 폭 정수 타입과 범위가 지정된 열거형을 포함해 타입 안전한 옵션을 사용하십시오. 옵션 값을 검증하고 명확한 오류를 반환하십시오. 동적 구성 변경을 스레드 안전하게 만들고 변경이 언제 적용되는지 확인하십시오. 호환성을 깨야 할 특별한 정당성이 없다면 소스 및 바이너리 호환성을 보존하십시오. 공개 바이너리 인터페이스가 노출될 때는 레이아웃, 심볼, 호출 규약을 검토하십시오. 문서화된 다중 릴리스 절차에 따라 사용 중단을 진행하고 마이그레이션 지침을 제공하십시오. 공개 API에는 사용법, 매개변수의 의미, 스레드 안전성 규칙, 성능 비용, 호환성 참고 사항을 문서화하십시오. 서드파티 구현 타입을 공개 API를 통해 내보내지 마십시오. ## 선행 기록식 로깅 등 위험한 부분일수록 깊이 검토 선행 기록식 로깅, 메모리 테이블, 컴팩션, 복구 및 기타 데이터베이스 핵심 경로에는 가장 심층적인 검토를 적용하십시오. 다양한 구성, 컴팩션 방식, 실패, 동시 워크로드에서 핵심 변경을 테스트하십시오. 컴팩션이 설정된 제한을 준수하고 빈 파일 집합이나 단일 파일 상황을 처리하는지 확인하십시오. 공개 헤더를 호환성에 가장 큰 영향을 주는 영역으로 다루십시오. 영속적인 테이블 및 블록 형식을 장기간 유지되는 데이터 계약으로 다루십시오. 압축 선택, 블록 크기, 손상 상황, 호환성 경계 전반에서 체크섬을 검증하십시오. 반복자의 탐색, 다음, 이전, 삭제, 끝점 의미 체계를 테스트하십시오. 캐시 키를 고유하게 유지하고 프리페치가 리소스 제한을 준수하는지 확인하십시오. 핫 경로에서 실행될 수 있는 테이블, 캐시, 유틸리티 변경을 벤치마크하십시오. 캐시 동기화, 메모리 소유권, 축출 정책을 명시적으로 정의하십시오. 선택적 유틸리티를 데이터베이스 내부 구성 요소와 분리하십시오. 옵션의 타입 안전성, 검증, 사용 중단, 스레드 안전한 동적 업데이트를 확인하십시오. 내부 유틸리티의 오버플로, 언더플로, 잘못된 입력, 단언 계약을 테스트하십시오. 단위, 통합, 스트레스 테스트 및 벤치마크 증거 없이는 형식, 복구, 컴팩션, 캐시에 대한 고위험 변경을 승인하지 마십시오. ## 모든 빌드 시스템을 맞추고 지원하는 모든 플랫폼에서 빌드 소스 파일을 추가하거나 제거할 때 지원되는 모든 빌드 시스템을 유지보수하십시오. 먼저 정본 소스 매니페스트를 업데이트한 다음 승인된 생성기로 파생 빌드 파일을 다시 생성하십시오. 생성된 내부 빌드 파일을 직접 편집하지 마십시오. 영향받는 참조를 모든 빌드 정의, 언어, 문서, 구현에서 검색하십시오. 리소스 제한 안에서 병렬 빌드에 호스트의 CPU 개수를 사용하십시오. 서로 다른 빌드 모드가 호환되지 않는 객체 파일을 재사용하지 못하게 하십시오. 수동 빌드에는 구성 변경 시 빌드 시스템이 자동으로 정리하는 메커니즘을 활성화하십시오. 프로젝트의 운영 체제, 컴파일러, 표준 라이브러리, 새니타이저, 빌드 모드 조합을 지원하십시오. 구성된 경우 Linux, macOS, Windows, 네이티브 및 크로스 컴파일러, 릴리스 빌드, 새니타이저, 유니티 빌드, 언어 바인딩을 고려하십시오. 플랫폼 API를 직접 사용하는 것보다 프로젝트의 이식성 추상화를 우선하십시오. 피할 수 없는 플랫폼별 헤더, 호출, 속성, 내장 기능에는 가드를 적용하십시오. 전이적 포함에 의존하지 말고 모든 표준 헤더를 직접 포함하십시오. 프로젝트 제약 조건이라면 프로덕션 및 스트레스 실행 파일이 런타임 타입 정보 없이 빌드되도록 하십시오. 런타임 다운캐스트는 테스트로 제한하고, 다른 곳에서는 프로젝트의 검사된 정적 캐스트 도우미를 사용하십시오. 지원되지 않는 문자와 기타 지속적 통합 비호환 콘텐츠를 거부하는 소스 검사를 실행하십시오. 저장소에서 요구하는 경우 소스 주석과 문자열에 ASCII 문장 부호를 사용하십시오. ## sleep에 의존하지 않고 실패를 재현할 수 있는 테스트 작성 테스트 깊이를 위험에 맞추십시오. 격리된 동작에는 단위 테스트, 상호 작용에는 통합 테스트, 동시성과 성능에는 스트레스 테스트를 사용하십시오. 경계, 오류 경로, 복구, 플랫폼 차이, 회귀 상황을 다루십시오. 입력은 다르지만 테스트하는 계약이 같다면 테이블 기반 사례를 사용하십시오. 반복되는 생성, 왕복 처리, 단언 시퀀스를 위한 도우미를 추출하십시오. 결정론적 경계 사례를 무작위 커버리지와 분리하십시오. 더 넓고 유용한 커버리지를 제공한다면 매개변수의 모든 조합보다 무작위 표본 추출을 우선하십시오. 프로젝트의 난수 소스를 사용하고 실패를 재현할 수 있도록 시드를 출력하십시오. 동시성 이벤트를 기다리는 동안 sleep으로 시간을 지연하지 마십시오. 동기화 지점이나 명시적 신호를 사용하여 스레드 진행을 제어하십시오. 각 단위 테스트 실행에 정의된 시간 제한을 적용하십시오. 소수의 집중 테스트는 직렬로 실행하고 더 큰 집합은 병렬 테스트 하네스를 통해 실행하십시오. 강제 컨텍스트 전환 조건에서 새 동시성 테스트를 반복해서 스트레스 테스트하십시오. 프로젝트의 전용 재현 도구를 사용하여 지속적 통합에서만 발생하는 간헐적 실패를 조사하십시오. 경로, API, 컴파일러, 빌드 플래그의 영향을 받는 지원 대상 플랫폼을 모두 테스트하십시오. 테스트 실패가 이를 유발한 구성을 재현할 수 있을 만큼 충분한 상태를 보고하도록 하십시오. 새 구성 옵션과 성능 기능을 스트레스 테스트 및 벤치마크 커버리지에 추가하십시오. 제출 전에 업데이트된 테스트에서 중복과 의도하지 않은 공유 상태를 검토하십시오. ## 라이선스 헤더를 붙이고 문서와 릴리스 노트를 맞추기 모든 새 소스 파일에 저장소가 요구하는 라이선스 헤더를 추가하십시오. 파생 파일에는 프로젝트 헤더와 더불어 업스트림 저작권 고지를 보존하십시오. 각 소스 언어에 올바른 주석 접두사를 사용하십시오. 필수 이중 라이선스 지정을 일반적인 권리 고지로 대체하지 마십시오. 변경 후 자동 포맷을 실행하고 생성된 차이를 검토하십시오. 종속성 유지보수 도구를 실행하고 관련 없는 매니페스트 변경을 거부하십시오. 기능을 추가할 때 핫 경로 회귀를 유발하지 않으면서 유용한 지표를 평가하십시오. 성능 관련 기능은 표준 벤치마크 도구를 통해 제공하십시오. 릴리스 노트는 짧고 외부에 공개되도록 하며 사용자에게 보이는 동작에 집중하십시오. 하위 시스템의 색인과 주제별 장에 구성 요소 설계를 문서화하십시오. 필요한 경우 생성된 사이트나 게시물이 유효한 작성자 메타데이터를 참조하는지 확인하십시오. 새 API, 옵션, 사용 중단에는 저장소의 전용 절차를 따르십시오. 사용 중단된 영역을 제거하기 전에 마이그레이션 지침을 업데이트하십시오. 구현, 빌드 메타데이터, 테스트, 문서, 릴리스 노트를 동기화된 상태로 유지하십시오. 새 소스 파일이 한 빌드 시스템에서는 접근 가능하지만 다른 빌드 시스템에서는 누락된 상태로 두지 마십시오. ## 클린 빌드와 테스트를 통과한 뒤 변경 승인 정확성, 테스트, 성능, 호환성, 계약 경계, 스타일, 문서를 각각 별도의 기준으로 검토하십시오. 성능에 민감한 변경에는 벤치마크 결과를 요구하십시오. 새로운 동시성 또는 구성 가능 동작에는 스트레스 테스트 커버리지를 요구하십시오. 집중 검사가 통과한 후 전체 클린 빌드 및 테스트 대상을 실행하십시오. 무시된 오류 결과를 탐지하는 더 엄격한 상태 검사 빌드를 실행하십시오. 변경된 빌드 플래그가 오래된 객체를 재사용하지 못하도록 자동 정리 모드를 사용하십시오. 빌드 시스템의 기계 판독 가능한 진행률 출력을 통해 장시간 테스트 실행을 모니터링하십시오. 단계, 완료된 작업, 전체 작업, 실패, 백분율, 제한된 실패 세부 정보를 추적하십시오. 단언 실패를 충돌, 신호, 시간 초과, 인프라 오류와 구분하십시오. 보고된 증거와 함께 벤치마크 매개변수 및 테스트 구성을 보관하십시오. 측정을 위해 벤치마크를 릴리스 모드로 빌드하십시오. 충돌을 진단할 때 디버그 빌드로 전환한 다음 다시 측정하기 전에 클린 빌드를 수행하십시오. 영향받는 영역에 필요한 포맷, 소스, 빌드, 테스트, 새니타이저, 플랫폼 검사를 실행하십시오. 검토 후 수정 사항의 직접적인 영향을 받는 기준을 다시 실행하십시오. 일부 일치 항목이 관련 없어 보인다는 이유만으로 저장소 전반의 일관성 검색 범위를 좁히지 마십시오. 코드, 계약, 테스트, 빌드 메타데이터, 문서, 측정된 증거가 일치할 때만 승인하십시오.