[Smallib : 앱센터를 위한 작은 도서관 프로젝트] 이론

▼ Smalib 포스팅 목록
👩‍💻 작성자 📆 작성 일자
이주원 2023.11.23

2주차에 할 일은?

- 각자 달랐던 코딩 컨벤션들에 대해 이야기하고 정리하기
- 역할 나눠서 개발하기 위한 규칙 정하기
- 테스트 코드 작성해보기

로 생각하고 앱센터에 도착했지만, 결론은 이론으로 주구장창 이야기만 했다.

테스트 코드 작성하기

먼저, 테스트 코드 작성에 대한 이야기를 진행했다.
이전의 스터디나 프로젝트에서는 테스트 코드 작성 없이 개발을 진행했기 때문에, 테스트 주도 개발(TDD)에 대한 생각이 모두에게 있었다.
그렇게 테스트 코드에 대한 이야기를 하다가 이야기가 딴 길로 새버렸다...
(이에 대한 내용은 각자 포스팅이 올라올 것 같다)

아무튼, 테스트 코드에 대한 이야기는 테스트 코드 작성하자!로 마무리 되었다.
테스트 주도 개발은 제대로 이야기가 나오진 않았다

각자 달랐던 코딩 컨벤션에 대해 이야기하고 정리하기

지난 주 라이브 코딩을 해보면서 느낀 점은 상당히 방식이 달랐다는 것이다.
분명 프레임워크인데, 라이브러리에서 개발하는 듯한 여러 바리에이션을 본 것 같다.

DTO에 관하여

먼저, DTO 네이밍 방식이다.
나의 네이밍 방식은 언제나 다음과 같다. 

(Entity 명)(행위)(요청/응답)Dto.java
이때, 줄임말을 사용하지 않는다 (Request (O), Req (X))

ex) BookSaveRequestDto : 책 엔티티에 대한 - 저장 행위 - 요청을 위한 - 데이터 전송 객체

그런데 생각보다 여러 컨벤션이 있었다

  • (행위)(Entity 명)(요청/응답)Dto.java (줄임말도 허용)
  • (Entity 명)Dto.java

두 번째는, DTO를 파라미터로 넣을 때 어떤 이름으로 넣는 가? 였다.

  1. 그대로 넣는다 (BookSaveRequestDto bookSaveRequestDto)
  2. DTO는 뺀다 (BookSaveRequestDto bookSaveRequest)
  3. 요청/응답만 표현한다 (BookSaveRequestDto request)
  4. 요청/응답 + DTO로 표현한다 (BookSaveRequestDto requestDto)
  5. DTO만 넣는다 (BookSaveRequestDto dto)

나는 1, 4번을 혼용하듯이 사용한다.
둘 중 한가지를 일관성있게 사용하는 것이 좋다고 생각한다.

개인적으로 다른 경우에 대한 반론을 하자면 다음과 같다.

  1. DTO를 빼는 경우도 나쁘지는 않지만 요청/응답 등에 대한 데이터 전송 객체를 언급하는 것이 중요하다고 생각된다.
  2. 요청/응답만 표현하는 것도 2번의 의미와 같다.
  3. DTO만 넣는다면 요청/응답 DTO 구분이 어려워진다. (만약, 요청/응답 DTO가 구분되지 않았다면 나쁘지 않은 선택일 수 있어보인다)

역할 나눠서 개발하기 위한 규칙 정하기

역할을 나누기 전에 내가 한 마디를 했었다.
dev 브랜치는 대체 무슨 역할인거야?
지난 주 라이브 코딩 이후 dev 브랜치를 만들어 push 했는데 나는 언제나 이 방식이 이상했다.

다른 프로젝트에서 형들이 이런 브랜치를 사용하는 전략을 채택했는데, 이러한 부분들이 이상했다.

- 어떤 브랜치 전략을 구사한 것일까? (Git Flow, GitHub Flow, Trunk-based Development...)
- main보다 dev가 ahead가 너무 많아서 최신화된 코드 확인이 어렵다
- checkout의 기점이 되는 branch가 이로 인해 명확하지 않아진다

그래서 이번에는 내가 강력하게 제안했다.

Trunk-based Development 브랜치 전략을 채용하고, main 브랜치와 short-term 브랜치만 활용하자!
Trunk-based Development는 Trunk(main 등) 브랜치에 바로 push함으로써 PR/merge의 복잡성을 줄인 전략인데, 진짜 브랜치 없이 개발하게 되면 테스트 등에서 문제가 발생할 수 있기 때문에, short-term 브랜치를 만들어 PR을 날리고 테스트 후 merge하는 방식도 사용하는 경우가 있다.

그래서 이를 위한 CI/CD 파이프라인에 대해서도 간단히 설명했다.

1. Feature -> main (Pull Request)
Feature 브랜치에서 기능을 작성 후 PR을 날렸을 때, CI 작업만 수행한다. (병합 - 테스트 - 빌드)

이때 테스트는 통합 테스트가 적합해보인다.
(PR을 보내고 리뷰를 받는 동안 긴 시간이 소요되므로, 통합 테스트를 수행해도 비효율적이지 않다고 생각했다.)

2. main (Push)
직접적으로 main 브랜치에 Push하는 경우는 전혀 없어야하고,
PR이 merge되어 main 브랜치에 Push 되는 경우를 의미한다.

이 경우 CI/CD 작업을 수행한다. (병합 - 테스트 - 빌드) - (배포)
이때 테스트는 배포를 위한 과정이기 때문에 빠르게 진행하기 위해 단위 테스트가 더 적합해보인다.

이에 대한 자세한 내용은 Trunk-based 브랜치 전략을 위한 CI/CD 파이프라인 설계라는 주제로 글을 써볼까 한다.

그래서 개발은?

이번 주 포스팅이 이론인 이유는 이론 이야기만 주구장창하다가, 각자의 컨벤션을 위해 짧은 라이브 코딩을 한게 다였기 때문이다...
다음 주에는 조금 미리 개발하거나 하는 등의 방식을 통해 개발의 진전도 있도록 이야기해야겠다고 생각했다.


이야기한 내용들...

포스팅 할 주제들(이야기한 내용들)을 보니 참 딴 길로 많이 샜다고 느꼈다...

results matching ""

    No results matching ""