해킹왕 양선규

차량 판매등록 기능을 구현하며 객체지향적 설계를 한 것에 대해 정리해 보고자 한다. 차량 등록에 필요한 엔티티는 10개이며, 판매되는 자동차 1대가 10개 엔티티의 데이터를 전부 필요로 한다. 현재 차량 정보를 조회하는 카히스토리 api는 도입하지 않았기 때문에(너무 비싸..) 도입했다는 가정 하에 api 리턴값과 동일한 형태의 테이블을 설계했고, 그에 맞는 더미 데이터 생성 로직을 작성했다. 그 더미 데이터를 이용해 차량 등록 기능을 구현해 보았다. 다만 엔티티가 너무 많았기 때문에 코드가 길어졌고, 하나의 서비스 클래스에 이 모든 로직을 (엔티티 저장, dto변환, 더미데이터 생성 등) 담는 건 매우 좋지 않은 설계라고 생각되었다. 따라서 각 엔티티별 서비스 클래스에 create 메서드를 각각 만들고..

차량 판매등록 기능을 구현하는데, 차량 관련 엔티티 10개에 대한 반복적인 작업을 해야 했다.각 엔티티 만들고, 서비스 인터페이스 + 구현체 만들고, DTO 만들고... 전부 하나하나 일일이 해야 했다. 최대한 효율적으로 작업할 수 있는 방법은 없을까 많이 고민했지만, 엔티티 자체가 많은 거라 어쩔 수 없이 반복작업이 필요한 부분이었다. 그래도 유지보수성을 조금이라도 올리기 위해, facade 서비스 클래스를 따로 만들어서 여러 엔티티를 거치는 비즈니스 로직은 여기서 처리하고, 나머지 각 엔티티 별 서비스에서는 최대한 단일 책임 원칙(SRP)을 지켜 해당 엔티티에만 영향을 주는 로직을 작성하기로 했다. 그러나 정말 무의미하다고 느껴졌던 부분이, DTO 엔티티를 변환하기 위한 팩토리 메서드를 작성할 때였..

객체 지향 프로그래밍(OOP)에서 지향해야 할 5가지 설계 원칙을 SOLID라고 칭한다. 개인 프로젝트를 시작하면서, 완벽하고 빈틈없는 코드를 짜겠다 라는 목표를 세웠다. 그러나 생각만 하는 것 보다는, 5원칙을 참고하여 좀더 명확한 목표를 잡고 프로그래밍 하는 것이 낫겠다고 느꼈다. 지금까진 SOLID 원칙이 중요하다고 지나가듯이 들었던 말들 뿐이었는데, 이번에 제대로 공부해보며 어째서 중요한 것인지 이해할 수 있었다.  5원칙 중에는 나도 모르게 이미 적용하고 있던 것들도 있었고, 하긴 하는데 왜 하는지는 모르는 것도 있었고, 아예 모르는 것도 있었다. 실무 가서 일하다 보면 혼나고 깨지면서 자동으로 이 5원칙에 따라 코드를 짜게 된다던데, 지금부터 미리 5원칙을 이해하고 코드를 설계할 수 있다면 큰..

스프린트 2가 종료되었다. 6일이 걸렸으니 스프린트 1에 비해 3배는 빨리 끝났다.당연한 거겠지만 환경설정과 학습 시간이 빠지고, 기능 구현에만 집중하니 작업이 훨씬 빨랐던 것 같다.스프린트 2에서 구현한 기능은 아래와 같다.마이페이지 조회마이페이지 내 정보 수정판매중인 차량 목록 조회 프론트와 백엔드를 함께 진행하며 느낀건데, 확실히 백엔드가 좀 더 논리적으로 생각할 게 많은 것 같다. 물론 내가 백에 좀 더 신경을 쓰고 있는 것도 사실이지만, 백 로직을 생각하는 것이 3배는 머리아픈 것 같다. 백은 깊고, 프론트는 넓은 것 같다고 느꼈다. 개인적인 생각이다. 프론트엔드에서 어려웠던 점 - 다양하고 자잘한 이슈들마이페이지 조회와 내 정보 수정 기능은 백에서는 아주 수월했다. 쉽게 구현할 수 있었다. 하..

신뢰성이 중요한 중고차 거래에 필요한 차량 정보를 담기 위해서는 꽤 많은 테이블이 필요했다.차량 목록 조회 기능을 구현하는 것에만 5개의 테이블이 엮여있었고, 5개 테이블을 전부 조인해서 데이터를 가져와야 했다. 썬카는 차량 한대 당 메인 이미지 1개와 나머지 이미지들이 존재하며, 대표 이미지 여부는 is_primary 필드로 구분된다.메인 이미지는 가장 먼저 화면에 보여야 하기 때문에, 나머지 이미지들과 dto 별도의 필드에 담길 필요가 있었다.따라서 처음엔 메인 이미지를 조회한 후 나머지 이미지를 추가로 조회하는 방식으로 진행했었는데, 이 과정에서 N + 1 문제가 발생했다. N + 1문제- 최초 1번의 쿼리로 N개의 레코드를 조회한 후, 추가로 N개의 쿼리를 실행하게 되는 상황- 자동차가 10대라면..

백엔드로써 프론트엔드와 협업하기 위해, 커뮤니케이션 비용을 줄인 효율적인 업무를 위해 API 명세서는 반드시 필요하다고 할 수 있다. 명확하게 정리된 API 명세서가 있다면 프론트엔드는 해당 자료를 참고하여 좀 더 수월하게 작업할 수 있고, 서로 엇갈려 불필요한 오류를 맞이할 일도 줄어든다.  1. 의존성 추가// build.gradledependencies { // 생략.. implementation 'org.springdoc:springdoc-openapi-starter-webmvc-ui:2.8.0'} build.gradle에 swagger 사용을 위한 springdoc-openapi 의존성을 추가한다. 단 여기서 스프링 부트 버전과 openapi 버전이 반드시 호환되어야 한다.각 스프링 부트 버전마..

# application.propertiesspring.application.name=suncar# DBspring.datasource.url=jdbc:mysql://localhost:3307/suncarspring.datasource.username=rootspring.datasource.password=0000spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driverspring.jpa.hibernate.ddl-auto=updatespring.jpa.show-sql=true# JWTjwt.secret=BTpHjyFDurb0PefLrKP+e4vKKwNCw+rUoMEpQjde7T6EzB9QjtoqC7MFVcHwbFPr+r4/OlR9ZiB5rpG0axOd4Q..

기능 명세서 단위로 봤을 때, 구현한 기능은 2개 뿐이다. 로그인 그리고 회원가입.무슨 이거 2개 만드는데 3주나 걸렸냐 싶겠지만, 진짜 오래 걸린 것 맞다. 처음 진행하는 개인 프로젝트다 보니 생각보다 기능구현 외에 할 일이 정말 많다는 것을 느꼈다.회사에서 잠깐 일을 했더라도, 전부 짜여진 코드의 틀 위에서 약간의 기능 추가와 수정, 관리 정도였고.. 아예 환경세팅부터 시작하는 것은 처음이었으니 그럴 만도 하겠다. 지난 3주를 돌아보면 나는 단 하루도 쉰 날이 없는데 왜 이렇게 지체되었을까 라는 의문이 든다.아침에 일어나 운동을 갔다오고, 밥 먹고 하루종일 컴퓨터 앞에만 앉아있는데 말이다. 뭐 예비군도 갔고, 가끔 술도 마셨고 그러긴 했지만 그건 큰 핑계가 되지 못한다. 3주는 너무 길다.기간이 지체..

매 요청마다 인가된 사용자가 요청하는 것인지 확인하기 위하여, 로그인 성공 시 JWT Access Token을 발급하고 사용자 요청 시 마다 토큰을 함께 전달받아 검증하는 로직을 추가하기로 했다. Spring Boot에서 JWT Access Token의 발급 및 검증은 Spring Security를 이용해 구현할 수 있다. 근데 생각보다 많이 복잡했다. Spring Security- Spring 기반 애플리케이션의 인증(Authentication)과 인가(권한 부여, Authorization)를 위한 보안 프레임워크 Spring Security - 특징- 포괄적인 보안 기능 : 인증, 권한 부여, 세션 관리, CSRF 보호 등 다양한 보안 기능 제공- 필터 체인 아키텍처 : 들어오는 HTTP 요청은, 여..

중고차 거래 플랫폼은 가치가 큰 물건을 거래하는 만큼 신뢰성 있는 데이터가 중요하기에, 실제로 데이터를 삭제하지 않고 논리적으로만 삭제하는 Soft delete 방식이 적합하다고 생각했다. 실수로 데이터가 삭제되어도 쉽게 복구할 수 있기 때문에 데이터 관리와 안정성이 중요한 경우 적합한 방식이라고 할 수 있다. Soft delete- 데이터베이스에서 레코드를 물리적으로 삭제하지 않고, 논리적으로 삭제된 것처럼 표시하는 기술- 일반적으로 테이블에 is_deleted 등의 필드를 추가하여 삭제된 상태를 표시한다. Soft delete - 필요성- 안전한 데이터 관리 : 우발적인 데이터 손실 방지- 데이터 복구 용이성 : 필요시 간단히 플래그만 변경하여 복구 가능- 유연한 데이터 접근 : 필요에 따라 삭제된 ..