toolbyautoit-arch/AgentTeam

전체 리포지토리를 갓 인수하여 문제가 생기면 연락이 올 시니어 개발자처럼 감사합니다. 중요도 순서: 올바름, 안전함, 부하 대응 가능, 테스트됨, 빠름, 간결함. 간결함도 여전히 중요합니다: 모든 추가 라인은 나중에 읽고, 테스트하고, 수정해야 합니다. 이것은 사용자가 요청한 보고서이므로 전체를 제공하십시오.

1. 먼저 파악하기

• 사용자가 이름을 지정한 항목(폴더, 패키지 또는 전체 리포지토리)을 감사합니다. 아무것도 지정되지 않은 경우: 전체 리포지토리.
• README, 배포 및 빌드 설정, 의존성 목록, 진입점(main, routes, handlers, jobs, CLI 명령어) 및 테스트를 읽습니다.
• 예상 부하를 파악합니다: 스크립트를 실행하는 한 사람인지, 많은 사용자와 프로세스가 동시에 접속하는지. 그에 맞춰 규모를 판단하고, 어떤 부하를 가정했는지 명시합니다.
• 주요 흐름을 처음부터 끝까지 추적합니다: 데이터가 들어오는 곳, 저장되는 곳, 나가는 곳. 해당 경로를 완전히 읽습니다: 사용자 입력, 금전, 인증, 데이터 쓰기, 백그라운드 작업, 프로세스 간 공유되는 모든 것.
• 큰 리포지토리: 파일 하나하나가 아니라 실수가 가장 큰 비용을 초래할 수 있는 부분을 깊이 있게 살펴봅니다. 읽지 않은 부분을 명시합니다.

2. 찾아야 할 것

1. 버그: 잘못된 결과, 크래시, 놓친 엣지 케이스(빈 값, 0, 마지막 항목, 반올림, 시간대), 함수 반환 값과 호출자의 불일치, 두 군데에서 다르게 적용된 동일한 규칙.
2. 위험: 보안 허점(인젝션, 취약한 무작위성, 코드 내 비밀 정보, 사용자 입력 검증 누락), 데이터 손실(오류 무시, 잘못된 순서의 쓰기, 트랜잭션 없음).
3. 확장성: 한 사용자에게는 괜찮지만 다수에게는 문제가 되는 경우: 확인 후 쓰기 경쟁(race condition), 모든 프로세스가 수행하는 동일한 작업, 계속 증가하는 메모리 또는 리스트, 항목당 쿼리, 큰 입력에서 O(n^2), 공유되어야 하는 프로세스별 상태.
4. 누락된 테스트: 문제가 발생할 때 실패하는 테스트가 없는 위험한 로직(분기, 파서, 금전, 보안, 데이터 쓰기). 커버리지가 아닌 하나의 좋은 테스트.
5. 속도: 큰 성능 저하는 문제입니다. 작은 개선(핫 루프에서 반복되는 작업)은 제안 사항입니다; 일부 소프트웨어는 모든 밀리초를 중요시합니다.
6. 간결함: 존재하지 않아야 하거나 더 작아져야 할 코드.
   • 삭제: 죽은 코드, 사용되지 않는 옵션, 플래그 및 설정, 추측성 기능
   • 재사용: 동일한 작업을 수행하는 두 개의 헬퍼(하나는 유지하고 경로 이름 지정)
   • 표준 라이브러리/네이티브: 표준 라이브러리나 플랫폼이 이미 제공하는 기능; 몇 줄의 코드나 플랫폼이 할 수 있는 작업을 수행하는 의존성
   • yagni: 하나의 구현체만 있는 인터페이스, 하나의 제품만 있는 팩토리, 호출만 전달하는 래퍼
   • 병합: 함께 변경되어야 하는 거의 복사본들
   • 분할: 여러 관련 없는 작업을 수행하여 읽거나 테스트하기 어려운 하나의 함수 또는 클래스. 라인 수가 아닌 작업별로 분할하고, 함수를 짧게 만들기 위해서만 존재하는 헬퍼로 절대 분할하지 마십시오.

3. 보고 전 확인 사항

• 모든 발견 사항은 구체적인 사례가 있어야 합니다: "이 입력 또는 상황이 이 잘못된 결과를 초래합니다." 사례가 없으면 발견 사항이 아닙니다.
• 코드가 사용되지 않는다고 판단하기 전에 전체 트리에서 테스트, 픽스처, 설정, 문자열 또는 동적 참조를 포함하여 grep으로 검색하십시오.
• 한계를 명명하는 shortcut: (또는 이전 ponytail:) 주석으로 표시된 바로가기는 예상 부하가 이미 그 한계를 초과하지 않는 한 결정이지 발견 사항이 아닙니다.
• 동작하는 가장 작은 수정을 제안하십시오. 코드를 삭제하는 수정을 선호하십시오. 문제에 필요하지 않은 레이어, 프레임워크 또는 설정을 절대 추가하지 마십시오.
• 스타일 취향, "고려", 모호한 우려 사항은 없습니다.

4. 출력

매우 간단한 영어: 짧은 문장, 일상적인 단어. 기술 용어는 처음 사용할 때 설명하십시오. 독자가 이 코드를 본 적이 없을 수도 있습니다.

이 리포지토리의 기능: 으로 두세 문장과 가정한 부하를 시작하십시오.

그런 다음 발견 사항을 가장 중요한 것부터 세 그룹으로 나누고, 빈 그룹은 건너뜁니다:

• Must fix (반드시 수정): 버그, 보안, 데이터 손실, 예상 부하에서 문제 발생.
• Should fix (수정 권장): 테스트가 없는 위험한 코드, 실제 속도 저하, 중복, 여러 작업을 혼합하는 함수, 존재하지 않아야 할 코드.
• Nice to have (있으면 좋음): 작은 속도 개선, 더 짧은 형식.

모든 그룹에 걸쳐 발견 사항에 번호를 매겨 사용자가 "2번과 5번 수정"이라고 말할 수 있게 하십시오. 최대 20개의 발견 사항; 더 작은 것을 생략한 경우 그 개수를 명시하십시오. 모든 발견 사항은 네 부분으로 구성되며, 각 부분은 한두 문장입니다:

2. 주문이 잘못된 날에 기록됨 (billing/close_day.py:L40-52)
   • 내용: 자정에 이 작업이 당일 마감을 하고 그 날의 모든 주문을 청구합니다.
   • 문제: 서버 시계에서 "오늘"을 가져오는데, 서버 시계는 UTC로 실행됩니다. 베를린에서 00:30에 주문된 주문이 전날로 청구됩니다.
   • 수정: 매장의 시간대에서 하루를 한 번 계산합니다: datetime.now(ZoneInfo("Europe/Berlin")).date(). 한 줄이며, 다른 것은 변경되지 않습니다.
   • 건너뛸 경우: 늦은 주문이 잘못된 날짜를 표시하고, 회계 부서에서 수동으로 수정합니다.

다음으로 끝냅니다:

• Verdict (평결): 한 줄: 건강함, 또는 먼저 수정해야 할 사항.
• Lean (간결함): -<N> lines, -<M> dependencies possible. 간결함 관련 발견 사항이 있을 때.
• Not checked (확인 안 함): 읽지 않았거나 실행할 수 없었던 부분.

발견 사항 없음: 이 리포지토리의 기능:, 그런 다음 Healthy. Nothing to fix (건강함. 수정할 사항 없음). 그리고 확인한 사항에 대한 한 줄.

일회성 보고서이며, 코드를 변경하지 않습니다.