서누레코즈

IntelliJ를 이용해서 Java프로젝트를 생성할 때 빌드 관리 툴을 선택해야 한다.

Maven과 Gradle이 있는데 이중에 Gradle을 선호한다고 한다.

이유로는 Maven보다 뒤늦게 Gradle이 나와서 기존의 Maven의 단점들을 보완하기도 했고 

Gradle이 사용 가능한 환경에서 Maven을 사용할 이유가 없다고 한다. 

현실적으로는 회사에서 사용하는 빌드 관리 툴을 이용하자.. 

빌드 중..

빌드 완료 후 프로젝트 구조

build.gradle에서 빌드에 필요한 옵션들을 설정해준다..

우측에 Gradle 탭에서도 보다 시각적으로 확인할 수 있다. 

기본으로 지정된 의존성들을 지워주고 이쪽 프로젝트에 필요한 의존성을 주입해준다.

첫 번째로 스프링 부트를 이용하기위한 스프링부트 플러그인을 추가해준다. 

+ 스프링 dependency 관련한 플러그인도 추가해준다. 

두 번째로는 dependencies 부분에 사용될 라이브러리들을 추가해준다.

REST API를 이용하기 위한 라이브러리와 

jpa 관련 기능을 이용하기 위한 라이브러리 

그리고 to-do 애플리케이션 서버를 이용하려고 인메모리 형식인 h2 데이터베이스를 이용한다. 

이제 리로드 버튼을 누르면 의존성들이 추가된 걸 확인할 수 있다.

+ 추가적으로 lombok 라이브러리도 사용한다. 

추가로 dependencies에 작성하고 리로드 해주자. 

lombok 같은 경우는 의존성을 추가해준다고 바로 사용이 가능한 것이 아니라 

IntelliJ에서 추가적으로 설정을 해주어야 한다.

일단 첫 번째로 intelliJ에  lombok 플러그인을 설치해준다 

이후 IntelliJ 환경설정에서 추가적으로 설정해준다.

추가적으로 dependencies 추가를 위한 코드들은 외워서 쓰는 것이 아니고 

구글에 maven springboot 검색해서 들어가서 원하는 버전과 빌드 관리 툴을 선택하면 코드가 나온다.

이후 필요한 패키지와 클래스 세팅으로 프로젝트 세팅을 마친다.

국비 학원에서 급급하게 팀 프로젝트를 진행해서 Spring의 개념적 이해보단 

이렇게 하니 저렇게 하니 이렇게 동작되더라 정도로 알고 있어  

어느 정도 환경설정이 세팅된 환경 속에서 페이지를 매핑하고

톰캣을 이용해 확인하고 어찌어찌 배포까지는 해서 작업물을 만들었었는데 

이 경험이 실무에서 적용되기 위해서는 스스로 더 공부를 해야겠다는 생각에 이곳저곳 돌아다니며 

습득한 내용을 적어 놓으려고 한다. 

실제로 이렇게 기록을 해놓으니 기억이 지워져도 

이 부분에 대해 기록해놓은 거 같다는 어렴풋한 생각 덕에 쉽게 다시 복습했던 기억에 다시 시작해보려 한다. 

1. IoC ( inversion of control) 

제어의 역전 이 말만 보았을 때는 정확히 무슨의미 인지 모르겠다. 

아무튼 역사를 보면 자바 기반의 어플리케이션이 개발되던 초기에는 자바 객체를 생성하고 객체 간의 의존관계를 연결하는 등의 

제어권을 개발자가 직접 가지고 있었다고 한다. 그러나 서블릿, EJB가 등장하면서 개발자가 독점적으로 가지고 있던 제어권이 서블릿과 

EJB가 등장하면서 개발자가 독점적으로 가지고 있던 제어권이 서블릿과 EJB를 관리하는 외부의 컨테이너로 넘어갔고 객체의 생성부터 생명주기의 관리까지 모든 객체에 대한 제어권이 바뀐 것을 IoC, 제어의 역전이라 하는 것이다. 

스프링의 중요한 핵심중 하나인 IoC에 대해 알기 전에 자바관련해서 몇 가지 짚고 넘어가야 한다. 

Class - 설계도

Object - 실체화가 가능한 것 

Instance - 실체화가 된 것.

예를들어

리그 오브 레전드에는 누누라는 캐릭터가 있고 랭크 게임이든 일반 게임이든

큐를 잡고 들어간 게임에서 존재할 수 있는 즉, 실체화가 가능한 것을 Object라고 한다다. 

그리고 내가 실제로 누누를 플레이하게 된다면 누누는 실체화된 instance가 되고 

누누는 heap memory에 올라가게 된다. 

그런데 내 친구도 누누를 플레이하려고 한다. 

그리고 내 친구는 내가 누누를 플레이하는지 모른다. 

그래서 친구 역시 누누를 플레이할 때 누누가 instance가 되고

이 역시 heap memory에 들어가게 된다. 

heap memory에 같은 누누가 두 개가 들어가게 되면 이는 비효율적일 거라 생각이 든다.

그래서 내가 친구에게 누누를 하고 있다고 말해주어 생성된 인스턴스를 넘겨주고 싶지만

이를 프로그래밍으로 해결하기에는 꽤나 복잡하고 어려운 작업이라고 한다. 

그래서 Spring에서 이를 해결해준다.

Spring이 instance 가능한 객체를 읽어와 heapmemory에 올려주고 이를 사용하게 되는 것.

다시 챔피언으로 돌아와 누누 더 나아가 모든 챔피언에 객체에 대해 heap memory로 올려준다. 

이렇게 한 번만 객체를 생성해서 사용하기 편리하게 도움을 주는 것.

2. DI (Dependency Injection)

의존성 주입

예를 들어 이전에는 생성한 객체에 대한 주소를 내가 관리를 했다면

이제는 내가 아닌 Spring이 객체들을 메모리에 적재시키고 ( 제어의 역전 )

Spring에서 내가 원하는 모든 곳 클래스의 메서드에서 가져와서 사용이 가능해진다. 

이를 싱글톤이라고 하며 사용되는 곳에 인스턴스를 DI 주입해주는 것.

참고 url :

https://gangnam-americano.tistory.com/60

https://www.youtube.com/watch?v=mAFLNA9MYg8&list=PL93mKxaRDidG_OIfRQ4nztPQ13y74lCYg&index=2 

다른 사람들에겐 어처구니 없는 실수일수도 있고 나에게는 꽤나 머리아프고 시간을 잡아먹은 오류였는데 다시 보니 부끄럽기까지 하다. 

익숙치 않은 영어에다 컴포넌트들을 app.jsx파일에 한데 모아놓으니 어디에서 실수가 나왔는지 이해도 잘안가고 그랬었다. 

구글링을 해보았지만 크게 도움이 되지 않았고 결국엔 뇌피셜을 굴려서 해결을 했는데 

일단 Header 컴포넌트에서 문제가 있다는 것. 

그리고 Header 컴포넌트 내부를 보아도 별문제가 없어 보였지만 시간을 오래동안 두고 보니 바로 눈에 띄워졌다.

당시의 Header 컴포넌트는 함수형 컴포넌트였고 ArrowFunction 컴포넌트였는데 

ArrowFunction에서 바로 리턴 값이 한줄이라면 별다른 괄호 없이 작성을 해도 되지만 

소스코드가 길어져 중괄호{}를 써야하는 입장이라면 return 문이 필요하다는 것이다. 

나의 코드는 중괄호에 간단한 h1 태그로 잘 나오나 확인하는 태그였고 나는 계속 오류를 못잡아 방황했다.

{} 중괄호를 작성해서 소스코드를 쓸때 리턴을 해주는걸 까먹지 말자..