우테코 5기

[레벨 3 회고] 하루스터디 4주차 회고

teo_99 2023. 7. 23. 23:01

4주차는 처음으로 기획에서 벗어나 개발과 발표 준비에만 몰두했던 시간이었는데요, 여느 때와 마찬가지로 한 주 동안 배웠던 것들, 느꼈던 점들을 작성해보고자 합니다 🥸

 

페어 프로그래밍

기능 개발을 본격적으로 시작하기에 앞서, 팀원들과 어떻게 개발을 할 지에 대해서 논의하는 시간을 가졌었습니다. 이 과정에서 처음에는 동기화 작업이 우선이니 몹 프로그래밍, 그리고 그 뒤부터는 페어 프로그래밍을 하자! 라고 결론이 났습니다. 그래서 엔티티 설계 등, 동기화 작업이 중요한 경우에는 몹 프로그래밍을 진행했고, 그 뒤 개별적인 기능은 페어 프로그래밍으로 구현했습니다.

 

분업 방식을 고려하지 않았던 것은 아니지만, 프로젝트의 경우에는 결과물만큼 동기화 과정도 중요하다고 판단했기 때문에 페어 & 몹 프로그래밍으로 진행했습니다. 저는 모디랑 페어 프로그래밍을 진행했는데, 모디는 테스트 코드 작성에 있어서의 역량이 두드려졌습니다. 통합 테스트를 작성하는데 @MockMvc에 대한 이해도도 높았던 것 같습니다. 

 

다만 페어를 하면서 학습하게 된 내용들도 정말 많았던 것 같은데 문서화가 안되어서 아쉽습니다.. 아무래도 데드라인이 정해져 있는 개발이다보니 트러블슈팅이나 새로 학습한 내용에 대한 문서화를 제대로 하지는 못했는데 다음부터 개선해야 할 부분이라고 생각합니다.

 

ATDD?

사실 이번에 ATDD를 도입하려고 했습니다. 하지만 실패하는 인수 테스트 코드를 먼저 develop 브랜치에 올려야 한다는 점이 마음에 걸렸습니다. develop 브랜치에서는 CI/CD 파이프라인이 동작하고 있어서 항상 테스트 및 빌드가 실패할 수 밖에 없기 때문입니다.

 

이런 문제에 대한 해결방안으로 '테스트를 주석처리하는 등'의 방법이 있다고는 하는데, 개인적으로 ATDD가 그만큼의 불편을 감수하면서 진행할만한 효용이 있는지에 대해서는 논의를 해봐야 할 것 같긴 합니다. 이번에는 일정 상의 이유와 앞서 언급한 CI/CD 관련 이슈로 인해 ATDD를 진행하지 못했지만요..!

 

 

Repository에 대한 고민

오랜만에 설계에 관한 고민도 조금 했던 것 같습니다. JPA Repository를 구현하면서 '엔티티로 찾냐, ID로 찾냐' 에 대한 논쟁이 있었기 때문인데요. 코드로 나타내면 다음과 같습니다.

Study findByMemberId(Long memberId); // 1안

Study findByMember(Member member); // 2안

 

 

 

팀원들끼리 JPA Repository를 구현하면서 1안과 2안으로 스타일이 나뉘었기 때문에 논의를 필수적으로 할 수 밖에 없었는데요. 저는 다음과 같은 이유로 '1안과 2안을 적절히 사용해야 한다'고 생각했습니다.

 

  • 1안만 고려하는게 부적절한 이유
  1. 객체지향적 코드가 아닌 Service에서 항상 Repository만 직접적으로 호출하는 트랜잭션 스크립트 패턴의 코드가 나올 확률이 높다. 이는 도메인 객체가 단순한 데이터 구조가 되기 때문에 변경에 대응하기 힘들 것이다.
  • 2안만 고려하는게 부적절한 이유
  1. JPA를 사용하는 이점이 과연 있을까 싶다. 연관된 모든 엔티티를 항상 복원하고 나서야 Repository 메소드 호출이 가능해지는데 이는 지연 로딩을 사용하지 못하는 것이고 쿼리 최적화의 어려움이 있을 수 있다.
  2. 또한, 엔티티를 기준으로 항상 Repository 메소드를 호출하게 되면 의존성이 매우 복잡해질 우려가 있다. 여러 도메인이 한 Repository 메소드에서 다뤄진다는 것은 Service에서도 여러 도메인을 다룬다는 것을 의미하는데, 이는 유지보수하기 어려운 코드를 만들어 낼 위험이 존재한다.

 

하지만 관련한 문제를 아직까지 마주한 적이 없기 때문에 '우리 이렇게 하자!' 라고 쉽게 주장할 수는 없었습니다. 저도 '이러이러할 것이다' 라고 추측만 할뿐이지, 관련한 경험은 부족하기 때문입니다. 따라서 팀원들과 논의 끝에 일단 ID 대신 엔티티를 사용하는 방향(2안)으로 일관화하고 나중에 문제가 발생하면 논의해보자고 결론이 났습니다. 확실히 문제가 발생하기 전까지는 문제로 삼지 않는 마음가짐이 중요한 것 같다는 생각이 드네요.

 

 

발표 및 3차 스프린트 준비

이번에는 저와 룩소가 발표를 맡았습니다. 목요일 오후부터 발표 준비를 시작했는데, 나름 PPT도 깔끔하고 발표도 잘한 것 같아 기분이 좋았습니다. 하루스터디가 기획을 틀고 난 뒤 처음으로 코치, 크루분들에게 공개하는 자리였는데 기분좋은 피드백이 조금 있었어서 기뻤습니다. 

 

목차

발표가 끝난 뒤, 코치님들의 피드백을 반영해서 3차 스프린트 목표를 작성했는데 확실히 프로젝트의 방향성이 점차 견고해지는 것 같아 기분이 좋습니다. 3차 스프린트부터는 소켓을 도입하는데 새로운 경험도 많이 하게 될 것 같아 기대가 됩니다.

 

되돌아보기

문서화를 잘 하자

본격적으로 개발을 시작했는데, 문서화가 안되고 있다는 느낌을 받습니다. 정작 이번주에 개발하면서 배웠던 내용들도 뭐였는지 기억이 잘 안나는 터라, 자잘하게라도 작성해두는 연습을 해야겠습니다.