Devstore

💻 서비스 소개

• 개발자에게 필요한 장비를 판매하는 쇼핑몰
• 베스트 아이템, 리뷰, 상품문의 등 소비자를 위한 서비스 제공
  
  

📎 관련 링크

• S3(클라이언트) : http://devstore-dev-deploy.s3-website.ap-northeast-2.amazonaws.com/
• EC2(서버) : http://storedve.shop
• API 스웨거 : API문서

🧑🏻‍💻 팀원 소개

프론트엔드
김용희(팀장)	이승미	최영웅	김현지
백엔드
이혜인(팀장)	이기호

📆 진행 기간

2023.05.30 ~ 2023.09.13

⚙️ 사용 기술

[ FRONT-END ]

[ BACK-END ]

📁 관련 문서

• 요구사항 정의서
• DB 다이어그램
• 화면설계서

Swagger 사용 방법

• Login 이 후 Authoriztion header에 있는 token key 값을 아래의 화면에 입력 (자물쇠 모양)

• 상품 등록 관련 삭제할 이미지 or 삭제할 option이 없다면 해당 배열을 빈 배열로 넘겨줘야합니다. 이미지를 등록할 때는 이미지의 순서 제어를 위해 대표값을 true, 나머자는 false, 이미지의 순서를 정해서 전달해 줘야합니다.

{
  "deleteImageId": [
  ],
  "deleteOptionId": [
  ],
  "updateOptionList": [
    {
      "optionId": 1,
      "optionDetail": "string",
      "optionName": "string",
      "itemCount": 0,
      "additionalPrice": 0
    }
  ],
  "imageSortAndRepresentativeInfo": [
    {
      "imageId": 1,
      "orderNumber": 1,
      "representative": true
    }
  ]
}

상품 수정 시 삭제할 이미지 및 옵션이 없으며, 이미지를 추가할 때의 JSON id들은 기본값이 모두 0으로 되어 있기 때문에 해당 부분을 수정하고 싶지 않다면 빈 배열로 전달해주시며 됩니다. 아래의 imageSortAndRepresentativeInfo 에서 이미 존재하는 이미지의 경우는 id값을 적어주고 새로 추가 등록하게 되면 null로 전달해 주시면 됩ㄴ디ㅏ.

작업 내용 (백엔드 개발자 - 이기호)

AWS 배포

배포

사진은 정적 데이터기 때문에 S3 저장소에 저장, 백엔드 서버의 경우는 EC2를 통해 배포 진행, DB는 AWS에서 제공하는 RDS의 MYSQL DB를 활용해 구현

• RDS의 보안을 위해 EC2와 가튼 VPC에 속하게 만들어 EC2에서만 접근이 가능하도록 설정, 이를 통해 RDS의 보안 상승
• AWS 접근 시 각각의 IAM의 발급을 통해 필요한 권한만을 프론트엔드 및 백엔드에 제공

프로젝트 구조

프로젝트 초기

Request -> Controller -> Service (비즈니스 로직 실행, Response Data 변경) -> Controller -> response 의 흐름으로 데이터 요청

이 방법은 2가지의 문제 발생

1. 각 계층이 강하게 결합이 되어있다.
2. 테스트 코드 작성 시 정확한 테스트를 하기 어렵다.
   • patch 요청을 받을 경우 response로 id를 반환하기 떄문에 service에서도 id만을 반환하게 된다면 test 시 id만을 검증하거나 다시 데이터를 조회해 테스트 진행
   • 그 결과 테스트 시 문제 발생

프로젝트 구조 변경

Request -> Controller -> Mapper(Entity 변경) -> Service(로직 실행, Entity 반환) -> Mapper(Dto 변환) -> response 의 흐름으로 데이터 변경

1. 계층 간의 이동을 Entity를 통해 진행
   • 계층간의 결합 약화 및 테스트 환경 구축, Service단의 역할 과부화 방지

결과

1. DTO -> Entity , Entity -> DTO 변환 과정 추가 발생
2. 계층 간 결합도 약화
3. 테스트 코드를 통해 개발자가 원하는 테스트 진행 가능

학습

• Mapper를 활용한 Class 변경 시 효율적인 관리를 위한 생성자 선택 회고
• 계층간의 이동 시 Entity 및 DTO 선택
• Repository 인터페이스를 통한 프레임 워크 의존성 약화(프레임워크 의존성 약화)

테스트 커버리지 80% 달성을 통한 신뢰성 있는 코드 작성

• 프론트엔드와의 배포 테스트 중 구현한 코드가 정상 작동하지 않는 문제 발생, 문제 해결한 뒤 다시 배포해서 협업 하는 과정에서 많은 시간이 소요된다.

단위 테스트 구현

• 코드의 신뢰성을 높이기 위해 단위 테스트 지행
• 단위 테스트를 통해 발생할 수 있는 예외, 성공에 대한 테스트 진행
• 이를 통해 각 모듈의 신뢰성 상승
• 단위 테스트만으로는 각각의 모듈들이 합쳐졌을 때 발생할 수 있는 문제에 대한 테스트 진행이 불가능해 완벽하게 신뢰할 수 없을 것이라 판단(Mock 객체 사용)
• 통합 테스트 진행의 필요성을 느낌

통합 테스트 구현

• 통합 테스트를 통해 각 모듈을 결합한 테스트 진행
• 이 과정에서 TestRestTemplate, MockMvc를 활용한 통합테스트에 대한 구현 학습
• 통합테스트의 목적에 따라 TestRestTemplate 과 MockMvc 중 택 1 하여 테스트 진행
  1. 실제 프론트엔드에서 데이터를 전송하는 것을 테스트 하고 싶다면 TestRestTemplate을 활용
  • 롤백이 불가능
  3. 각각의 모듈의 통합적인 테스트에 초점을 맞춰 테스트를 진행한다면 MockMvc를 활용

테스트 컨테이너 사용

도입 배경

• 통합 테스트를 TestRestTemplate으로 진행할 경우 같은 테스트를 여러번 진행할 때, 다른 개발자가 테스트를 진행할 때 동일한 테스트 결과를 보장하지 않는 다는 문제 발생

  • 롤백 불가능하기 때문

  • 테스트 컨테이너를 활용해 언제 어디서 누가 테스트를 실행하더라도 같은 테스트 결과를 출력할 수 있도록 테스트 컨테이너 구현

테스트 컨테이너 장점

1. 도커만 설치 되어 있다면 언제 어디서나 같은 환경에서 테스트의 진행이 가능
2. InMemory DB를 사용하지 않고 실제 배포 환경에서 사용하는 DB 모델을 활용하기 때문에 배포환경과 동일한 DB 환경 구축 가능 3.** 테스트 시에만 리소스를 사용**하기 때문에 리소스 낭비를 막을 수 있다. - 테스트 시 Docker에서 DB가 올라가고, 테스트 완료 시 컨테이너가 제거된다.

테스트 컨테이너 단점

1. 테스트 시 도커가 올라가고 DB에 데이터가 초기화 되는 시간이 추가적으로 발생

테스트 컨테이너 도입 의사 결정

• 테스트 컨테이너 사용 시 테스트 시간이 추가적으로 발생한다는 단점이 있지만 1번의 설정을 통해 언제 어디서나 동일한 테스트 환경을 구축 할 수 있어 통합테스트에 대한 신뢰할 수 있는 결과를 보장한다는 장점으로 인해 테스트 컨테이너 도입

결과

1. 작업 환경과 동일한 DB 환경에서 테스트 진행 가능
2. 언제 어디서나 동일한 테스트 결과 출력 가능
3. TestDB 리소스 낭비 방지
4. 테스트 실행 시 도커 컨테이너가 올라가는 추가 시간 발생

테스트 코드 강제화를 통한 코드 신뢰성 상승

1. Build 시 Test결과가 조건을 만족하지 않는다면 Build가 되지 않도록 Build 제한, 이를 통해 테스트 작성의 강제화 도입

학습

• Multipartform의 MockMvc, RestTemplate을 활용한 테스트
• 통합 테스트를 구현하는 과정에서 RestTemplate, MockMvc를 활용한 테스트 및 각각의 장단점 학습
• 테스트 커버리지 70% 이상 달성을 위해 약 300개의 테스트 진행 및 이를 통해 필요한 테스트와 불필요한 테스트를 선별하는 기준에 대한 학습

정적 테스트 도구 사용을 통한 코드 품질 개선

• jacoco + sornaqube 활용

도입 배경

• 코드가 많아짐에 따라 code smell 및 보안상의 오류를 파악하기 위한 도구필요
• 테스트 커버리지의 시각적인 표현 필요

도입 효과

1. 테스트 미진행 부분에 대한 빠른 확인이 가능
2. code smell의 빠른 파악이 가능 및 제거 가능
3. 테스트 커버리지 특정 수치 이하일 경우 Build가 작동하지 않도록해 테스트 강제화 가능

### 결과 1. 불필요한 코드 제거 2. 보안상의 이슈가 Security Hotspots 제거 3. 코드 품징 상승 효과 발생

정적 테스트 도구의 사용을 통해 문제가 있는 코드의 확인 및 변경을 통해 코드의 품질을 상승시킬 수 있으며, 작성한 테스트 코드의 커버리지의 시각화를 통해 부족한 테스트를 파악할 수 있다 sonarqube의 경우는 프리티어 환경에서 EC2에 배포하는 것은 무리라고 판단하여 LOCAL PC에서 DOCKER를 통해 기동

Filter를 활용한 Logging을 통해 Controller에 진입하지 못하는 요청에 대한 원인 파악

Controller에 진입하지 모하는 EndPoint에 대한 에러 원인을 찾는데 많은 시간 소모 발생 이를 해결하기 위해서는 Request요청이 Controller에 진입하지 않아도 무조건 확인할 수 있는 곳에 Logging 기능 구현이 필요 (AOP 사용 불가능) 이를 위해 서블릿 컨테이너에서 실행되는 Filter를 활용해 Logging 작업 구현

결과

EndPoint 오타로 인한 에러의 원인 빠른 파악 가능해 많은 작업 시간 단축 가능

학습

Filter 사용 방법 학습 인터셉터 사용 방법 학습

서비스 로직에 대한 구현 설명

연관관계 매핑에 의한 DB 데이터 삭제 에러 해결

문제 원인

특정 테이블의 row를 삭제하려고할 때 외래키 참조로 인해 해당 row를 삭제할 수 없는 에러 발생(참조 무결성 유지를 위한 참조되는 데이터의 삭제 불가)

해결

1. DB에서 외래키를 체크하는 옵션 생략
   • 참조 무결성에 문제가 발생할 가능성 존재
2. 연관관계를 미리 끊어 준 뒤 제거 (선택한 방법)

문제 해결 블로깅

SpringSecurity를 통한 인증 인가 기능 구현 미 Google OAuth2 인증 구현

HashMap의 특성을 활용한 성능 개선 O(m*n) -> O(n+m)

학습

• Controller로 JSON 데이터가 들어오게 되면 어떻게 Class로 매핑이 되는지 학습(왜 Dto들은 기본생성자가 필요한가)