삶을 개발하는 Developer

2주간의 야근.. 그리고 여차저차한 마무리 약속이 있는 금요일(성시경 콘서트)을 제외하고는 4일은 연장 야근한 주간이었다. 9-10pm 퇴근 집에 오면, 느긋하게 저녁을 먹고, 일기를 쓰고, 보고 싶었던 영상을 보는 등의 저녁이 있는 삶을 즐길 여유도 없이 골아떨어져야 했다. 아마도 이렇게까지 야근을 하게된 여러 이유들이 있을 것. 1) 아직 확정되지 않은 기획들2) 개발 시점이 되서야 혹은 TC 중에 스물 스물 수면 위로 올라오는 미확정 안건들3) 자잘하게 잠수함 패치되는 디자인들 4) 서비스 특성 상(결제 도메인), 다른 팀의 의존적인 부분들이 많다보니 테스트가 쉽지 않은 것도.. 5) 확정되지 않은 부분들에 대한 논의를 이어가느라 개발할 시간이 부족해지는 것도 덤. 좀 더 나은 디자인에 대한 고민보..

일정이 너무 촉박해 놓치는 것들 최근에 일정이 빠듯한 프로젝트에 중간에 투입되어 바쁘게 개발 중에 있다. (이번주엔 야근을 3번 정도 했다..)바쁘게 개발하다보니 지켜왔던 것들을 조금 놓치게 되는 것들 그리고 어떻게 개선하면 좋을지 혹은 개선했는지를 정리해 보려고 한다.  1. 코드 리뷰일정이 바쁘다 보니 각 기능들이 특정 브랜치에서 연속적으로 작업된게 아닌 부모 브랜치에서 병렬적으로 작업되었다. 이렇게 했을 때, 보다 상위 기능에 추가 작업이 이뤄졌을 때, 직접접인 영향도가 하위 브랜치엔 없다는 장점이 있을 수 있는데, 병렬적으로 작업되다보니 서로의 개발 내용을 몰라 중복 코드가 왕왕 생긴 점각 PR 에서 개발된 기능들이 꽤나 의존적이었던 관계로 병합 과정 및 기능 재점검을 위한 통합 테스트가 진행되어..

보호되어 있는 글입니다.

상품  판매 시스템 요구사항1. 초당 수천개의 요청을 감당할 수 있는 시스템을 구축해야 합니다.2. 계정 별로 구매 가능한 상품 수 제한이 있습니다. 3. 재고 관리가 엄격하게 되어야 합니다. 1. 사용자 별 구매 수량 관리사용자 식별 값으로 분산락을 걸어 동일 사용자의 상품 구매 작업 동시에 처리되지 않도록 한다. 또한, 요청 마다 구매 수량 계산에 의해 트랜잭션 시간의 증가로 부하가 발생할 수 있으니사용자의 구매 수량을 Redis 로 관리하도록 해 총 구매 수량 계산 연산이 매번 수행하지 않도록 한다.2. 상품 재고 관리상품의 판매 유무 조회 후, 사용처리를 진행할 때, 해당 상품을 동시에 사용처리하는 요청이 많을 경우, 동시성 문제가 발생할 수 있다. 상품은 하나이나, 모든 요청이 구매 가능하다고 ..