인프런 워밍업 클럽 2기 - 백엔드 프로젝트(Kotlin, Spring) / 4주차 발자국

인프런 워밍업 클럽 2기 - 백엔드 프로젝트(Kotlin, Spring) / 4주차 발자국

image

1주 동안 배운 내용을 정리하고 회고하는 시간을 가져보자.

 

16~18 일차 - Admin View

View

3주차에 이어서 Admin View를 만들어보게 되었다.

image

이번에도 마찬가지로 중복되는 부분을 fragment와 layout으로 분리하는 작업을 진행했다.

그리고 사용자가 직접 업데이트 하는 부분이 있기에, 추가적으로 script-util 파일을 통해 API에 요청을 보내도록 했다.

 

19 일차 - GCP, Docker

암호화

배포 이전에 설정 값을 암호화 하기 위해 jasypt를 사용하게 되었다.

Jasypt?

  • 애플리케이션을 배포할 때 공개되면 안되는 값들이 평문으로 올라가는 것을 막기 위해 암호화할 수 있는 라이브러리이다.

아래는 암호화한 DB 비밀번호가 들어있는 설정파일의 일부분이다.

  datasource:
    url: jdbc:mysql://mysql:3306/portfolio
    username: root
    password: ENC(ZeronFrlX1yD4JW496HshMgc9t1kUrQi)
    driver-class-name: com.mysql.cj.jdbc.Driver

ENC(암호화 내용)으로 내용이 암호화 되었음을 표시해야한다.

 

배포

Docker를 이용해서 빌드 한 이미지를 Docker hub에 올리고 이를 서버에서 내려받아 사용했다.

image

이후 GCP를 이용하여 서버를 생성하고, Docker를 이용해 MySQL과 프로젝트를 빌드 시켰다.

image

마지막으로 도메인을 연결하고, 이를 제출하며 마지막 7번째 미션도 해결 할 수 있었다.

결과물은 아래와 같다.

Dongguk's Portfolio

 

20일차 - 서브 미션, 코드 리뷰

3주차 때와 일정이 거의 겹쳐 3주차 발자국에 포함시키지 못했던 미션 5는 4주차에서 소개하겠다.

각 API마다 3개의 테스트 코드를 작성해야 했기에 열심히 작성해서 테스트를 진행해보았다.

 

이번에도 관련 내용은 README에 정리했다.

https://github.com/ppusda/MML

 

이후 마지막에는 최종 점검과 코드 리뷰 시간이 진행되었다.

https://github.com/ppusda/MML/pull/1

많이 배워갈 수 있었던 좋은 시간이 되었던 것 같아서 조언 받은 내용을 정리해보고자 한다.

 

Rest API와 Versioning

Rest API

API를 작성할 때 Restful 하도록 고려를 하는 편이라고 생각했지만, 주의하지 못했던 부분이 있었다.

  • 자원을 복수형으로 명시

    • /user/users

Versioning

사실 지금까지 코드를 작성해보면서 “API에 버저닝이 굳이 필요할까?” 라고 생각해서 배제 했었다.

하지만 이번 코드리뷰를 받아보면서 버저닝의 중요성을 알게되었다.

  • API의 기능이나 데이터 구조가 변경될 때, 기존 클라이언트가 정상적으로 작동하도록 하기 위해 버전 관리를 통해 이전 버전을 유지하도록 사용할 수 있다.

⇒ 사용자가 원하는 버전을 사용하도록 할 수 있고, 업데이트 시기를 사용자가 정하도록 할 수 있다.

이로 인해 호환성과 안정성을 챙기고 사용자 경험을 개선시킬 수 있다는 것을 알게되었다.

 

find 와 get의 차이

이 부분에 대해서는 진지하게 고민해 본 적은 없었던 것 같다.

간단하게 find는 “DB에서 찾기”, get은 “찾아온 데이터를 가져오기”라고만 생각하고 코드를 작성했었다.

 

하지만 코치님께서 소개해주신 내용을 통해 좀 더 시선을 달리하게 되었다.

How and why to decide between naming methods with "get" and "find" prefixes

 

get~은 실패하지 않으며 짧은 시간으로 요소를 가져올 때 사용되는 단어.

find~는 실패할 수 있으며 긴 시간이 소요되어 요소를 찾아낼 때 사용되는 단어.

 

위 내용을 참고해서 앞으로 메서드 네이밍을 사용할 때 주의해야 할 것 같다.

 

Test code 방향성

요즘에 가장 관심이 많이가고 그만큼 잘 모르겠는 내용이 테스트 코드이다.

이번에 테스트 코드를 강의를 기반으로 혼자 프로젝트에 작성해다보니까 방향성에 대해 의문이 많이 들었다.

 

“이런 테스트 코드를 어떻게 짜면 좋은건지 모르겠다” 라고 질문 드렸는데, 그 부분에 대해서 커버리지를 최대한으로 채워보면서 감을 익히면 좋을 것 같다고 말씀해주셨다.

 

추가로 관련해서 좋은 레퍼런스를 추천해주셨다.

토스ㅣSLASH 21 - 테스트 커버리지 100%

 

내용을 들어보고 서브 미션 프로젝트를 고도화 할 때 좀 더 좋은 테스트 코드를 작성하도록 노력해볼까 한다.

 

총 회고

4주차로 스터디가 마무리 되었다.

이번 4주차에는 일정이 너무 많고 도저히 시간이 안나기도 했지만, 강의를 보면서 따라 친 부분들이 잘못 입력되어서 동작하지 않는 곳들을 찾아내는데 고생을 좀 하게 되었다.

이상하게 로컬 환경에서는 잘되었는데, 배포만 하면 고장이 나서 원인을 찾기가 힘들었지만, 너무 간단한 오타들이어서 허무했다.

 

강의도 끝나고 더 이상 미션도 없어서 강제성은 사라졌지만 계속해서 나름대로 고도화를 진행해보려고 한다.

최종 점검에서 아직 나의 부족한 모습들을 많이 보게 되었지만, 여러모로 자극도 많이 받아서 힘들어도 계속해서 학습을 이어나가려고 한다.

 

코치님도 너무 친절하셨고 꾸준하기가 쉽지 않아서 많이 몰아들었지만, 어찌저찌 마무리를 하게 되었다.

이상의 내용은 개인 블로그에 완전 총 회고로 다시 한 번 작성하겠다.

 

모두 화이팅! (o゚v゚)ノ

댓글을 작성해보세요.

채널톡 아이콘