개발 기록

전제데이터: 500만건조건: nickname 정확히 일치결과: 중복 없기 때문에 단건 조회테스트 환경: 조회 성능 측정 시 캐시 효과를 배제하기 위해 매번 MySQL 서버를 재시작해 동일한 스타트 환경에서 측정최초 조회 속도인덱스가 없는 상태에서 500만건중 쿼리파라미터로 들어온 값과 일치하는 단건 조회를 수행한 결과-> Filter: (u.nickname = 'zi0') (cost=529242 rows=499163) (actual time=0.0548..2733 rows=1 loops=1) -> Table scan on u (cost=529242 rows=4.99e+6) (actual time=0.0494..2589 rows=5.03e+6 loops=1)소요 시간DB 실행시간: ..

벌써 또 한 달이 흘렀다.과연 나는 이 한 달 동안 얼마나 더 성장했을까?팀장 경험 — 책임을 피해 오던 내가, 책임을 맡게 되기까지나는 원래 나서는 걸 좋아하는 성격이다.하지만 모순적이게도 책임을 진다는 것에는 항상 부담을 느껴서, 지금까지 단 한 번도 팀장을 맡아본 적이 없었다.숙련 주차 팀장을 정할 당시, 랜덤으로 팀장이 되었고싫다고 말할 수는 없었던 상황이었다. 다행히 본격적인 팀 프로젝트는 아니었기 때문에 부담이 조금 덜했고, 그렇게 첫 팀장 역할을 맡게 되었다.이왕 팀장이 된 거, 그냥 역할만 수행하고 끝내고 싶지는 않았다.“나와 같은 팀원들이 이 시간만큼은 같이 성장했으면 좋겠다”는 마음이 컸다.그래서 내가 개인적으로 질문받았던 내용, 혼자 공부하며 정리했던 것들, 그리고 실무 경험을 통해 ..

그때그때 필요한 어노테이션을 찾기보다 왜 필요하고 무슨일을 알아서 해주는지에 대해 알고 사용하기 위해 정리했다.⭐️ Entity@GetterLombok제공모든 필드에 대해 getter 자동 생성불변성, 캡슐화를 깨지 않고 필드 접근 가능@EntityJPA가 이 클래스를 DB테이블과 매핑되는 엔티티로 생각해당 어노테이션이 붙은 엔티티는 JPA가 영속성 컨텍스트로 관리@Table(name=””)엔티티가 매핑될 실제 테이블 이름 지정예약어나 기존 테이블과 충돌할 때 유용 (예약어 user와 충돌될 수 있으므로 users)@NoArgsConstructor(access=AccessLevel.PROTECTED)protected로 막아 외부에서 무분별한 객체 생성을 차단 → 얜 이해하기 너무어려움,,엔티티의 프록시조..

문제 상황 처음에 User URI 설계를 다음과 같이 진행했다.PATCH /users/{userId}POST /users/{userId}/delete이때 서비스 단에서는User user = globalValidator.findOrException(userRepository, userId);globalValidator.matchPassword(user, request.getPassword());globalValidator.forbiddenErrorHandler(user, sessionUserId); 하지만 여기서 문제가 발생했는데문제 분석1.URL 조작 위험클라이언트가 /users/2 → /users/3 으로 바꾸면 다른 사람의 리소스에 접근 시도가 가능해짐.접근을 막기 위해 검증 메소드(forbidden..

첫번째 트러블슈팅 [Error] 일정 관리 트러블슈팅 3 - URI 설계 (User)이전 트러블슈팅 [Error] 일정 관리 트러블 슈팅 1 - 제네릭제네릭이 개념중에 가장 코드 적용으로 바로 이어지기 힘든 부분이었다. 필수과제 구현까지 총 3번의 제네릭 활용 리팩토링을 해보았는devz0.tistory.com문제리팩토링을 진행하며 User, Schedule, Comment 세 도메인 간 연관관계를 다시 보던 중, “단방향으로 유지할지, 양방향으로 전환할지” 판단이 애매했다. 특히, 단건 조회에서 일정과 댓글을 함께 보여주는 엔드포인트 설계를 하며 “일정 단건 조회시 댓글목록을 항상 참조하는데 Schedule ↔ Comment를 양방향으로 바꿔야 하나?”라는 고민이 있었다.⚠️ 이전입문과제는 일정과 댓글..

어려웠던 부분1.JPA 관계 설정ERD도 그려봤고 엔티티에도 다대일 일대다 양방향 관계 설정도 했다. 문제는 DTO. 사실 그냥 내 문제잘못된 설계Comment comment = new Comment( request.getContent(), request.getUsername(), request.getPassword(), request.getTodo() // ❌ request에서 Todo를 직접 받음);이건 request DTO에 Todo 엔티티가 직접 들어있다는 전제인데, 클라이언트는 Todo 엔티티 구조를 모름 Todo의 id만 알고있음DTO는 엔티티를 몰라야함!!또한 JPA가 관리하지 않는(영속되지 않은) Todo 객체가 들어가면 연관관계가 깨질 수 있음DTO는 단순히 데이..

벌써 다시 개발을 시작한지 한달이 흘렀다. 이 소중한 시간을 어떻게 보냈는지 되돌아보려고 한다.들어가기이번 달은 본격적으로 Java 개발자를 목표로 공부를 시작한 첫 달이었다. ‘객체지향’이라는 말이 어렵게만 느껴졌지만, 직접 코드를 써보면서 조금씩 감이 오기 시작했다. 자바 기간 주요 목표는 기본 문법과 컬렉션 등, 그리고 객체 설계 감각을 익히는 것이었다.한달 동안의 학습은 커리큘럼 강의와 자바 문법은 프로그래머스 문제들로 익혀갔다.어려웠던 점 & 해결과정건강상의 이유로 개발을 그만둔지 너무 오래된 상태였어서 다시 기본으로 돌아가는 것 자체가 힘들고 어려웠다. 그전에 이만큼 했으니까 더 잘해야 할텐데 라던지 더많이해야할텐데 같은 내 현실을 직시하고 기본기를 다지는 그 시작부터 어려웠다.그래서 한달..

[Error] 키오스크 트러블 슈팅 1 - 상태 패턴enum 상수과 switch문으로 관리하던 상태에서 상태 패턴 적용 해보는 것도 괜찮을 것 같다고 하셔서 검색 후 내 코드에 적용해 보았다. 기존에 키오스크 실질적인 기능을 담당하는 start() 메소드가devz0.tistory.com [Error] 키오스크 트러블 슈팅 2 -책임 분리이전 글에서 이어지는 내용 [Error] 키오스크 트러블 슈팅 1enum 상수과 switch문으로 관리하던 상태에서 상태 패턴 적용 해보는 것도 괜찮을 것 같다고 하셔서 검색 후 내 코드에 적용해 보았다. 기devz0.tistory.com오래되긴 했지만 API 만들어본 경험이 있어서 과제 로직 구현 자체는 어렵지 않았다. 객체 지향 적인 코드 흐름 문제 제외하고 가장 생..

이전 글에서 이어지는 내용 [Error] 키오스크 트러블 슈팅 1enum 상수과 switch문으로 관리하던 상태에서 상태 패턴 적용 해보는 것도 괜찮을 것 같다고 하셔서 검색 후 내 코드에 적용해 보았다. 기존에 키오스크 실질적인 기능을 담당하는 start() 메소드가devz0.tistory.com키오스크 프로그램을 작성하면서 상태패턴을 도입했다.Kiosk 클래스가 State를 관리하고, 각 상태(START, MAIN_MENU, SUB_MENU, CART, ORDER)는 사용자의 입력에 따라 다음 상태로 전이된다.초기 설계에서는 Kiosk 내부에서 상태 전이(currentState = State.MAIN_MENU)를 직접 수행했지만,점차 책임 분리의 중요성을 알게되며 로직을 수정하다 State와 Kios..

enum 상수과 switch문으로 관리하던 상태에서 상태 패턴 적용 해보는 것도 괜찮을 것 같다고 하셔서 검색 후 내 코드에 적용해 보았다. 기존에 키오스크 실질적인 기능을 담당하는 start() 메소드가 굉장히 길었는데 그 부분은 간략하게 생략되었지만 고려해봐야할 몇가지 문제가 생겼다. 그 과정을 정리해보려고 한다.목표기존 enum + switch 구조에서 상태 패턴(State Pattern)을 적용하여 Kiosk 클래스의 start 메소드 단순화 및 코드 재사용성 향상을 시도상태 패턴 적용 후 장점 start() 메소드가 간단해지고, 상태 전환 로직이 상태 객체로 분리됨.상태별 클래스(StartState, MainMenuState, ...)를 독립적으로 관리 가능 → 재사용성, 확장성 향상.새로운 ..