알파벳 백엔드 리팩토링 - 1

시작에 앞서 홈페이지가 궁금하신 분들은 여기서 확인 하실 수 있습니다.

 

우여곡절끝에 홈페이지를 완성해서 올렸습니다.

이렇게만 하면 끝날 줄 알았는데 여러가지 요구사항이 쏟아져 어쩔 수 없이 이를 위한 서비스 코드들을 생산해야 했고, 당연히 이는 곧바로 기술 부채로 이어졌습니다.

블로그에 기록하기 민망한 수준이지만 어차피 하나하나 차근차근 해결하는 중이기에 기록에 많은 시간이 들지는 않을 것 같아 시작하려 합니다.

 

먼저 알파벳은 2가지 큰 기능이 서비스 중 입니다.

1. 웹 뷰

2. 정말 단순한 api

 

1번은 말 그대로 홈페이지로서 기능하기 위해 먼가 뷰를 리턴해주는 기능입니다.

2번은 요즘 깃허브에서 정말 핫한 프로필에 뱃지를 보여주는 서비스입니다.(제 블로그 소개글에도 적용되어 있습니다)

 

앞으로 해결해야 할 문제는 여러가지가 있겠지만, 당장 DB 관련해서 문제가 있었습니다.

파라미터로 학번을 넘겨주면 그에 맞는 뱃지를 리턴해주는 서비스에서 학번을 그냥 하드코딩으로 넣어뒀기 때문입니다.(그만큼 급하셨다는거지...)

그렇다고 AWS위에 올려둔 서비스라서 ec2 자체에 DB를 설치해 문제를 해결하기에는 비용 문제가 있었습니다.

이 경우 가장 이상적인 방법은 RDS를 이용하여 문제를 해결하는 방법인데 당시에는 제가 많이 부족하여 불가능했습니다.

이런 이유로 서버 안에 급하게 텍스트 파일로 회원 정보를 저장하고 이걸 가져다가 서비스 하는 식으로 구현을 했습니다.

 

이후 당연히 이 텍스트 파일을 DB로 전환하는 작업이 이어졌습니다.

1. RDS를 생성하여 접근되는지 확인

2. DB를 위한 서비스 코드 생산

 

1번 작업은 뭐 당연한거고 설정 잡는데 문제가 있었지만 금방 해결 했습니다.

2번은 또 새로운 내용이라 시간이 좀 걸렸습니다.

스프링 부트에서 JPA를 이용하여 DB를 활용하게끔 하는 내용이었고 카카오 커머스 2차 시험 내용과 상당히 유사했습니다.

엔티티, 레포지토리, 서비스, 컨트롤러로 이어지는 아주 일반적인 구조로 별로 새로운 내용은 없습니다.(갓 lombok)

다만 테스트를 위해 넣어둔 코드가 빌드때마다 돌아가서 DB 테이블을 날려주는 트롤링으로 한 3시간을 헤맸습니다.

(왜 null exception을 받는거지? -> 생성자 왜 없어? -> 어노테이션 미스냈네 -> 왜 Out Of Bound? -> DB 비어있다고? -> 진짜 텅비었네 다시 넣고 실행 -> 잘되네 다시 빌드해볼까? -> 왜 Out of Bound? -> .....)

 

이렇게 지금까지의 알파벳 리팩토링에 대해 알아봤습니다.

이제 당연하지만 왜 테스트 코드가 빌드때마다 DB 테이블을 날렸는지 원인을 찾고 적당한 테스트 방법을 찾아야 합니다.....

분명 기술 부채를 해결하려고 많이 노력하는데 문제가 계속 나옵니다.

그리고 이번주 중으로 또 새로운 기능을 추가하라고 합니다.(받아라 똥코드ㅋㅋㅋ)

과연 잘 마무리 지을 수 있을까요? 응원해 주세요