4주 차: 알림 기능 찾아 삼만리 Day 18 - 아마도 마지막 리팩토링(Refactoring), 끝을 향하여 (1)

[알림 기능 찾아 삼만리 링크 1주 차: (1) (2)]

[알림 기능 찾아 삼만리 링크 2주 차: (3) (4) (5) (6) (7) (8) (9) (10)]

[알림 기능 찾아 삼만리 링크 3주 차: (11) (12) (13) (14) (15) (16) (17)]

 

[TIL Day 149 - 중간 발표회 피드백 모음]

 

중간 발표회에 좋은 피드백을 받은 뒤, 팀에서는 남은 일정을 점검하고 계획을 조정하며 하루를 마무리했다. 5주 차는 사실상 문서 작성 및 발표 준비 기간이라서 이번 주에 최대한 개발 일정을 마쳐야 했다. 눈꺼풀 위에 돌덩이를 하나씩 얹은 양 계속 눈이 감겼지만, 더 나은 이메일 알림 기능을 만들기 전에 이름 변경 같은 리팩토링(refactoring)을 진행했다.

 

1. 이름 수정 [깃허브 링크]

일단 'UserToJobOpeningMapping' 클래스는 다대다 연관관계(N:M)에 쓰이는 중간 테이블이 아니라, 이메일이나 푸시(Push)로 전송하려는 '알림'이므로 이름을 'UserToJobOpeningMapping'에서 'Notification'으로 수정했다. 나머지도 이와 같은 이유로 수정했다.

 

2. 불필요한 레이어(Layer) 삭제 [깃허브 링크]

하는 일이 겹치는 레이어는 삭제했다.

단순히 불필요한 레이어를 삭제하고 여러 클래스의 이름을 고쳤을 뿐이지만, 혹시 몰라서 새벽에 이메일을 보내봤다. 다행히 이메일 알림은 문제없이 전송되었다.

 

3. private 메서드로 추출 [깃허브 링크]

그다음으로는 로직을 어떻게 나눌지 고민하다가, 각 로직을 클래스로 나누지는 않되 private 메서드로 추출해서 public 메서드에서 흐름이 잘 보이도록 했다. 만약 구현체를 보고 싶다면 맨 아래에 추출해둔 private 메서드로 확인할 수 있도록 리팩토링했다. 

 

(1) 리팩토링 전 Notification Service ▼

(2) 리팩토링 후 Notification Service ▼

(3) 리팩토링 후 Notification Service의 맨 아래 추출한 private 메서드 ▼

4. Delete 메서드 호출 시 Request Body 대신 Request Param 사용 [깃허브 링크]

원래는 사용자가 선택한 키워드를 삭제할 때 Request Body로 Delete 메서드를 호출하도록 했는데, 프론트엔드(Frontend)에서 메서드를 호출하지 못할 수도 있어서 Request Param을 대신 사용했다. Request Param으로도 데이터를 한꺼번에 삭제할 수 있었다.

 

5. 기타 [깃허브 링크 (1) (2)]

기술적 의사결정을 내리기 전에 마지막으로 사용하지 않는 클래스를 삭제하고 이름을 고쳤다. 중간 발표회 이후에 리팩토링한 터라 정말 졸렸지만, 고민 하나가 머릿속을 맴돌았다.

 

'이메일 전송 로직을 분리해야 할까? 해야 한다면 그 이유는?'

 

Day 19에서 계속…….