22.12.03.(토) TIL - 디자인패턴에 대한 첫 고민

오늘은 실전! 스프링 부트와 JPA 활용1 - 웹 애플리케이션 개발>에서 주문 서비스 코드를 작성하였다.하다보니 강의를 보면서 코드를 작성하는 것보다 코드를 먼저 작성해보고 강의를 듣는 것이 코드와 강의를 이해하는게 더 좋은 것 같다.강의를 들으면서 궁금했던 점은 entity에 비즈니스 로직을 넣어도 괜찮은지. 그리고 new XXX() 을 사용해서 인스턴스를 만들어서 사용하지 않는지에 대한 내용이었다.그러면 import해온 entity는 어떻게 저장이 될까... 게다가 repository를 호출 안하고 주문 취소 로직을 작성하는데 어떻게 DB에 데이터가 수정이 될지에 대한 것이었다. 2번 질문에 대한 대답은 JPA의 강점은 entity 내에서 바뀌는 값들을 알아서 쿼리를 만들어 db에 날려준다.(영한님 말로는 변경된 감지라고 한다.) 그러면서 1번 질문에 대한 대답은 인스턴스를 여기저기 생성하여 코드를 작성하면 나중에 유지보수가 어려워진다고 하였다. 요즘 읽고 있는 에서 "둘은 너무 많다"는 내용이 떠올랐다. 똑같은 걸 나타내는 상수든 함수든 뭐든지 두 개 이상이면 하나도 만들라는 이야기이다. 또 강의를 보면서 다른 분들이 적은 질문도 보는데 정적 팩토리 메서드, 프록시 같은 개념들도 나왔다. 공부하면 할 수록 더 공부해야되는게 많아지는 느낌이다. 내가 몰랐던 새로운 것들이 나타날 때 방대한 바다에서 헤어나오지 못해 허우적 되는 느낌이랄까... 더 공부해야 할 것JPA를 사용할 때는 도메인 모델 패턴SQL를 사용할 때는 트랜잭션 스크립트 패턴사내에서는 myBatis를 쓰니 트랜잭션 스크립트 패턴을 더 보아야겠다. 요약여러가지 디자인패턴에 대해 알게 되었다. 아직도 많이 모르고 있구나라는 생각이 든다. 그래도 지금이라도 알아서 다행이고, 나중에 연차가 쌓이면 이것들에 대해 진지하게 고민해보고 적용해 볼 날을 기대하며거인 위에 어깨에 올라타 있지만 내가 몰랐던 새로운 것이 나타날 때는 나는 작아진다.그래도 시간 지나 과거에 적은 TIL을 보면서 지난 날보다 성장했음에 뿌듯함을 느낄 날을 기대하면서 오늘도 공부하면서 성장하자.

22.11.30.(수)~ 12.02.(금) TIL- 삽질의 연속

11.30.(수) ~ 12.02.(금)출근하기 전에 실전! 스프링 부트와 JPA 활용2> 강의들었다. 주문조회 API를 Entity로 노출하는 것와 DTO로 노출하는 것, 그리고 fetch 조인에 관한 강의 3편을 들었다. 강의 시작 할 때 JPA를 완전히 이해하고 들으라고 했다. 하지만 일단 강의를 듣고 나중에 실습하면서 이해할려고 했다. 그래도 일단 이해한 것은 entity로 그냥 노출시키면 relation 관계에서 무한로딩이 빠질 수 있다는 점이었다. 해결 방법은 해당 entity 필드 양쪽 중 한 곳 에@JsonIgnore를 처리해야한다. 게다가 relation 걸린 수 많큼 1+N의 쿼리가 나가는데 이럴 때 fetch join을 사용하면 쿼리가 한 번만 나갈 수 있다.JPA를 실무에서 많이 사용하고 편하다고는 사용하기 위해서는 공부를 많이 해야 될 것 같다는 생각이 들었다.우선 사내에서는 mybatis를 사용하니 우선 거기에 익숙해지고 천천히 JPA를 공부해보아야 겠다. 회사에서는 이제 세팅된 스프링부트 코드 해석하고 테스트로 패키지를 따로 만들어서 그 안에 Controller, Mapper, Service, Repository, Entity 등을 다 넣어서 테스트 했다. 하지만 에러가 발생했는데 알고보니 MapperScan, EntityScan가 설정된 경로 외 다른 곳에 패키지를 만들어서 실행이 안되었다. 처음 접해보는거라 삽질을 많이한다. 게다가 테스트로 코드 작성하는 것도 오래 걸리고 나의 뇌가 버벅되어 생산성이 안 나오는 느낌이었다. 빨리 익숙해져야지... VSCode 쓰다가 intelliJ 잠깐 쓰다가 STS쓰니까 단축키 버퍼링도 온다...또한 Redis를 사용하여 토큰 값을 저장하였다. Redis 이야기는 많이 들어보았다. 하지만 사용하지는 않아서 다른 DB랑 똑같은 줄 알았다. Redis를 파고보니 key-value로 데이터를 저장하는 DB였다. 이렇게 새로운 사실을 알고나면 신기하지만 이걸 왜 아직까지 몰랐을까라고 생각하면 아찔하다. 또 Rest API를 사용하기 위해서 restTemplate를 사용해보았다. 세팅된 코드에는 RestTemplate를 @Configurete로 저장하여서 사용하였다. 이걸 인스턴스로 어떻게 꺼내어 사용하까 고민했는데 다른 분에게 물어보니 @Autowired로 사용해서 꺼내쓰면 된다고 하였다. 왜 그 생각을 못했을까... 이렇게 다시 Spring Container에 대해 배운 것이 생각이 났다. 이제 안 까먹겠지?restTemplate.exchage 쓰려다가 안되서 어짜피 post로 외부 API 받아올거라 restTemplate.postForEntity로 사용했다.JS에서 Axios를 사용했는데 사용법이 좀 다른 것 같다. 근데 이것도 익숙해지면 편해지겠지? 요약삽질을 많이했다. 코드 작성하는 속도가 느리다. 뇌가 버벅거린다. 나만의 단축키를 하나 만들어서 다른 코드 편집기를 사용하더라도 그거를 적용해야겠다.이제 담주부터 프로젝트 진도 나가겠지? 너무 떨린다... 근데 빨리 프로젝트하고 싶기도 하다. 배운 걸 빨리 써먹고 싶다.

22.11.28.(월) ~ 11.29.(화) TIL

22.11.28.(월) 월요일은 휴가 내고 어디 갔다가 저녁 먹고 실전! 스프링 부트와 JPA 활용2> 강의를 들었다. RequestBody를 Entity로 받는 것이 아니라 DTO로 받는 것에 대한 내용이었다. 사실 스프링 부트 공부하면서 블로그를 찾아볼 때 DTO, DAO를 사용했는데 그걸 이해 못하고 넘어갔다. entity로 인자를 받거나 응답을 주는 것은 entity에 화면을 뿌리기 위한 로직이 들어가 있다. entity에 프레젠테이션 쪽 로직이 추가된 것이다. 또한 API의 스펙과 기능들이 entity에 들어왔다. 이렇게 되면 entity의 필드명이 바뀌면 API 스펙이 바뀌어 버린다. 또한 응답필드를 확장할 때 유연성도 떨어진다. 그래서 필요한 필드만 요청받고 응답받는 DTO를 사용하는 것이 좋다. 22.11.29.(화)화요일은 업무시간에 삽질한 내용이다. 시니어 개발자 분이 전달해준 기본 세팅이 된 프로젝트 소스코드를 받아서 코드를 볼려고 하였다. STS를 사용했는데 작동이 안되었다. Spring Boot App config에 Main Type이 정의가 안 되어 있었다. 그리고 그 외 여러 설정들을 해주니 실행이 되었다. 이것 저것 삽질하다가 하루가 다 갔다. 역시 세팅하는게 제일 어려운 것 같다... 기본 세팅되어 있는거 실행하는 것도 어렵다... 삽질하는데 전달해줄 때 설정이 뭔가 빠진 것 같다라는 생각이 들은 것에 반성하며...

22.11.26.(토) TIL- 스프링부터 실전강의 열심히 들었다.

오늘은 어제 블랙 프라이데이 때 지른 김영한님의 강의 실전! 스프링 부트와 JPA 활용1 - 웹 애플리케이션 개발> 강의를 들었다. 세팅을 하는데 어렵진 않았다. 엔티티도 한땀한땀 작성해주었는데 세팅 + 엔티티 작성을 해주는데 에너지를 많이써서 진도가 나가기 싫었다. 그래도 회원(Member), 상품(itme) 레포와 서비스, 테스트를 작성했다. 주문(Order)까지 하려고 했지만 엔티티 작성해주는데 에너지를 너무 많이 사용한듯ㅠ회사에서 JPA를 사용하지는 않지만 그래도 설계 및 서비스 로직 작성하는 방법을 배우고 싶어서 수강하였다. @OneToMany, @ManyToOne을 쓸 때 To 전에 오는 관계 entity가 현재 위치하는 엔티티, To 뒤에 오는 관계 entity는 매핑하려는 entity로 생각해주면서 작성해주었다.@ManyToMany는 사용하지 않는 것이 좋다. 일단 요정도만 알자.

22.11.25.(금)-스프링 컨테이너, 싱글톤, @Component, @Autowired

스프링 컨테이너(ApplicationContext)를 생성하고 @Bean Annotation을 메서드에 등록하면 컨테이너에서 @Bean을 스캔하여 스프링 빈을 등록한다.@CompoenetScan은 @Component가 붙은 모든 클래스를 스프링 빈으로 등록한다.@Autowired를 지정하면 스프링 컨테이너가 자동으로 해당 스프링 빈을 찾아 주입한다.(getBean(MemberRepository.class)와 동일) 싱글톤 패턴은 클래스의 인스턴스가 1개만 생성되는 것을 보장하는 디자인 패턴이다. 하지만 싱글톤 패턴을 사용하면 문제점이 여러가지가 발생한다. 다 이해하는건 어렵지만 결론적으로 유연성이 떨어진다고 한다.그래서 스프링 컨테이너는 인스턴스를 한 개만 생성(싱글톤)하여 관리한다.내부 로직은 자세히 알 수 없지만 스프링이 CGLIB라는 바이트코드 조작 라이브러리를 사용하여 싱글톤을 보장해준다고 한다. 바이트코드를 조작하는 CGLIB 기술을 사용해서 싱글톤을 보장해주려면 클래스에 @Configuration을 붙여주면 된다.그래고 의존관계를 주입할 때 생성자 주입, 수정자(setter) 주입, 필드 주입, 일반 메서드 주입이 있는데 4가지 중에 대부분 생성자 주입을 사용한다고 하고 종종 수정자 주입을 한다고 한다. 생성자 주입을 하면 한 번만 호출 되는 것을 보장된다. 그리고 불변, 필수 의존관계에 사용된다.내가 블로그에 찾아본 예제에는 필드에 @Autowired를 사용했는데 이 방법은 좋은 방법이 아니었다... 사실 @Autowired나 @Component도 왜 사용하는지 몰랐다. 하지만 순수 자바 코드로 AppConfig를 만들어 사용하는 클래스를 메서드로 사용하여 main 함수에 AppConfig 인스턴스를 생성해주면 되었다. 하지만 스프링 컨테이너를 사용하고 나면 싱글톤을 보장해주고 Annotation으로 OCP, DIP 원칙을 지키면서 코딩을 할 수 있게 해준다. - 이제 스프링 부트로 개발을 시작할 날이 얼마 안 남았다ㄴ 이번에 블랙프라이데이 이벤트라서 김영한님의 강의 실전 JPA1, 2 강의를 구매하였다.ㄴ 요즘 개인적으로 재정긴축해서 아껴쓰고 있긴하지만... 과감하게 강의를 질러야될 만큼 속도감있게 올바른 방향으로 공부를 해야되었다. 현재 위기기만 기회로 만들기 위해서 계속 노력이 필요하다. 강의가 비싸지만 영한님 버프 받고 생존의 굴레에서 벗어나자

22.11.24.(목) TIL-1. IOC, 2. myBatis 파라미터, 3.Post

다음 프로젝트에 Spring boot랑 myBatis랑 같이 쓴다고 해서 myBatis도 같이 공부하고 있따. myBatis 문법 중에 인자를 받는 문법 때문에 헤메었다.. 단일, 다중 파라미터일 때 사용하는 문법이 다르다는 걸 알았을 때 좀 허무했다. 그리고 IOC 용어도 자바 코드로 AppConfig를 만들어 사용영역과 구성영역으로 나누었다. 오늘 배운 것들1. 제어의 역전- 기존에는 프로그램의 제어의 흐름을 클라이언트 코드에서 제어하는 것이 아니라 외부에서 관리하는 것을 제어의 역전이라고 한다.2. myBatis 단일파라미터, 다중파라미터단일 파라미터인 경우 ${} 사용, parameterType ="String"다중 파라미터인 경우 #{} 사용 parameterType ="map" 3. Get, PostPOST -> header에 body로 받을 때, GET -> url의 param으로 받을 때 4. 로그인할 때 토큰 생성 연습Rest API에 http method 보낼 때 Get과 Post도 구분도 못해서 잠깐 해매었다... 그전에는 GraphQL만 사용해서 그런거 신경 안 써도 됐지만 Get, Post도 구분 못 하는거에 충격... 이제라도 알았으면 됐다.

22.11.23 TIL - 객체 지향 원리 적용 그리고 static

오늘은 휴가를 내고 집에서 강의를 들었다. 생각만큼 많이 듣지는 못했다. 연말에 휴가를 다 써야 하는데 12월 되면 바빠서 못 쓸 것 같아서 다른 사람들 휴가 쓸 때 같이 썼다 1.자바 코드로 회원, 주문, 할인 도메인과 인터페이스 예제를 작성하였다. 이 예제 코드도 좋은 코드지만 SOLID 원칙에 OCP과 DIP 원칙에 위배가 되었다.해결 방법은 각 Service 클래스에 인스턴스 변수를 생성자 인자로 넣어준다. 그리고 AppConfig 파일을 만들어서 그 안에 Service 구현체를 반환해주고 해당 Service를 사용하려는 지점에 AppConfig를 호출하면 AppConfig에서 필요한 인스턴스를 꺼내어 사용할 수 있다. 이렇게 하면 각 Service들은 각자의 역할에만 집중할 수 있으며 확장은 가능하지만 수정은 안되는 코드를 작성해줄 수 있다.어제 객체지향 원리에 5가지 원칙에 대해서 잘 이해가 안 되었지만 코드로 작성해보니 좀 더 이해할 수 있었다. 그리고 Spring을 사용하기 전에 그냥 자바 코드로 의존성 주입을 경험해볼 수 있었다. 2.그리고 static을 왜 사용하는지에 대해서도 알았다. 그 전에는 그냥 코드 따라 칠 때 있길래 생각없이 따라 작성했다. static은 프로그램이 실행될 때 클래스에서 딱 한번 생성된다. 인스턴스가 생성될 때 static 변수는 생성되지 않으며 다른 인스턴스들은 해당 클래스 내부에 있는 static변수를 공유한다. 우연히 다른 사람이 질문한 글을 보았는데 완전 유레카였다. 예전에는 왜 static을 이해하지 못했을까...static 참조: https://www.inflearn.com/questions/240845 내일이나 모래부터 Spring로 프로젝트 시작할 거 같은데 처음 해보는거라 너무 긴장된다... 잘 할 수 있을까...

22.11.21~11.22 TIL 좋은 객체 지향에 대해서

- 21일 월요일은 좋은 객체 지향 설계의 5가지 원칙(SOLID)과 객체 지향 설계와 스프링의 내용을 들었다. 자바를 사용하면서 객체 지향은 그저 클래스를 사용하고 상속을 하는 것만 알았다.하지만 객체지향의 설계에는 SOLID라는 5가지 원칙이 있다. 사실 무슨 말인지는 잘 모르겠다. OCP(개방-폐쇄 원칙과 DIP(의존관계 역전 원칙)이 중요하다고 하였다. 나중에 강의를 들으면서 코드를 작성하면서 따라가다보면 알게 되겠지

22.11.19 스프링 기초 강의 - AOP

오늘은 스프링 AOP에 대해서 배웠다.NodeJs와 prisma를 사용했을 때 Pirmsa.middleware랑 비슷하다라고 했다. 공통관심사항과 핵심관심사항을 분리하는 것이 포인트 게다가 @Aspect Anotation을 사용해주기만 하면 간단하게 공통관심사항을 분리하여 사용할 수 있다.(@Bean 주입할 때 따로 분리해주든가 @Component 와 함께 써주면 Spring Container에서DI를 하기 전에 프록시 메서드로 먼저 주입 후 joinPoint.proceed() 가 끝나면 원래 메서드를 사용한다.) 공통관심사항과 핵심관심사항을 편리하게 분리할 수 있는 이유는 Spring에서 DI를 사용하여 원래 메서드를 주입하기 전에 프록시 메서드를 주입할 수 있기 때문이다. 공부할 것이 많지만 급하지 말고 꾸준히 하나씩 해나가자. 모래 위에 쌓은 성은 쉽게 무너지니 탄탄한 지반 위에 차근차근 쌓아 올려가자

22.11.18 - Spring 복습 및 Anotation의 의존성 관계에 대한 깨달음

이제 프로젝트에 스프링 부트를 사용해야 한다. 김영한의 스프링 입문 - 코드로 배우는 스프링 부트, 웹 MVC, DB 접근 기술> 강의를 컴포넌트 스캔과 자동 의존관계 설정> 부분까지 복습했다. 컴포넌트 스캔과 자동 의존관계 설정에 대한 이야기가 이야기 안되었는데 udemy의 자바 기초 강의에 스프링 관련을 듣고 들으니 이해가 되었다. 사실 @Autowired가 어떻게 작동되는지 이해가 안되었는데 다시 복습하니 @Controller -> @Service -> @Repository를 의존성 관계를 가지며 이 관계대로 Spring Container에1서 가져온다. 공부하면 공부할 수록 공부해야 할 것이 많다고 느껴졌다. 이제 NodeJS보다 Java를 더 파야되는 상황이 왔다. 일은 더 많아지고 늦게까지 일해야겠지. 오히려 이런 상황이(사내 상황이 변하고 새로운 언어로 프로젝트하고 내가 주도록으로 할 수 있는 상황) 더 성장할 수 있는 기회가 될 거라 생각해서 적극적으로 달려들자