개발.. 한놈만 팬다

`@Transactional`로 묶었다고 동시성이 해결되는 건 아니다. 그건 원자성(A) 얘기지 격리성(I) 얘기가 아니다. 재고 5개짜리 상품에 10명이 동시에 주문을 넣는 상황을 따라가며 비관적 락, 낙관적 락, 그리고 "사실 읽을 필요도 없는" 원자적 UPDATE까지 저울질한 기록. 시작은 단순한 착각이었다주문 로직을 짜면서 처음엔 이렇게 생각했다."재고 차감이랑 주문 생성을 @Transacional 로 묶었으니, 동시에 주문이 들어와도 알아서 잘 처리하겠지 트랜잭션이 ACID 를 보장하니깐 동시성도 트랜잭션이 잘 막아줄 것이라고 막연히 믿었다.혼자 주문할 땐 이 믿음이 안깨진다.읽고 -> 확인하고 -> 줄이고 -> 커밋 읽기와 쓰기가 딱 붙어 있어서 문제가 생길 틈이 안보인다. 검증할 상황 자체..

멈춘 코드브랜드 도메인을 만들고 있었다. 요구사항은 단순했다"어드민이 브랜드를 등록할 때, 동일한 이름의 soft-deleted 행이 있으면 새 INSERT 대신 그 행을 복구(restore)하라."설계 문서는 이 로직을 BrandAdminFacade.create 에 두라고 했다. 그대로 옮기다가 손이 멈췄다. // BrandAdminFacade.create()fun create(name: String): BrandInfo { val existing = brandRepository.findByName(name) // ← 왜 Facade 가 이걸 알지? return when { existing == null -> save(BrandModel(name)) ex..

좋아요 등록·취소는 단순한 INSERT/DELETE 같지만, 멱등성을 제대로 보장하려면 다섯 개의 결정을 거친다. DB unique 제약과 hard delete 같은 결정들이 한 트랜잭션 안에서 도메인 정합성을 어떻게 만드는지 정리한다. 1. POST /products/{id}/likes 한 줄에서 시작좋아요는 처음 봤을 때 단순한 기능이었다. 명세상 엔드포인트는 세 개뿐이다. (user_id, product_id) 한 행을 INSERT 하거나 DELETE 하는 일이다.그런데도 설계 문서를 쓰는 동안 결정해야 했던 것이 다섯이었다.멱등성, 좋아요 수의 위치, soft delete 와 unique 의 충돌, BaseEntity 상속 여부, 그리고 그 모두를 묶는 hard delete 결단.이 글은 그 다..

루프팩 첫 주, 회원 도메인 세 가지를 TDD로 구현했다. 잘한 것보다 어색했던 게 더 많아서, 일단 기록부터 남긴다. TDD를 막 시작한 사람, 도메인 검증을 어디 둘지 고민하는 사람에게 참고가 될지도.(Red 실패하는 테스트 Green 최소 구현 Refactor 코드 정리 다음 사이클)이번 주에 한 일3개의 유스케이스를 TDD 사이클 한 바퀴씩 돌렸다.회원가입 POST /api/v1/users내 정보 조회 GET /api/v1/users/me (이름 마지막 글자 * 마스킹)비밀번호 수정 PATCH /api/v1/users/me/password각 기능은 test → feat → refactor 세 커밋으로 끊어서, 한 사이클이 어디서 끝나는지 git 그래프만 봐도 보이도록 했다. 가장 곱씹었던 결정 ..

Mock API를 우선 제공해야 하는 필요성에 대한 이해Mock API는 데이터베이스 연결이나 백엔드 처리 없이 정적 응답만 제공합니다. 테스트 및 개발용: 실제 API가 준비되지 않았거나 불완전하거나 불안정한 경우 사용 https://velog.io/@khy226/msw로-모의-서버-만들기 MSW(Mock Service Worker)로 더욱 생산적인 FE 개발하기MSW(Mock Service Worker)는 Service Worker를 이용해 서버를 향한 실제 네트워크 요청을 가로채서(intercept) 모의 응답 (Mocked response)를 보내주는 API Mocking 라이브러리이다.velog.iohttps://techblog.woowahan.com/20154/ API 모킹으로 테스트를 더 편..

10주간 항해를 마치고 부족한 부분을 다시 공부하고자 항해 그 후 스터디에 참여를 하여 스터디를 진행을 하였습니다.스터디를 진행을 하면서 개인적으로 공부를 했던것을 기록하려고 합니다. 해당 내용은 항해에서 배웠던 10주간 챕터들 중에서 항해하면서 부족하고 추가로 공부할 필요가 있는 것을 키워드 별로 공부를 진행 했습니다. 런던파와 고전파에 대한 이해와 본인의 견해 수립런턴파와 고전파의 가장 큰 차이는 테스트에서의 격리(isolation)를 어떻게 정의하고 구현하느냐이다.런던파런던파는 테스트 대상 코드가 다른 객체/클래스에 의존할 경우, 이 의존성을 모두 테스트 대역(test double) 으로 대체해야 한다고 본다.테스트 대역은 실제 객체 대신 사용하는 ‘단순화된 대체’ 객체로, 복잡성을 줄이고 테스트를..

프로그래머스에서 문제를 풀다가 다른 사람들의 풀이를 보면서 새롭게 알게 되어 알게 된 내용을 기록 해보려고 합니다. 우선 관련된 프로그래머스 문제는 짝수의 합 입니다. 이 문제는 반복문을 이용하면 간단하게 풀리는 문제였지만, IntStream.rangeClosed 을 이용하면 더 간단하게 작성 할수 있다는 것을 알게 되었습니다. IntStream.range vs rangeClosed ?IntStream.range 와 rangeClosed 은 둘다 주어진 범위 내에서 순차적으로 정수 스트림을 반환 합니다.차이점은 range 는 마지막 정수를 포함하지 않고, rangeClosed 는 마지막 정수를 포함합니다. import java.util.stream.IntStream;IntStream.range(0, 5)..

int 보다 더 큰 숫자 데이터 타입은 long 으로 대부분 알고 있을거에요가끔 코딩테스트 문제를 풀다가 long 보다 더 큰 데이터 타입을 써야 할 경우가 생기는데요이때 사용할 수 있는 데이터 타입은 BigInteger 입니다. 범위에 맞지 않는 타입을 사용하게 되면 Java NumberFormatException 에러를 만나게 됩니다ㅠㅠ int & long 범위 우선 많이 사용하는 int, long 의 범위에 대해서 알아 볼게요! int-2,147,483,648 ~ 2,147,483,647long-9,223,372,036,854,775,808 ~ 9,223,372,036,854,775,807 9,223,372,036,854,775,807 보다 더 큰 숫자를 사용할때 BigInteger 를 사용합니다!..

분명 열심히 commit 하고 잔디가 심어잘 심어져 있는데 로그인 안한상태 혹은 다른 계정으로 내 github 의 잔디를 봤을때 잔디가 없다 이건 무슨일인가 🤔 내 잔디가 잘 심어져 있는걸 나말고 다른 사람들한테도 티를 내고 싶은데 왜 안보이는거지!?!?!?!?!!! private repo 잔디는 나만 봐야하는건가..여기에 심어진 잔디는 나혼자 알고 있어야 하는건가... 물론 github 의 잔디를 누구를 보여주기 위해서 심는건 아니지만..그래도 고생해서 심은 잔디인데..안보이면 속상하지 않는가... 그래서 혹시 나와 같은 생각을 한 사람이 있는지 구글링을 해서 그 해답을 찾았다! 해결방법은 생각보다 너무 간단했다 잔디 바로 위에 Contribution settings 에 해결법이 있었다 Contribu..

표준 출력 1. 문자 출력 console.log('Hello World'); // Hello World 2. 변수 출력 result = 35; console.log(`resule is ${result} wow`); // resule is 35 wow 3. 출력 시간 단축 하기 let answer = ''; for(let i = 1; i