8000 GitHub - Lee-Jungyu/cafe
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Lee-Jungyu/cafe

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

30 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

cafe

프로젝트 계획 이유

스프링 부트 환경에 익숙해지기 위해 기초적인 스프링부트 프로젝트를 만들어 보았습니다.

카페 애플리케이션을 통해 사용자 인증과, JPA, TDD에 대해 공부하려고 합니다.

실행 방법

intelliJ Community Edition IDE 기준

  • git clone
  • intellij 실행 후 open project
  • src/main/resources/application.properties 내부 server.port 확인
    • server.port에 입력된 포트번호로 서버가 돌아갑니다.
  • src/main/java/com/jglee/cafe/Application.java에서 재생 버튼(녹색 삼각형 모양) 눌러서 서버 실행
  • localhost:포트번호로 접속 (port 번호 변경 안했다면 3000번 -> localhost:3000)

프로젝트 UI


Why I use JWT?

  • JWT와 비교되는 인증 방식으로는 세션-쿠키 방식이 있습니다.
  • 세션-쿠키 방식은 쿠키에 저장된 session id 값을 통해 서버에서 user의 정보를 알 수 있는 방식입니다.
  • 다만, 세션-쿠키 방식은 서버에서 세션에 대한 데이터를 계속 갖고 있어야 하고 이로인해 추가적인 저장공간이 필요하게 되어 부하가 높아집니다.
  • 이에 반해 JWT방식은 클라이언트에게 토큰을 건네주고 서버는 토큰을 해석하여 사용자 정보를 인증하는 방식으로 세션-쿠키 방식에 비해 부하가 적어집니다.
  • JWT 또한 단점이 존재하는데 이미 발급받은 토큰을 없앨 수 없으므로 유효기간 중의 토큰을 탈취당하면 보안적으로 위험합니다.
  • 이에 대한 해결책으로 Access/Refresh Token을 사용하는 방법이 있습니다.

TDD (Test-driven Development)

여기에 적혀있는 장·단점은 저의 기준으로 적은 것임을 미리 알려드립니다.

  • 특징
    • 테스트를 먼저 만들고 테스트를 통과하기 위한 코드를 작성
    • 실패하는 테스트 케이스 작성 → 성공하는 테스트 케이스 작성 → 코드 리팩토링
  • 장점
    • 테스트 시간 감소
      TDD를 사용하지 않고 변경된 결과를 테스트하고 싶을 경우 서버를 재가동해야 합니다. 또한 기능들을 테스트하려면 postman 혹은 FE 화면에서 직접 개발자가 기능을 실행해야 합니다. 기능에 변경이 발생할 때마다 이러한 작업을 하게 된다면, 테스트에 들어가는 소모되는 시간 비용은 생각보다 큽니다. 하지만 미리 테스트 코드를 작성하고 구현 코드를 변경하게 된다면 테스트 코드를 실행하는 것만으로도 변경된 결과를 파악할 수 있습니다. 따라서 TDD를 사용하면 테스트에 들어가는 시간이 감소하게 됩니다.
    • 기능의 목적이 뚜렷함
      테스트 코드를 작성하지 않고 기능을 구현하다 보면 개발자 본인이 구현하려고 하는 기능의 목적을 잊게 되는 경우가 종종 발생합니다. 그래서 목적을 잊고 구현 코드를 작성하다 보면 실제로 필요하지 않은 코드들이 뒤죽박죽 섞여 들어가는 일이 발생합니다. 하지만 테스트 코드를 미리 작성하면 기능의 실행 결과가 분명해집니다. 그 이유는 작성된 테스트 코드를 기반으로 기능을 구현을 하게 되기 때문입니다. TDD는 테스트 결과가 나오는데 필요한 만큼 코드를 구현하고 더욱 깔끔한 코드를 작성할 수 있게 만들어줍니다.
    • 코드의 변화에 대한 대비
      프로그램을 만들다 보면 기능을 추가하거나 수정하거나 삭제해야하는 일이 발생합니다. 어떠한 기능이 다른 기능에 의존적이게 된다면 코드 변화에 대한 side-effect가 발생할 수 있습니다. 테스트 코드를 작성하는 것은 이러한 side-effect가 발생할 때 대처할 수 있습니다. 코드에 변화가 발생할 경우 다시 테스트 코드를 실행하게 되고 테스트 결과가 예상과 일치하는지만 파악하면 됩니다. 테스트 결과가 예상과 일치하다면 side-effect가 없다고 봐도 무방합니다. 하지만 테스트 결과에 변화가 발생할 경우 side-effect가 발생한 경우이고 어떤 부분에 변화가 발생됐는지도 테스트 코드는 알려주기 때문에 해당 코드만 수정하면 됩니다.
  • 단점
    • 어려움
      기존 TDD를 사용하지 않고 개발하는 방법과 TDD를 사용하고 개발하는 방법은 과정이 많이 다릅니다. 기존의 방법은 기능을 설계하고 설계된 코드를 구현하고 구현된 결과를 테스트하는 방법으로 진행됩니다. 이 방법은 생각의 흐름대로 개발을 진행하기 때문에 TDD에 비해 쉽습니다. 이에 반해 TDD는 기능을 설계하고 테스트 코드를 작성하고 테스트가 성공하게끔 코드를 구현합니다. TDD가 어려운 이유는 기존의 개발 방법과 다르기 때문에 어렵습니다. 테스트 코드를 작성하기 위해 알아야 하는 것(테스트 코드 작성 방법, 문법, TDD를 사용하기 위해 익혀야 하는 툴...)을 배우기가 힘듭니다. 또한 테스트 시나리오를 작성하는 것이 익숙하지 않습니다. 처음부터 완벽한 테스트 시나리오를 생각하기는 쉽지 않습니다. 실제로 테스트 코드를 작성한 후 개발을 하다가 생각나는 예외들이 발생합니다. 이런 경우 테스트 시나리오를 다시 생각하게 되고 테스트 코드를 다시 작성하게 됩니다. 테스트 코드를 모두 작성하고 테스트 하는 것은 효율적인 일이지만 테스트 코드를 작성하는 데 많은 정성을 들여야합니다.
    • 개발 시간이 길어짐
      TDD를 사용한다는 것은 테스트 코드를 작성한다는 것입니다.
      TDD 방법의 개발 시간 = 기존 개발 방법의 개발 시간 + 테스트 코드를 작성하는 시간
      이때 테스트 코드의 길이는 경험상 테스트를 할 코드의 길이만큼 길어지게 됩니다. 그래서 기존의 개발 시간보다 오래 걸리게 되고 이는 생산성의 저하를 불러오게 됩니다. 따라서 시간이 촉박하지만 TDD를 사용해야 할 때 테스트가 필요한 경우에 한해서 테스트 코드를 작성하는 것 또한 하나의 방법인 것 같습니다.

JPA (Java Persistence API)

  • JPA란?
    • 자바 ORM 기술에 대한 표준 명세 (자바에서 제공하는 API)
    • 자바 어플리케이션에서 관계형 데이터베이스를 사용하는 방식을 정의한 인터페이스
    • 2019년에 Jakarta Persistence로 이름이 바뀌었습니다.
  • ORM (Object-Relational Mapping)
    • 객체지향 프로그래밍은 클래스를 사용하고, 관계형 데이터베이스는 테이블을 사용하기 때문에 객체 모델과 관계형 모델 간에 불일치가 존재합니다.
    • 이를 ORM을 사용하여 객체 간의 관계를 바탕으로 SQL을 자동으로 생성하여 불일치를 해결합니다.
    • 즉, 객체와 관계형 데이터베이스의 데이터를 자동으로 매핑(연결)해주는 것입니다.
  • 장점
    • 객체 중심적인 개발 가능
      기존의 SQL 중심적인 개발에서 객체 중심적인 개발이 가능합니다.
      객체 지향 프로그래밍은 추상화, 캡슐화, 정보은닉, 상속, 연관, 다형성 등 프로그래밍 시 코드의 생산성을 높이고 시스템의 복잡성을 제어할 수 있는 다양한 장치를 제공하는 데에 목표를 둡니다. 반면 관계형 데이터베이스는 데이터를 잘 정규화해서 저장된 데이터의 중복을 줄이고 일관성을 높이는 데에 목표를 둡니다. 이런 점에서 관계형 데이터베이스와 객체 지향 간의 패러다임 불일치가 나타납니다.
      JPA는 이러한 패러다임 불일치를 해결해줍니다. 우리가 개발하는 Java ApplicationJDBC API 사이에서 SQL Mapping 과정을 수행하기 때문입니다. SQL Mapper를 사용하여 SQL 중심적인 개발을 했을 때 개발자가 중간에서 변환하던 작업들을 JPA가 자동으로 해결합니다. 따라서 개발자는 이러한 과정을 JPA에 맡기고 조금 더 객체 지향적인 코드를 작성할 수 있게 됩니다.
    • 생상성 증가
      기존 SQL Mapper를 사용한 프로그램은 RDB 처리를 하기 위한 모든 기능(CRUD)을 SQL로 구현을 해야 했습니다. 이는 개발자가 비슷한 SQL 코드를 계속 반복해서 찍어내는 작업을 하게 합니다. 반면 JPA는 기본적인 CRUD 기능을 제공하고 페이징 처리 등이 구현되어 있어 개발자는 로직에만 신경쓰면 됩니다.
    • 유지보수 용이
      프로그램에 변경사항이 발생하면 SQL 중심적인 개발에는 치명적일 수 있습니다. Entity에 column이 하나 추가되는 것만으로도 전체 SQL 코드를 수정해야 하는 일이 발생할 수 있습니다. 그리고 만약 사용하는 DBMS를 바꾸게 된다면 DBMS에 맞게 SQL 코드를 모두 수정해야 합니다. 반면 JPA는 Entity를 SQL로 매핑하는 역할을 자동으로 제공하기 때문에 Entity에 수정이 발생하더라도 그에 맞는 유연한 대처를 할 수 있습니다. 또한 JPA는 DBMS에 독립적이기 때문에 사용하는 DBMS에 관계없이 같은 코드를 사용할 수 있습니다.
  • 단점
    • 어려움
      JPA를 잘 사용하기 위해서 알아야 하는게 너무 많습니다. 단방향, 양방향, 임베디드 관계, 매핑 전략, 쿼리방법 등 다양하게 많은 것을 알아야 합니다. 이러한 것들을 무시하고 편하게 코딩하면 성능 상의 문제 혹은 데이터 불일치 문제가 발생할 수 있습니다.

log

About

No description, website, or topics provided.

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published
0