개발놀이터

코드를 리팩토링 하는 과정에서 Collection에 담긴 내용을 if문 두개로 중첩해서 걸러내는 로직이 있었습니다.   로직을 간단하게 설명하자면 사용자가 장바구니에 담은 상품의 사이즈와 데이터베이스에 존재하는 상품의 사이즈 중 같은 것을 찾고 (ex. 장바구니에 105사이즈를 담았다면 데이터베이스에 105사이즈를 검사함) 찾은 것 중에 재고를 비교해서 장바구니에 선택한 수량이 데이터베이스에 남아있는 수량보다 많은 경우 (ex. 장바구니에 2개를 넣고 결제하려는데 데이터베이스엔 1개밖에 없는 경우) 를 비교해서 만약 그런 상황이라면 재고가 남아있지 않는다는 메시지를 띄워주기위해 설계한 로직입니다.  들여쓰기가 세번 이상 되었기 때문에 리팩토링 해야겠다고 생각했고 StreamAPI를 이용해서 깔끔하게 리팩..

오늘도 사이드 프로젝트를 리팩토링하면서 시간을 보내고 있었습니다. 얼마전 if-else 블록의 중복으로인해 추상화하는 방법을 깨달아서 이 방법으로 추상화를 진행했습니다.  그 결과 이렇게 코드를 줄일 수 있었죠.   이랬던 코드들이  이렇게 바뀌었습니다.  https://coding-review.tistory.com/487 다형성을 이용해 if else 블럭 추상화하기취준때 개발했던 온라인쇼핑몰 프로젝트는 약 2년전에 개발한만큼 돌아가게만 만든 경향이 있는 코드들입니다. 읽기 힘든 코드는 물론이고 확장성을 고려하지않은 구조가 많았습니다. 제 프로coding-review.tistory.com 리팩토링 방법은 위의 링크와 같은 방식으로 처리했습니다.  리팩토링으로 SRP와 OCP를 동시에 지킬 수 있게 되었..

취준때 개발했던 온라인쇼핑몰 프로젝트는 약 2년전에 개발한만큼 돌아가게만 만든 경향이 있는 코드들입니다. 읽기 힘든 코드는 물론이고 확장성을 고려하지않은 구조가 많았습니다. 제 프로젝트에서 문제가 된 부분을 단순화해서 보여드리고 어떻게 리팩토링 하였는지 포스팅해보려고합니다. if else 블럭을 추상화? 한번 이런 상황을 가정해보도록 하겠습니다. 우리 프로젝트는 관리자 (ADMIN), 매니저 (MANAGER), 일반회원 (MEMBER)에 따라 할인이나 결제에 대한 정책이 다르게 설정되어있습니다. 때문에, 할인정책에서도 관리자, 매니저, 일반회원인지를 확인하고 정책을 적용해야하고 결제정책 또한 마찬가지입니다. 그 결과 제 코드는 이런 방식으로 짜게되었습니다. @Service public class Paym..

이번에 눈에 들어온 그지같은 코드는 바로 이중 for문입니다. 우선 리팩토링 전 코드부터 보시죠. package com.hello.capston.service; import com.hello.capston.entity.*; import com.hello.capston.repository.ItemDetailRepository; import com.hello.capston.repository.OrderItemRepository; import lombok.RequiredArgsConstructor; import lombok.extern.slf4j.Slf4j; import org.hibernate.TransactionException; import org.springframework.security.core.p..

요즘 공부할게 딱히 없을 때 포트폴리오로 작성했던 사이드프로젝트 온라인 쇼핑몰의 고도화를 진행하고 있습니다. 고도화라고 해봐야 별게 없지만... 버전을 4버전까지 업그레이드 하면서 대부분 성능개선 혹은 인프라적인 개선이 이루어졌습니다. 블로그 카테고리 "사이드 프로젝트" 부분을 참고해주세요! 하지만 코드는 2년전에 작성한 그대로 유지하고 있어서 굉장히 비효율적인 코드라던가 확장에 유연하지 않다던가하는 문제가 있었습니다. 이번 리팩토링은 세션 관리를 Authentication 객체를 이용해서 관리하도록 변경하였습니다. 기존 코드를 먼저 보시죠! if (loginId == null)) { User findUser = cacheRepository.findUserAtCache(username); Comment ..