개인회고
CSS 회고
Continue
Start
Stop
stash 날려서 git임시파일 하나나 뒤적거렸던 때를
생각하면 아직도 눈앞이 흐려진다....(결국 임시파일에도 없었다)🥹
트러블 슈팅 기록
프로젝트 외적으로 발생했던 문제들을 기록해 놓는다.
git stash 문제
git stash
git checkout feat/ffeeaatt
git stash pop <----- 문제 확인! 작업한 파일 중 어떤 파일들이 아예 담겨있지 않았다.stash conflict 이해하기
[분기 전 커밋] 파일 A (원본)
│
├── 원래 브랜치: 파일 A 수정 → stash
└── feat/ffeeaatt: 파일 A가 다른 내용으로 이미 변경되어 있음stash pop 할 때 feat/ffeeaatt의 파일 A와 stash 속 파일 A가 충돌해서, git이 해당 파일 적용을 포기한 것으로 아직
stash list에 남아있는 상태였을 것으로 추측되지만는데...
그 때 기억이 정확하진 않지만,
git list에 아무것도 나오지 않음을 확인 했기 때문에 정확한 원인은 파악이 안된다.
git stash 임시 파일
stash는 내부적으로 커밋으로 저장된다.
stash가 사라졌을 때 아래 명령어로 복구를 시도할 수 있다.
git reflog --all | grep stashreflog에 stash 기록이 남아있을 때 사용한다. stash 했던 커밋 해시를 확인할 수 있다.
reflog: HEAD의 이동 기록을 모두 보여준다--all: 모든 브랜치 + stash 기록까지 포함한다 (기본값은 현재 브랜치만)| grep stash: 출력 결과 중 stash 가 포함된 줄만 필터링한다
git fsck --lost-foundreflog에도 남아있지 않을 때 마지막 수단으로 사용한다.
git 내부 객체를 전수 검사해서 어디서도 참조되지 않는 고아 객체를 찾아낸다.
fsck: File System Check. git 내부 객체의 무결성을 검사한다--lost-found: 참조되지 않는 고아 객체를.git/lost-found/폴더에 저장한다
dangling commit → stash, 리셋으로 날린 커밋 등 조회가 가능하다.
GitHub 로그인 안 되는 문제
다른 블로그 글에서 같은 문제가 있었을 때, password 재설정 메일을 보내 다시 로그인해서 해결했다고 했지만, 내 경우에는 재설정 메일 조차 안왔다.
5분정도 기다리니 해결됐는데 잦은 push 후 이슈를 수정하고 있던 상황으로 미루어보아 너무 잦은 요청을 보내서 Github에서 잠시 차단당했던 것 같다.
팀 회고
프로젝트 발표 피드백
같은 의미를 전달하는 더 간결한 문장 구사하기
주제와 맞는 장표를 작성하기
장표 각각의 주제를 명확하게 하고, 장표끼리 순서를 연결하기
예를 들어 프로젝트 설명 할때
프로젝트에서 가장 중요하게 신경써서 구현한 개념은 무엇인지.
처음 보는 사람이 프로젝트의 비즈니스를 파악할 수 있도록 해야한다.
다른 팀들과 똑같이 구성하면 차별점이 없다. 보지 않게 된다.
차별점이나 궁금점이 생길 수 있는 장표만들 담는것이 더 효율적이다.
똑같은 자료를 제공하더라도 보는 시점이 다르거나 아예 안 볼 수도 있다.
무엇을 보여주고 싶은지를 친절하게 알려줄 수 있는 부분이 있다.
ppt에 일단 키워드가 들어 있으면 해당 키워드를 제대로 설명할 수 있는 부분이어야 할것. (보면 궁금해진다.)
말하려는 주제를 친절하게 전달하고
다음 피피티 장에 무얼 봐야 할지 전제로서 알 수 있도록 하기.
준비한 자료보다 청자가 익숙한 키워드가 더 눈에 띄여서 말하려는 의도가 잘 전달되지 않을 수 있다.
청자가 누구던 같은 흐름을 이해하고 제시한 이야기를 따라갈 수 있도록 하기
텍스트가 너무 많은 자료각각의 비교를 할 때: 보여주고싶은 부분을 추출해서 피로도를 줄인다.
쉽게 읽을 수 있는 코드 -디자인 패턴
애그리거트를 나누었을 때 생기는 문제 트러블 슈팅 -
그런데 왜 애그리거트를 나눠야 했는지 설명이 안되어있다.
허브와 허브 경로를 분리하기 위해 확장성을 고려해서 애그리거트를 나누었다.
도메인 패키징 구조 시행착오 부분 -
DIP를 구성하기 위해 패키징 구조를 도입했다. 라는 도표가 이해하기 좋을 것 같다.
- 허브 스케줄링 부분:
스케줄링이 00시에 시작되어 주문을 생성하고 배송을 생성하는 흐름인데,
배치/스케줄러 에서 처리량 측면 외에도 스케줄링 자체가 이뤄지지 않을 때 스케줄링 전략에 대해서도 생각해봐야한다.
- 외부 api 최적화 부분:
캐시가 없어서 db로 트래픽이 쏠리는 형상 = Cache Stampede
캐시가 없으면 서버는 상관없이 요청을 받을 텐데 이때 생기는 db 부하가 바로 서버 부하로 이어진다.
테스트 관련 전제가 무엇인지 더 친절했다면 좋겠다.
30 (허브 간 단일 경로 개수) * 2시간마다 1번씩 요청했을 때...
문제되는 부분을 캐치하고 개선 방법을 고려해보는 시도가 좋았다.
주문 알림 부분
어떤 도메인에 관한 부분이 아니라 서비스들 전체에 대한 부분이기 때문에 언제든 모든 서비스로 확장될 준비가 되어있어야 한다.
그리고 각 서비스마다 알림을 발생시킬 때 비즈니스 변경, 메시지
현재 비즈니스에 관한 파악을 해야했다.
확장성을 핑계로 비즈니스와 관련없는 방향으로 기술이 범람하는게 아닌지 생각해봐야 한다.
더 구
이벤트처리를 위해 카프카를 사용한다 X
카프카의 특성은 뭐가 있고, 단점이 뭐가 잇는데, 단점을 보완하려면 이런 방법을 시도해볼 수 있고 그 방법이 우리 프로젝트와 비즈니스 모델에 적용되기 괜찮은 방식이기에 적용을 해봤다.
배치로 처리했다.
배치로 처리했을 때 ~문제가 생길 수 있다 까지 생각을 해봐야한다.
카프카와 래빗엠큐차이, SQS 차이 이해하기
카프카 사용하는 이유 - 메시지를 쓰는데 특화된 틀 : 처리량이 많은 구조에 활용되기 좋다.
링크드인에서 먼저 구현 선점
구현 자료와 다뤄본 개발자가 많다
백엔드 개발자의 마음가짐
비즈니스 요구사항이 모호하고 기획을 조절해서 서비스의 성능을 높일 수 있다.
시스템은 점진적으로 발전되는 가능성
Java를 사용하는 이유
개발자 풀이 넓어서
비즈니스가 복잡해지고 변경이 자주 일어날 때 사용하기 쉬워서
.net을 모티프로
특강 사전 학습 - Spring AI 활용 - 지능형 Agent(도구호출과 MCP)
