[JPA] ⏰타이머 과제

🐤 리팩토링 과정 및 트러블 슈팅

1. [문제 인식 및 정의]

: 처음에는 현재 댓글의 contents 필드에 길이 제한 어노테이션이 없는 것을 보았다. 그래서 CommentRepositoryTest.java에서 길이제한을 확인하는 테스트를 시행해본 결과, 기본적으로 255자의 제한이 있음을 확인하였다. (255자 전후로 테스트 성공/실패)

이는 JPA에서 길이제한 어노테이션을 명시하지 않으면 DB에서 기본값인 VARCHAR(255)로 처리되기 때문임을 알게되었다. 서버에서 명시적인 제약 없이 DB의 제약만을 따르는 것은 추후에 요구사항 변경시 유연한 대응이 어려운 구조라는 생각이 들었다.

2. [해결 방안]

2-1. [의사결정 과정]

기존의 255자 제한은 충분하지 않다고 판단되어 500자까지 허용하는 구조로 리팩토링하고자 함

2-2. [해결 과정]

• 길이제한_확인용_테스트() 에서 500자 저장을 시도하면 DataTooLongForColumnException이 발생함
• Comment 엔티티의 contentes 필드 위에 길이제약 명시. @Column(length = 500)
• DB에도 수동으로 DDL 수행. ALTER TABLE comments MODIFY contents VARCHAR(500);

3. [해결 완료]

500자일때 테스트 성공

501자일때 테스트 실패

3-1. [회고]

눈으로 흝어볼 땐 분명 Comment 엔티티의 contents 필드에 길이제한이 없어서 오히려 DB가 과부하 될까봐 걱정했는데, 이를 확인하기 위해서 테스트 코드를 실행해보니까 길이제한이 걸려있어서 당황스러웠다. 이를 통해 상황판단을 할 수 있었는데, 테스트코드가 없었더라면 실제로 실행해보기 전까지는 확인이 어려웠을 부분이다. 테스트코드의 필요성과 유용함을 느낄 수 있었다.

코드상으로는 유효성 제약이 없어보이더라도, JPA에서 @Column을 통한 길이제한에 대한 명시가 없으면, 기본적으로 DB의 기본값을 따른다는 것을 알게 되었다. 하지만 이를 변경하기 위해 @Column만 선언한다고 해서 DB의 컬럼까지 자동으로 변경되지는 않았고, DB에서도 명시적으로 DDL을 수행해주어야 했다. 이러한 과정을 통해서 추후에 요구사항 변경이 있을 시, 유연하게 대응할 수 있도록 리팩토링하였다. 명시적 제약을 설정하지 않더라도 기본적인 동작들이 어떻게 돌아가는지 배울 수 있었다.

3-2. [전후 데이터 비교]

길이제약 리팩토링전, 500자 입력시 테스트 실패

길이제약 리팩토링 후, 500자 입력시 테스트 성공

 

---

🌕 프로젝트 회고

이번 프로젝트를 통해 단순히 작동하는 코드가 모두 성공적인 코드는 아니라는 사실을 깨달았다. 예전에는 기능이 정상적으로 동작만하면 충분하다고 생각했지만, 이제는 코드의 구조와 가독성, 유지보수까지 고려한 설계가 얼마나 중요한지 느낄 수 있었다.

리팩토링이라고 하면 거창하게 구조를 바꾸는 것만을 말할 것 같은데, early return처럼 코드의 위치를 바꾸는 간단한 변경만으로도 로직의 흐름이 깔끔해지고 예외를 빠르게 제할 수 있다는 점이 인상깊었다. 특히 평소에 if-else문을 복잡하게 적는 경향이 있었는데, 조건문을 단순화하는 과정에서 내가 얼마나 불필요한 로직을 사용하고 있었는지 돌아보게 되었고, 앞으로는 조건문부터 더 깔끔하게 작성해야겠다고 다짐했다.

JPA를 사용하며 발생한 n+1 문제를 단순히 fetch join으로 해결하는 것에서 나아가서, @EntityGraph를 활용하면 더 선언적이고 간결하게 문제를 해결할 수 있다는 점도 새롭게 배웠다. 프레임워크가 제공하는 기능을 아는 만큼 더 편리하게 활용할 수 있다는 점이 실감됐다.

또한 '로직이 어떠한 의도를 가지고 작성되었는지' 그리고 '리팩토링 이후에 의도대로 코드가 동작하는지' 확인하는 과정에서 테스트 코드의 중요성도 체감했다. 겉으로 드러나지 않는 제약을 테스트를 통해 찾아낼 수 있었고, 전체 코드를 실행하지 않더라도 기능별로 단위 테스트를 한 덕분에 변경된 코드가 기존의 의도대로 작동하는지 확인할 수 있다는 점이 너무 편리했다.

이번 프로젝트는 테스트 코드를 적극적으로 활용해 볼 수 있는 좋은 기회였고, 단순한 기능 구현을 넘어서 어떤 코드가 좋은 코드인지 고민하는 계기가 되었다.