마이그레이션

팀 회의에서 기획 변경으로 인해 DB 설계가 여러 번 수정이 될 때 마다
(물론 기획이 크게 수정되면 안되지만 ㅎㅎ..) 로우 쿼리로 작성되어 코드의 관리의 불편함을 느꼈습니다.

이유

• 타입 세이프 하지 않음
  로우쿼리로 작성된 코드들은 타입 추적이 안됨.

  타입스크립트 사용 가정.
  서비스, 컨트롤러 또는 db 레이어에 강제로 명시되어 있는 타입들을 직접 수정

• 코드 길이와 가독성의 부재

1. 다중 조인 또는 JSON_ARRAYAGG, JSON_OBJECT와 같은 MySQL Function으로 row 데이터를 json으로 포팅하는 경우에 긴 쿼리로 인해 가독성이 떨어짐.

물론 ORM에서 구현하지 못하는 것들은 쿼리를 사용해야 합니다.

2. select를 제외한 update, delete, insert를 사용한 로우 쿼리들의 경우 boolean 또는 number를 반환 값으로 주었기 때문에 조회 (select) 쿼리를 추가 작성해야함.

Prisma로 결정

위와 같은 불편함을 느끼며 어떠한 ORM으로 선택할지 고민을 하는데

이전에 사용하였던 TypeORM의 개떡같은 docs와 느린 이슈처리와 함께
커뮤니티의 많은 분들의 추천으로

Prisma 4 로 결정했습니다.

prisma docs에서 말하는 왜 prisma인가.
https://www.prisma.io/docs/concepts/more/comparisons/prisma-and-typeorm

기존 ORM과의 다른점.

TypeORM, Sequelize와 같은 ORM과 크게 다른 점으로

다른 ORM들의 경우 .ts 파일에 class를 사용하여 직접 맵핑을 하는 반면에
Prisma의 경우 schema라는 독자적인 파일을 통해 타입을 생성해주는 것이

관리해야하는 코드 또는 파일이 줄어들어 편함을 제공해주는 것 같았습니다.

물론 .ts 파일에 작성하는 것과 .schema에 작성하는 것이 무엇이 다르냐 생각 할 수 있지만

.schema 파일은 .sql과 비슷한 모양새를 통해 조금 더 sql DDL 작성에 가까웠고
schema 파일 수정이 생기는 경우 prisma migrate cli를 제공해주어
손쉽게 마이그레이션 sql를 작성해주어 관리에 도움을 주었습니다.

cd를 진행할 때 간편함

느낀점

테스트 코드의 중요성.

이번 마이그레이션 경험을 통해 핵심으로 생각드는 것을 꼽자면
테스트 코드를 말 할 수 있을 것 같습니다.

서비스 레이어에 유닛 테스트를
컨트롤러 레이어에 통합 테스트를 작성 해놓았는데

레포지토리 레이어에서 기존 mysql 로우 쿼리들을 제거하며 ORM 코드로 채워 놓을 때마다
작성된 테스트들을 실행하며 기존의 함수가 제대로 작동되는지 확인만 하면되어
빠른 속도로 마이그레이션이 가능했습니다.

테스트 코드 작성이 단기적으로 개발 속도를 느리게 한다고 하지만
개발이란 코드 작성 짠! 하고 끝나는 것이 아닌 유지보수를 해야 하기 때문에

외주 작업을 하시는 일부 개발자 분들이 아니라면 무조건 하는 것이 장기적으로 회사뿐만 아니라 개발자 자신에게도 도움이 되지 않나 조심스럽게 강조합니다.

테스트 주도 개발에 대한 회의

간단하게 테스트 코드 작성 - 코드 개발 - 리펙토링을 반복적으로 하는 방법론을 TDD라 합니다.

무조건 저 순서를 지켜야만 할까요?
이상적인 방법론에 개발을 꾸겨넣는게 아닐까? 관료주의적인?
핵심인 리팩토링만 지키면 되는 것 아닌가?

추가

2022-09-25

테스트 코드 작성에 대한 고민을 계속 하던 중 커뮤니티의 사람들의 의견을 종합해 보았다.

TDD란 테스트 작성에 대한 패러다임으로 테스트 작성을 먼저 함으로써

• 개발 삼천포 방지
  미리 문서 작성하여 정의된 함수(기능)만 구현하여 중구난방 방지.

• 함수 작성 후 테스트 코드 미작성 방지.

• 함수에 대한 명세서 작성.
  이 함수가 어떠한 기능을 하는지 설명.

의식적인 순서를 지키면서 위 세가지의 장점을 얻을 수 있다고 한다.

결론

다른 사람들의 의견을 보았을 때
함수에 기능을 이것 저것 많이 넣거나 테스트 코드 작성에 익숙하지 않는 사람에게
TDD를 함으로써 개발 루틴에 대해 익숙해지라는 의의가 있다고 생각 들었다.

이미 함수 하나에 하나의 기능 그리고 테스트 코드 작성을 잘 하고 있는 개발자에게는
굳이 따라야 하는 방법론은 아니라고 결론을 내리고 싶다.

추가

2023-03-15

그동안 TDD에 대한 생각을 떨칠 수가 없었다.
결론부터 말하자면 테스트를 먼저 작성하는 것이 싸게 먹힌다고 생각이 변했다.

현대의 프로그래밍은 협업의 연속이라고 말할 수 있다.
개인 혼자서 기획 설계 프로그래밍 모두를 다 한다면 TDD가 별 필요 없을 수도 있겠지만
(다 해도 하는게 좋은 듯?)

실무를 하다 보면 기획 - 설계 단계에서 계속 수정되는 경험을 하게 될 것이다.
물론 변경이 안되면 좋겠지만 현실적으로는 그렇지 않다.

코드 작성 을 하는 도중 계속 되는 수정에 테스트 코드 작성을 나중에 한다는 것은

업무를 혼란에 빠뜨리는 주요 원인이 되지 않을까 싶다.

어지러운 상태에서 빠르게 빠져나가게 하는 것이 테스트 코드 작성 TDD가 아닐까 생각이 든다.