최근에 쿼리를 개선하는 과정에 다음과 같은 불편함이 있었다.

• 쿼리가 몇 개가 나가고 있는지 수동으로 위로 올리며 직접 체크
  • 그러다 API 여러 개 겹치면 지금 보려는 쿼리가 어디인지 모르겠고 그럴 때마다 클리어하고 다시 날리고…

최근에 프로젝트에서 리팩토링과 동시에 쿼리 개선을 하고 있다. 조인 한방 쿼리로 한 번에 끝내는 게 여러 번 네트워크 타는 것보다 좋을 것 같아서 한방 쿼리로 수정하고 있다가 다음과 같이 조인이 덕지 덕지 붙어있는 코드를 보고 뭔가 이상함을 감지했다.

문제 상황

ConcurrentHashMap을 알아보기 전에 왜 ConcurrentHashMap을 사용해야 되는지, 다른 Map 구현체와의 차이에 대해서 살펴보자.

2, 3차 데모데이 회고를 해보려고 한다. 왜 2주 차는 회고를 안 했냐고 하면 그동안 많이 바쁘기도 했고 무엇보다도 기획이 아직 확실하게 안 잡혔었기 때문에 회고를 남기기 애매했다. 2차 데모데이 발표를 내가 했지만 기획에 대해 많이 의문이 안 풀린 상태였다. 그래도 3차 데모데이를 기반으로 기획과 방향성이 잘 잡혀서 지금에서야 제대로 회고를 하게 되어서 다행이다ㅎㅎ 2, 3주 차 동안 어떤 해프닝들이 있었는지 한번 살펴보자

이전 프로젝트들에서 배포 후에는 DB 스키마를 변경하고 유지 보수한 적이 없어서 생각을 못 했다. 생각해 보면 귀찮아서 ALL DROP 후 CREATE 때린 거 같기도 하고ㅋㅋㅋ. 근데 만약 실제 운영하는 서비스이고 실제 데이터가 들어있다면? 하나라도 삭제되거나 잘못 변경되면 큰일 나기 때문에 신경 쓸게 많을 것이다. 일일이 각 배포 환경 돌아다니며 직접 schema를 변경할 수도 있겠지만 여간 귀찮은 게 아닐 것이다. 그리고 그러다 실수하면? 물론 실수한 게 문제가 아니다. 사람은 누구나 실수를 할 수 있다고 생각한다. 그런 환경이 나오지 않도록 하는 게 중요한 것 같다.

이번에 집사의고민 팀에서 브랜치를 정하고 어떻게 병합할지에 대해 얘기가 나왔다. 스쿼시 어쩌구저쩌구 리베이스 어쩌구저쩌구… 이런 용어가 나오길래 아 아직도 깃허브에 대해 모르는 게 많구나 다시 한번 느끼고 Merge 전략에 대해 정리하고 가고자 한다.