이름 짓기가 찾기가 아니다
이제 당신은 7가지 MOAD 패턴을 알고 있습니다. 이름을 아는 것이 중요합니다: 패턴을 볼 때 인식할 수 있게 해줍니다. 하지만 통제된 수업에서의 인식은 처음 열어본 코드베이스에서의 탐지와는 다릅니다.
코드베이스는 결함에 라벨을 붙이지 않습니다. 퇴적층 MOAD는 // O(N²) — 이것을 수정하세요라는 주석이 함께 오지 않습니다. 우레같은 무리는 캐시 미스 폭주로 자신을 알리지 않습니다. 당신은 특정 질문을 염두에 두고 코드를 읽음으로써 그것들을 찾습니다: 이 값들을 담는 데이터 구조는 무엇이고, 루프 내에서 어떤 연산이 그에 대해 실행되나요?
탐지는 인식과 분리된 기술입니다. 인식은 말합니다: 네, 그 패턴은 MOAD-0001입니다. 탐지는 말합니다: 이 코드베이스에서 그 패턴이 존재할 수 있는 모든 곳을 찾아보겠습니다. 전체 코드를 볼 수 있든 기호 이름만 볼 수 있든 상관없이.
첫 번째 스캔
첫 번째 통과는 grep을 사용합니다. 각 MOAD에는 기질이 있습니다: 특정 연산 근처에 존재하며, 조사할 가치가 있는 신호인 데이터 구조 또는 API.
MOAD-0001 (퇴적층): 루프 내의 List.contains
# 신호: 루프 내의 list 변수에 대한 멤버십 테스트
grep -rn '.contains(' src/ | grep -v HashSet | grep -v TreeSet
grep -rn 'visited =' src/ | grep -v set | grep -v SetMOAD-0002 (얽힘): 단계 간 공유되는 가변 플래그
# 신호: 한 서브시스템이 쓰고 다른 서브시스템이 읽는 정적 가변 필드
grep -rn 'static ' src/ | grep -v final | grep -v class | grep -v voidMOAD-0003 (누출된 컨텍스트): 풀링된 실행자의 ThreadLocal
# 신호: 보장된 ThreadLocal.remove() 없이 ThreadLocal.set()
grep -rn 'ThreadLocal' src/
grep -rn 'ThreadLocal.set' src/ -lMOAD-0004 (로그된 비밀): HTTP 헤더가 로그 출력에
# 신호: 인증 끝점 근처의 헤더 변수가 있는 log 호출
grep -rn 'log.*header' src/
grep -rn 'Authorization' src/ --include='*.log'MOAD-0005 (우레같은 무리): 동기화 없는 캐시 미스
# 신호: 잠금 없이 cache.get() + null 검사 + cache.put()
grep -rn 'cache.get' src/ -A4 | grep 'cache.put'이러한 패턴은 확인된 결함이 아니라 후보를 생성합니다. 모든 후보는 분류가 필요합니다: 주변 코드를 읽고, 데이터 구조 타입을 확인하고, 연산이 규모에서 실행되는지 확인하세요.
복잡성을 위한 코드 읽기
Grep은 후보를 찾습니다. 읽기는 이를 확인합니다. 후보 파일을 열 때, 당신은 하나의 질문으로 읽습니다: 이 연산의 비용이 입력 크기와 함께 증가합니까?
MOAD-0001의 경우, 확인 프로토콜:
1. 외부 루프를 찾으세요. 무엇이 반복 횟수를 제한합니까?
2. 내부 연산(.contains, .indexOf, 'in')을 찾으세요. 어떤 데이터 구조에 대해 실행됩니까?
3. 그 데이터 구조가 외부 루프를 구동하는 입력과 함께 증가합니까?
4. 그렇다면: 비용은 O(N²)입니다. 여기서 N = 입력 크기. 확인된 결함.
5. 아니라면: 내부 구조는 제한됨(설정, enum, 작은 상수). 거짓 양성.N개 노드를 방문하는 그래프 순회, 각 단계에서 visited list를 확인: 루프와 내부 데이터 구조 모두 N과 함께 증가합니다. 확인됨.
요청 핸들러가 5명의 관리자 IP의 허용 목록을 확인: 허용 목록은 요청 볼륨과 함께 증가하지 않습니다. 거짓 양성.
동일한 프로토콜이 각 MOAD에 적용됩니다: 외부 드라이버를 식별하고, 내부 구조를 식별하고, 둘 다 함께 확장되는지 묻으세요.
급증 점수: 당신의 발견 우선순위 정하기
확인된 모든 결함이 즉시 패치할 가치가 있는 것은 아닙니다. 10,000명의 다운스트림 의존자가 있는 라이브러리의 MOAD는 private 내부 도구의 동일한 MOAD보다 더 높은 급증 점수를 갖습니다.
급증 점수 = 속도 향상 × 내부 차수. 속도 향상: 일반적인 프로덕션 규모에서 수정이 얼마나 빨라지는가? 내부 차수: 업스트림이 병합할 때 자동으로 수정을 상속받을 다운스트림 패키지 또는 서비스는 몇 개입니까?
Apache Maven의 의존성 해석기에서 확인된 MOAD-0001, 50,000개 노드 그래프에서 실행, 자동으로 변경을 상속받는 1,000개 이상의 다운스트림 Maven 플러그인: 급증 점수가 매우 높습니다. 이 수정은 당신의 큐의 앞에 있어야 합니다.
다운스트림 의존자가 없는 단일 사용자 CLI 도구에서 확인된 MOAD-0001: 급증 점수는 거의 0입니다. 수정할 가치가 있지만, 긴급하지 않습니다.
일중독 대 탐욕스러운 노드. 높은 betweenness & 높은 속도 향상을 가진 노드는 일중독: 중요한 흐름을 처리 & 차단 해제 시 다운스트림 큐를 비웁니다. 다운스트림 용량을 확인한 후에만 패치하세요. 높은 외부 차수 & 낮은 속도 향상을 가진 노드는 탐욕스러운: 제공된 모든 것을 소비하고 고통을 느끼지 않습니다. 일중독을 패치하지 않고 다운스트림 용량을 확인하지 않으면 인프라 규모에서 MOAD-0005(우레같은 무리)를 생성합니다.
스캔에서 병합까지: MOAD 파이프라인
확인된 결함이 높은 급증 점수를 가지면 파이프라인을 통과합니다. 각 단계는 산출물을 생성합니다. 어떤 단계도 선택 사항이 아닙니다.
scan → 후보 목록 (grep 출력, 정적 분석 결과)
ticket → 결함 설명 (MOAD 번호, 위치, 복잡성 분석)
patch → 코드 변경 (데이터 구조 교환, 원시 채택)
test → 단위 테스트 (O(1) 증명: N=100 & N=10,000에서 수정 시간)
UNDF → 공개 공개 게시 (undefect.com, 공개 도메인)
disclose → CVE 또는 CWE 참조(보안 관련인 경우)
PR → 업스트림 pull 요청 (패치 + 테스트 + UNDF 링크)
merge → 유지관리자 수락; 수정이 버전 범프를 통해 전파됨각 산출물은 다음 단계를 공급합니다. 테스트 없는 패치는 확인할 수 없습니다. 공개 없는 테스트는 같은 패턴의 다른 인스턴스로 전파될 수 없습니다. 업스트림 PR 없는 공개는 포크에서 수정을 고립시킵니다.
MOAD 게시(UNDF)는 대부분의 엔지니어가 생략하는 단계입니다. 그들은 결함을 수정하고, PR을 제출하고, 자신들이 완료했다고 간주합니다. 하지만 명명된 게시 없는 수정은 동일한 패턴을 만나는 모든 미래 엔지니어가 문제와 수정을 독립적으로 재발견해야 함을 의미합니다. MOAD 게시는 지식 루프를 닫습니다: 패턴을 이름 지으면, 탐지 방법을 표시하고, & 패치로 연결합니다. 미래 연구자는 패턴 이름을 검색하여 수정을 찾습니다.
규모의 행성 패칭. 광범위하게 사용되는 라이브러리의 단일 MOAD-0001 수정은 이를 가져오는 모든 프로젝트로 전파됩니다. MOAD 게시는 해당 라이브러리를 업그레이드하지 않을 프로젝트의 엔지니어도 수정을 배우도록 합니다. 두 경로는 병렬로 실행됩니다.
결함 티켓 작성
좋은 결함 티켓은 5가지 질문에 답합니다:
1. 어디: 정확한 파일, 클래스, 함수, & 줄 범위
2. 무엇: 데이터 구조 타입 & 그에 대한 연산
3. 왜: 복잡성 분석 (O(N²) 이상, N 정의)
4. 영향: 어떤 입력이 최악의 경우 동작을 트리거하고, 어떤 규모에서
5. 수정: 대체할 데이터 구조 또는 원시5가지 모두에 답하는 티켓은 자급적입니다: 당신의 분석을 읽지 않은 유지관리자도 당신의 발견을 재현하고 당신의 수정을 확인할 수 있습니다. (3) 또는 (4)를 건너뛰는 티켓은 유지관리자가 병합하기 전에 당신의 복잡성 분석을 반복하도록 요구합니다. 그 마찰은 병합 확률을 줄입니다.
신뢰성은 복합적입니다. 명확한 티켓, 잘 목표화된 패치, & 벤치마크 테스트를 포함하는 첫 번째 PR이 병합됩니다. 동일한 작성자의 두 번째 PR은 마찰을 줄이고 검토됩니다. 세 번째 PR은 처음 두 개를 병합한 유지관리자가 검토합니다. 오픈 소스의 명성은 산출물의 원장입니다: 수락된 각 패치는 다음을 위한 신뢰를 얻습니다.
실제 후보 읽기
파이썬에서 실제 MOAD-0001 후보입니다. 이를 읽고 분류 프로토콜을 완료하세요.
class DependencyResolver:
def resolve(self, package, resolved=None, seen=None):
if resolved is None:
resolved = []
if seen is None:
seen = []
if package in seen:
return
seen.append(package)
for dep in self.registry.get_dependencies(package):
self.resolve(dep, resolved, seen)
resolved.append(package)
return resolved분류 질문:
1. `seen`은 어떤 데이터 구조입니까?
2. 6번 줄에서 어떤 연산이 그에 대해 실행됩니까?
3. `seen`은 입력 크기와 함께 증가합니까?
4. 재귀 호출을 구동하는 루프도 입력 크기와 함께 증가합니까?
5. 이것은 확인된 MOAD-0001 또는 거짓 양성입니까?당신의 패치
높은 급증 점수의 확인된 결함에는 완전한 패치가 필요합니다: 코드 수정, 개선을 증명하는 테스트, & MOAD 게시 개요.
테스트는 정확성 테스트가 아니라 성능 테스트여야 합니다. 정확성 테스트는 수정 전후로 통과합니다 — 바로 그것입니다; 출력이 변경되지 않습니다. 성능 테스트는 두 입력 크기에서 개선을 증명합니다:
import time
def build_graph(n):
# n개 패키지, 각각 이전 패키지에 의존
return {f'pkg{i}': [f'pkg{i-1}'] if i > 0 else [] for i in range(n)}
for n in [100, 1000, 5000]:
registry = build_graph(n)
resolver = DependencyResolver(registry)
start = time.perf_counter()
resolver.resolve(f'pkg{n-1}')
elapsed = time.perf_counter() - start
print(f'n={n}: {elapsed:.4f}s')수정 전에, 경과 시간은 n과 함께 이차적으로 증가합니다. 수정 후에, 선형으로 증가합니다. 둘 다 인쇄하고 PR 설명에 숫자를 포함하세요.
MOAD 게시 개요는 다음을 다룹니다: 패턴 이름, 기질(파이썬 의존성 해석기), 탐지 방법(grep for in seen 여기서 seen은 []로 시작), 수정, & PR에 대한 링크. 게시는 undefect.com에 공개 도메인으로 이동합니다. '파이썬 list 멤버십 루프에서 느림'을 검색하는 미래 엔지니어가 찾을 것입니다.