본문 바로가기
개발자 일지/기타

[TIL]배운 내용 및 정리할 내용 요약

by 네빌링 2021. 8. 4.
반응형

요 근래 배운 내용들에 대해 간단하게 정리해둔다.


 오랜만에 블로깅 하니 어색하다. 요즘 vue, react 등 사용하는 서비스 회사들이 많겠지만 아직 프로젝트를 하면서 이런 기술들을 사용해보진 못했다. react 클론코딩 등으로 만족하고 있었는데..

 다행스럽게도 이번 프로젝트에서 기존에 써보지 못한 기술, 방법론 등을 많이 써보고 있다. 또 잘하는 윗분들이 많으니 배울 것도 많다. 감사한 일이라고 생각한다. 그러고보니 TIL(Today I Learned)은 아닌 것 같지만 그냥 TIL로 표기하고 앞으로 하루하루 배운 것들이 있으면 조금씩 써봐야겠다.

 

 프로젝트에서 다음과 같은 기술들을 사용한다.

 

  1. Vue.js : 싱글페이지어플리케이션(SPA)를 구축하기 위해 사용하는 프론트엔드 프레임워크를 사용하고 있다. 아직 퍼블리싱이 안 나온 상태고 공통 모듈 등이 덜 나온 상태라서 프론트엔드 작업을 제대로 못하고 있긴 하지만, 컴포넌트별 효율적으로 분리하고 vue life cycle 흐름에 맞게 좋은 코드로 만들도록 노력해야지. 
  2. restful api : 이것도 뭐 요새 아주 많이 쓰지만 제대로 처음 써보는 것 같다. 
  3. swagger : restful api를 사용하다보니 테스트를 위해 swagger라는 라이브러리를 사용한다. postman은 공부할 때 써 봤는데 swagger 프레임워크는 처음 써본다. restful api를 테스트하고 문서화하는데 문서화는 아직 안 써봐서 모르겠다.
  4. springboot5 : 써봤지만 vue.js와는 처음 써보니 처음 써보는 느낌
  5. JWT Token : 이것도 아직 정확하게 학습이 안 되서 추후 학습 프로젝트를 해보든지 해야겠다
  6. Source Tree : 부끄럽지만 처음 써봤다. git bash로만 했다. git bash로만 덤볐던 이유는 쓸데없는 오기가 항상 있어서(..)뭔가 CUI 환경으로 확실히 학습이 되면 소스트리 같은 GUI를 사용하려고 했는데 개인적인 생각으로 이번에 써보니까 바보같은 생각이었다. 개발자는 편리한 기술들을 잘 갖다써야 하는데 그걸 이제 쓰다니..어쨋뜬 써보니 아직 적응이 다 된건 아니지만 소스트리 쓰면서 깃을 통한 실무 협업에 대해 많이 배워야겠다.
  7. Visual Studio Code : 실무 프로젝트에서는 처음 써본다.
  8. java11 : 이건 프로젝트 권장은 아니지만 개인적으로 람다,스트림,Optional 등을 써보고 싶어서 써보고 있다.(써보고 있다고 해봤자 사실 아직 한,두군데밖에 안 써봤다) 뭐 1.8기술이지만..저저번 프로젝트에서도 조금씩 써봤는데 사용하는 이유와 목적에 대해 명확히 좀 더 공부하고 써야할 상황에서 잘 써봐야겠다.
  9. MSA : Microservice Architecture를 쓴다. 
  10. Redis : Redis는 쓴다고는 하는데 사실 아직 어디서 쓰고있는지 아직 잘 모른다. 
  11. lombok : 사실 많이 써봤지만 오랜만에 써본다.
  12. Azure : MSA 방식을 쓰다보니 Azure도 사용한다.

 

뭐 더 있는 것 같은데 일단 이정도로 정리해본다. 아래에서는 좀 정리할 필요가 있는 것들에 대해 간단하게 정리해본다.

 

Restful api

  • URI가 정보의 자원을 표현하고, HTTP Method를 통해 행위를 표현한다. 
  • CRUD 행위를 POST, GET, PUT, DELETE라는 HTTP Method로 표현한다. 약간 규칙같은 거라고 보면 된다. 
    • ex) GET /human/1 : 1번 휴먼정보를 가져옴
    • ex) DELETE : /human/2 : 2번 휴먼정보를 삭제함
  • 스프링부트 컨트롤러 메소드에는 @PostMapping, @GetMapping, @PutMapping, @DeleteMapping 어노테이션을 사용하면 된다. 
  • Restful 방식은 컨트롤러에서 @Controller가 아니라 @RestController를 사용한다. 예전에는 @Controller를 선언하고 메소드 반환타입에 @ResponseBody 어노테이션을 써야 했는데 스프링부트4.x 버전부터 @RestController를 사용하면 메소드마다 @ResponseBody 선언을 안 해도 view가 아닌 데이터 자체로 반환된다.
  • URI의 각 고유값(GET /human/1이라면 1)은 @PathVariable로 받으면 된다.
  • 테스트는 postman, swagger 등을 사용하여 테스트한다. 또는 vscode에 Rest Client이라는 extension을 사용하여 테스트할 수 있다.  

 

Git, Source Tree

 

충돌(Conflicts)

충돌(Conflicts) 목표 충돌이 무엇이고, 언제 생기는지를 설명한다. 병합(머지, merge)로부터 생기는 충돌을 해결한다. 사람들이 병렬로 작업을 할 수 있게 됨에 따라, 사람들이 누군가의 영역을 침범

statkclee.github.io

 

람다, 스트림

 사실 안 써도 프로젝트하는데에 큰 문제는 없지만, 알아두면 좋다. 프로젝트를 하면서 람다스트림 코드를 1~2번 보기도 했고, 이해하려면 일단 알아야 하기도 하기 때문에 이번 프로젝트에서 간간이 써보려고 한다. 학습은 주말에 좀 해서 올려야겠다. 

  • 스트림은 말그대로 흐름인데 데이터의 흐름을 말한다. Array,Collection(List 등)에 함수 조합을 하여 가공한 데이터를 얻을 수 있다. 뭐 for문 같은 것으로 Array 등을 다룰 수는 있지만, 코드가 길어지면 로직이 복잡하게 되고 섞이게 된다.
  • 람다를 스트림과 이용하여 코드를 간결하게 줄이고 함수형 프로그래밍으로 자바를 다룰 수 있다.
  • 스트림은 크게 3가지로 나눌 수 있다.
    • 생성하기 : list.stream()같은 방식으로 스트림을 시작
    • 가공하기 : filter(), map() 등을 통해 원하는 데이터를 가공할 수 있다.
    • 결과만들기 

 

Optional

 NullPointerException 체크할 때 if (list != null) 같은 로직을 많이 쓰는데 이런 비슷한 것들이 남발되는 것들을 좀 더 깔끔하게 Optional 객체를 사용하여 처리할 수 있다. Java1.8부터 사용할 수 있는 메소드이다. 즉, Optional은 NullPointerException이 발생하지 않도록 값을 감싸는 Wrapper 클래스이며 이를 사용하여 NPE처리를 좀 더 깔끔하게 할 수 있다. 

 

  • 1.Optional 객체생성
    • Optional 객체 생성은 ofNullable()을 통해 생성 가능하다. ofNullable()의 인자로는 NPE를 발생시킬 가능성이 있는 값을 넣어준다. 이 때 이 값이 null이면 빈 Optional 객체를 반환한다. 
  • 2.isPrensent()로 존재여부 확인 후 로직 처리
    • Optional 객체 안에 값이 null인지 아닌지 판단하는 메소드이다. if 조건으로 준 후에 로직을 처리하면 된다.
  • 3.get()을 이용하여 Optional 객체 안의 값을 반환
    • Optional 객체 안의 값이 있는지 isPresent()로 확인 후, get()을 사용하여 객체 안의 값을 꺼낼 수 있다.

 

위에서 말한 1,2,3을 조합하여 아래와 같은 방식으로 사용할 수 있다.

List<String> list = null;

Optional<List<String>> optional1 = Optional.ofNullable(list);

if (optional1.isPresent()){
    System.out.println("Optional 객체 안에 값이 존재");
}else{
    System.out.println("Optional 객체 안에 값이 미존재");
}

list = new ArrayList<>();

Optional<List<String>> optional2 = Optional.ofNullable(list);

list.add("테스트1");
list.add("테스트2");

if (optional2.isPresent()){
    System.out.println("Optional 객체 안에 값이 존재");

    List<String> gotList = optional2.get();

    for (String value : gotList){
        System.out.println(value);
    }
}else{ 
    System.out.println("Optional 객체 안에 값이 미존재");
}

//결과
//Optional 객체 안에 값이 미존재
//Optional 객체 안에 값이 존재
//테스트1
//테스트2

 

  • 4.orElse()를 사용하여 null인 경우 반환값을 설정
    • orElse()라는 메소드로 값이 Optional 객체 안의 값이 null이면 반환 값을 설정할 수 있다.

아래 코드처럼 테스트해봤다.

 

 //테스트2.orElse()
String str = null;

Optional<String> optional3 = Optional.ofNullable(str);

str = optional3.orElse("orElse로 받아온 값");
System.out.println(str);

str = "hoy";
Optional<String> optional4 = Optional.ofNullable(str);
str = optional4.orElse("orElse로 받아온 값");
System.out.println(str);

//결과
//orElse로 받아온 값
//hoy

 사실 다른 선배들도 그렇고 Optional 쓰는 분은 우리 회사에서 못봤다. 굳이 쓸 필요가 있나 싶어서 안 쓰시는 것 같기도 하고 아무래도 단순 null처리가 더 익숙하고 직관적일 수가 있으니 팀프로젝트에서는 자제하는 것일 수도 있을 것 같다. 

 

 임시저장만 해두고 이제서야 좀 더 Optional 테스트를 해보고 글을 추가했다. 뭔가 다 만들고 공개하면 한세월 걸릴 것 같아서 이정도로 공개 포스팅 하고 시간 날 때마다 살을 붙여놔야겠다.

 

 

반응형