Take the Opportunities around you!

1. AOP 란 무엇일까? AOP는 Aspect Oriented Programming 을 줄인 말로, 관점 지향 프로그래밍이라 불린다. 2. AOP가 필요한 이유 프로젝트를 구현하다 보면 핵심적인 비지니스 로직 외에 부가적인 기능들을 추가해야하는 상황이 생긴다. 예를 들면, 메소드를 호출할 때마다 로그를 남긴다거나, 성능을 테스트하기 위해 메소드가 실행되는 시간을 측정하는 등 다양한 상황이 발생한다. 이런 부가기능들을 핵심 비지니스 로직에 포함할 수도 있지만, 이 경우 다양한 문제가 발생하게 된다. 1. 핵심 로직 외에 부가기능이 포함되어 코드를 파악하기 어려워진다. 부가기능이 1가지만 있다면 크게 상관이 없겟지만, 부가기능이 많아질 수록 핵심기능보다 부가기능의 코드가 더 많아지는 상황이 발생하게 된다...

1. 테스트 코드를 반드시 작성해야할까? 테스트 코드로 프로그램을 테스트 해야하는 이유가 무엇일까? 지금까지는 어플리케이션을 직접 동작시키고 Chrome 브라우저나 Postman을 통해서 직접 입력을 넣고 출력값을 비교하는 방식으로 테스트를 하였다. 물론 이렇게 테스트를 하는 것도 하나의 방법이지만 치명적인 단점이 있다. 그것은 바로 어플리케이션 전체를 구동한 뒤 테스트를 진행하기 때문에 프로젝트의 크기가 커질수록 실질적으로 테스트하는 시간보다 어플리케이션을 동작시키는 데 드는 시간이 오래걸릴 수 있다. 심지어 수정을 할 때마다 프로그램을 매번 다시 동작시켜야하는데 이게 누적될 수록 시간적인 손해는 간과할 수 없을 정도가 된다. 또한 테스트 코드를 통해 테스트를 진행하면 얻을 수 있는 장점이 한가지 더 ..

스프링 부트를 공부하기 위해 간단한 Todo 관리 앱을 만드는 것을 연습하는 과정 중 사소한 오류로 시간을 2시간을 버린 기록을 남긴다. ResponseEntity의 body에 왜 DTO가 안들어가는거야!!? 어플리케이션 첫 번째 API로 회원가입 부분을 만드는 과정에서 문제가 발생했다. 내가 의도한 것은 사용자의 입력을 받아서 회원가입을 처리하고, 응답값을 ResponseEntity 로 보내주는 것이었다. Postman을 이용해 테스트를 하는데 이상하게 Response body에 아무런 값이 들어가 있지 않았다. 코드는 아래와 같다. @NoArgsConstructor @AllArgsConstructor @JsonInclude(JsonInclude.Include.NON_NULL) //Json으로 만들 때..

스프링 부트로 프로젝트를 개발하게되면 Controller에서 프론트로부터 파라미터를 전달받아야 하는 순간이 온다. 파라미터를 전달받는 방식에는 여러가지가 있지만 이번 포스팅에선 @RequestParam, @PathVariable, @RequestBody 3가지에 대해서 다뤄보자. 1. @RequestParam GET 방식으로 넘어온 URI(Uniform Resource Identifier : 통합 자원 식별자) 에서 queryString 형태의 정보를 추출해내는 방식이다. 예를 들면, api 요청시에 URI가 http://localhost:8080/schedule?id=1 이면 queryString 형태의 정보는 ?id=1 이다. @GetMapping("/schedule") public ScheduleR..