코드 개선과제 2월5일차를 진행해보려 했지만 생각보다 어려워서 일단은 보류했다. 오늘부로 JPA 심화 강의가 지급돼서 미리 계획했던 인증/인가부분을 공부를할지 JPA 심화강의를 들어볼지 생각을 좀 해보았다. 바로 새로운 강의를 들을수도 있지만 너무 새로운것들만 계속 익히면 기존에 배운것도 살짝 뒤죽박죽 될것 같아서 일단 인증/인가 부분을 좀더 공부하기로 했다. 먼저 인증/인가 강의를 들으면서 어떤식으로 진행이 되는지 순서를 세워보고, 그 대략적인 순서를 보고 따라 코드작성을 해볼 예정이다. 우선 오늘은 전체적인 흐름을 한눈에 볼수있게 부연설명보다는 간략하게 적을 예정 1. 사전 설정 implementation("org.springframework.boot:spring-boot-starter-securit..

오늘은 어제에 이어서 쿼리DSL 강의를 좀더 복습하면서 Practice 프로젝트를 1차적으로 완성시키고, 페이지 정렬기능, 제목기반 검색기능을 구현했다. 이 쿼리DSL도 신기하게 Impl 파일을 구현해서 실질적인 쿼리코드는 여기서 짜고 상속 받은 파일이 Repository 파일로 가서 동작을 처리하는 방식이다. PostRepositoryImpl package lsw.practice.domain.post.repository import lsw.practice.domain.post.model.Post import lsw.practice.domain.post.model.QPost import lsw.practice.infra.querydsl.QueryDslSupport import org.springframe..

오늘부터는 코드 개선 과제를 수행하려고 연습용 프로젝트를 하나 만들었다. 처음 코딩했을때와 지금을 비교해보면서 얼마나 실력이 늘었을지도 궁금했고, 개인적으로 좀더 짜임새있고 이쁜 코드들을 만들어보고 싶어서 새로 만들기 시작했다. 이름이나 콘셉같은건 뭐로 정할까 하다가 그냥 연습용프로젝트니까 Practice 로 지었고 구성으로는 Post, Comment, User 등이 있다. 처음 코드를 짜다가 문득 패키지 구조에 대해서 생각을 하게 되었고, 패키지구조를 좀더 알아보았다. 크게 두가지로 나누면 도메인형 구조와 계층형 구조로 나뉜다. 도메인형 구조는 기존에 내가 배우던 형식의 구조이고 (Post, Comment 등 도메인에 따라 나누는 구조) 계층형 구조는 도메인에 들어가는 Controller, Servic..

어젠 전반적인 CI/CD의 개념과 Docker를 다운받았다면 오늘은 강의를 따라서 깃허브에 내장돼 있는 CI/CD를 이용해보았다. 일단 어제 배운대로 CI/CD의 전체적인 흐름을 더 자세하게 풀어본다면 개발자는 feature/ 로 시작하는 브랜치를 만들어서 test코드를 포함한 수정 작업을 완료한 뒤 Pull Request 생성 (자동화) Pull Request를 만들면 해당 브랜치에 대해 gradle test를 수행 Pull Request 코드의 test가 실패한 경우, Pull Request 를 생성한 개발자는 test 코드를 수정하여 Pull Request를 변경 Pull Request 코드의 test가 성공한 경우, 다른 개발자들의 승인을 기다림 다른 개발자들은 Pull Request의 코드를 승..

이번 주차는 개인의 코드 능력을 향상시키기 위한 주차이다. 이전까지 했던 내용을 복습하거나 Docker에 대해서 배우는 걸 선택한다. 나는 개인적으로 좀더 욕심이 나서 Docker를 배우는쪽으로 했다. 아직 초기단계고 심지어 오늘은 Docker를 까는데 오류도 많이나고 시간도 많이 걸려서 배운것도 적지만 일단 기록해둔다. 우선 Docker라는건 프로그램의 이름인데 CI/CD의 표준격인 위치인것 같다. 그럼 여기서 CI/CD는 무엇이냐! CI (Continuous Integration) 직역하자면 지속적인 통합 이라는 의미 하나의 프로젝트에 여러명의 개발자가 몰려들었을 때 작은단위로 merge 후 빌드, 테스트 하는것이 가장 이상적인 개발 과정이지만 그렇지 못하고 2일~3일 정도를 개발하다가 합치는 경우도..

내가 이번 프로젝트를 진행하면서 새로 배운것 협업에서는 데이터 삭제 로직은 ‘절대절대’ 두세번 고민해봐야합니다. 데이터는 회사의 자산이예요(삭제하면 사장과 면담 좀 해야할지도..) 그래서 보통 삭제로 로직은 soft-delete로 작성됩니다. 물리적으로 삭제: hard-delete, 논리적으로 삭제: soft-delete (https://velog.io/@taeha7b/hard-delete-softdelete) Entitiy 클래스에서 ‘@Where(clause = “is_deleted=0”)’를 작성해두면 삭제되지 않은 데이터만 조회할 수 있습니다. 여기서 is_deleted는 삭제여부 컬럼이겠죠 위는 코틀린1기 잡담방에 올라온 튜터님의 메세지이다. 일단 우리조는 처음에 어떤방식으로 소프트삭제를 구현할..