목록전체 글 (18)
쟈미로그
코루틴.. 공부해야지 마음먹었는데 마침 인프런 최태현 강사님이 코루틴 입문 강의를 올려주셨다;; 강의 ->-> 2시간으로 끝내는 코틀린. 운명이다 싶어서 홀린듯 결제했다. 섹션 1. 코루틴 기초를 수강 후 정리하는 글! 1강. 루틴과 코루틴 코루틴? (co-routine) : 협력하는 루틴(함수). 루틴 그렇다면 그냥 루틴(함수)은 뭘까? 그냥 루틴도 협력을한다. 먼저 루틴을 알아보자. fun main() { println("START") newRoution() println("END") } fun newRountine() { val num1 = 1 val num2 = 2 println("${num1 + num2}") } 여기서 루틴은 main과 newRoutine 2개다. main은 newRoutine..
서론 Mockito는 static 메소드를 목킹할 수 없다 (+final, private ..) Kotlin+Spring 환경에서 개발하면서 알게된 것 중 하나가 'Mockito로는 static 메소드를 목킹할 수 없다'는 것이다. 이 사실을 깨달은 경위는, 코틀린에서 확장 함수를 목킹하고 싶은 상황이 와서 목킹하려하자 에러가 뜨는 것이었다. (코틀린 확장함수는 자바로 디컴파일 시 static final 혹은 final 메소드로 변환된다.) 이 목킹하려는 확장 함수가 내가 짠 코드면 모르겠는데.. Spring Data JPA가 기존 Optional을 반환하는 findById 대신, 코틀린을 위해 제공하는 확장 함수인 findByIdOrNull을 목킹하려다 일어난 일이었다. (아래와 같이 findByIdO..
요즘 인생 처음으로 코틀린을 사용한 서버 개발을 하고 있다. 테스트 코드의 필요성을 느끼던 찰나, 한 팀원분이 Kotest vs JUnit 중 어떤 프레임워크를 사용할지 정하자고 하셨다. 자바 스프링부트로 개발할 때는 JUnit+Mockito로 단위 테스트를 짰었고, 그래서 큰 생각 없이 이 조합으로 테스트코드를 짜려했는데 오산이었다. (사실 Kotest라는 테스트 프레임워크가 있는 줄도 몰랐다 히히) 그래서 생각해보니 자바와 유사한 코틀린이지만 사용해볼 수록 자바 스타일 != 코틀린 스타일이긴 했다. 테스트 프레임워크도 코틀린에 어울리는 게 있다면 JUnit보단 그걸 사용하는게 맞다는 생각이 들었고, 찾아보니 Kotest가 마침 '코틀린에 어울리는 테스트 프레임워크'였다. 그래서 지금부터 Kotest ..
05. 코틀린에서 조건문을 다루는 방법 1. if문 if-else문은 기본적으로 자바-코틀린 문법이 동일함. 하지만 다른점이 있는데, 자바에서 if-else는 Statement지만 코틀린에선 Expression임!!! Statement : 프로그램의 문장, 하나의 값으로 도출되지 않음 Expression : 하나의 값으로 도출되는 문장 그렇기 때문에 마치 자바의 삼항연산자처럼 아래같이 표현이 가능함. (그래서인지 코틀린에는 삼항연산자가 따로 없다) fun getPassOrFail(score: Int): String { return if (score >= 50) { "P" } else { "F" } } 2. when 자바의 switch문을 코틀린에선 when으로 표현할 수 있음. Expression이라서,..
새 프로젝트 언어가 코틀린으로 정해지면서 코틀린 공부의 필요성이 코앞으로 닥쳤다. 인프런 최태현 강사님의 자바 개발자를 위한 코틀린 입문 강의를 듣고 요약해보잣! 01강. 코틀린에서 변수를 다루는 방법 1. 변수 선언 키워드 - var, val 코틀린은 자바와 달리 변수 선언 시 무조건 선언 키워드 var, val를 써줘야함. 이 선언 키워드 역할은 수정 가능 여부를 명시하는 것임. var : variable. 가변 변수. val : value. 불변 변수. (자바의 final) 타입 선언 코틀린에선 컴파일러가 자동으로 타입을 추론해주기 떄문에 의무적으로 타입을 쓸 필욘없음. 원한다면 : 기호로 표현 가능. 초기값 지정 안한 경우엔 컴파일러가 타입 추론을 못하므로 타입을 명시해줘야 컴파일 에러가 안남. ..
서론 소프트웨어를 개발할 때, 핵심 비즈니스 로직 외에도 기능 동작에 필요한 것들을 개발해야한다. (ex. 로깅, 트랜잭션 등) 그런데 만약 이런 부가적인 기능들이 자주 사용되는 것이라면 어떻게 될까? 코드에는 비즈니스 로직 + 부가적인 기능들이 뒤섞여서 핵심 로직을 찾기 어렵게 된다.. AOP(관점 지향 프로그래밍)는 이런 상황에서 도움이 된다! AOP는 핵심 로직과 부가적인 기능으로 관심사를 분리하고, pointcut을 정의해서 관심사간에 코드를 침투하지 않고도 사용하길 원하는 코드가 적용되도록 한다. 1. 스프링의 AOP 스프링에서도 자체 AOP 프레임워크를 통해서 AOP를 지원한다. 스프링 AOP는 Proxy 기반으로 동작하는데, 이 프록시를 구현하는 방식이 2가지다. JDK Dynamic Pro..
영속성 컨텍스트의 특징/장점 1차 캐시 동일성 보장 트랜잭션을 지원하는 쓰기 지연 변경 감지 지연 로딩 영속성 컨텍스트가 필요한 이유와 장점을 예시와 함께 알아보자. 1. 1차 캐시 영속성 컨텍스트 내부의 캐시. 영속 상태의 엔티티들이 저장되는 곳이라고 보면 된다. 쉽게 말하면, @Id로 매핑한 키-엔티티 인스턴스가 Map으로 저장되는 장소다. em.persist(~~); 를 통해 엔티티를 영속하면 아래 같은 그림이 된다. 엔티티 조회 조회를 위해서 em.find()를 호출하면 1차 캐시에서 엔티티를 우선으로 찾고, 캐시에 없으면 DB에서 조회를 한다. (메모리에 있는 1차 캐시에서 바로 조회할 수 있으므로 성능상 장점이 생김) 캐시에 없어서 DB에서 조회를 한 경우엔, 조회한 엔티티를 1차 캐시에 우선..
서론 Spring Data JPA를 주로 사용하면서, 단순 CRUD 프로젝트를 할 때는 큰 의문을 갖지 않고 개발했던 것 같다. 그만큼 Spring Data JPA는 추상화가 잘돼서 사용하기 편리한 기술이었다..! 하지만 JPA 관련 에러를 만나서 서칭해볼 때면 설명을 잘 이해할 수 없었고, 그건 JPA 기술에대한 기초 지식 부족 때문이었다. 그래서 이번엔 책의 3장을 읽으면서 JPA 기초를 공부해보고자한다! (구현은 하이버네이트 기준이다.) 엔티티 매니저 팩토리, 엔티티 매니저 엔티티 매니저 팩토리 엔티티 매니저를 생성하는 공장. persistence.xml(or application.yml 등)에 기재한 DB 정보를 바탕으로 생성된다. 생성될 때 비용이 커서, 처음 설정 파일 기준으로 생성된 이후부턴..
서론 평소에 전역으로 예외를 처리해서 반환해줄 일이 있을 때면 @ControllerAdvice와 @HandlerException을 사용하곤했다. 많은 레퍼런스에서 이 방식을 사용하길래 쓰게 됐고, 자세한 동작원리는 모른 채 사용했다. 그렇게 예외처리 == @ControllerAdvice + @HandlerException을 사용하는 것 이라는 생각을 갖고 개발하다가 실수를 하게됐다. 이미 응답을 준 상황에서도 예외를 던지면 ControllerAdvice의 HandlerException가 잡아서 처리해줄 거라는 착각을 한 것..! 두 어노테이션의 동작 방식을 몰랐고, "예외 처리"를 왜 하는가에 대한 개념도 모호해서 이런 일이 발생했던 것 같다. (예외가 발생했을 때 왜 잡을까? 잡아서 클라이언트에게 보여..
@Query 어노테이션의 nativeQuery = true 옵션을 사용해서 네이티브 쿼리를 사용하려던 도중 문제가 발생했다. org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'mainController' defined in file [/Users/kakaobank/Desktop/practice/build/classes/java/main/com/blog/practice/controller/MainController.class]: Unsatisfied dependency expressed through constructor parameter 0; nested exception is or..