2월 2주차 회고
까망베르 치즈와 사과, 이렇게 잘 어울릴줄이야...
이번주도 프로젝트 진행이 이전만큼 나오지는 않았다.
사실 코딩을 안한건 아니지만, 대부분 코딩 테스트 관련이었다.
또 테스트 커버리지 관련 이슈가 생각보다 오래 걸리는 중이다.
낮아진 커버리지 문제는 해결법이 3가지가 있었다.
커버리지 수치 조절하기, 아무 상관없는 코드의 테스트 짜기, 필요한 테스트를 추가하고 불필요한 코드 exclude하여 커버리지 수치를 올리기
나는 3가지 방법 중 정석적인 해결법을 골랐다.
사실 제일 쉬워보여서 고른건데, 만만치 않았다.😅
다시 되돌아보면, 특별히 잘못한 부분보다는 애초에 생각했던 공수보다 더 공수가 필요한 일이었던 것 같다.
해결하려는 이슈 자체에 대한 공수 계산은 꽤 정교했고, 작업 방향도 좋았다.
문제는 이전 마일스톤부터 테스트 커버리지 관리가 시작되었다는 점이었다.
정리해보면 이슈 자체보다는 프로젝트 구성이 변하면서 생각못한 병목이 발생했다.
🤔프로젝트 구성이 변경되고, 작은 이슈를 먼저 처리해보면서 "돌다리도 두드리고 건너기"를 했다고 생각했는데...
충분하게 두드려보지 못한것 같다.😅
문제 생긴 이슈의 오픈일을 보니 금요일이다.
멘토링이 화요일이니 수요일부터 시작한다고 가정해보면 3일 후에나 두드려본거니 확실히 느린것 같다.
이제 멘토링은 거의 끝나긴 했지만, 나중에 프로젝트 구성이 바뀌면 다음날 PR을 던져보거나 다른 팀은 잘 되는지 확인해야겠다.😎
webClient와 Feign 중 Feign으로 결정했다.
강력한 사용성이 마음에 들었는데, 처음에는 재요청 구현이 어려워 보여서 망설여졌다.
재요청도 쉽게 구현하다는 사실을 알게되어 편하게 선택했다.
재요청 알고리즘에 jitter를 추가했다.
프레임워크에서 워낙 잘 지원해주고 있어서 편리하게 추가할 수 있었다.
우리 프로젝트는 대략 2주 전부터 테스트 커버리지를 추적하고 관리하기 시작했다.
커버리지 측정 기준이 라인, 메소드, 분기 등으로 세분화 된다는 내용은 미리 인지하고 있었다.
coveralls, codecov 2가지 툴을 사용중인데, 커버리지가 서로 다른 문제가 생겼다.
"측정 기준이 달라서 그렇겠지, 나중에 바꾸면 될거야"라고 생각했었다...
당장 이번주부터 커버리지가 낮아져서 ci에서 merge를 막는 문제가 발생했다.
restTempalte에서 feign으로 마이그레이션을 했는데, restTeamplate 관련 테스트가 있어서 지웠다.
그런데 이게 codecov에서는 커버리지 수치를 낮추는 문제가 있었다.
- 기존 resttemplate 테스트를 feign 테스트로 변경했는데, resttemplate 관련 테스트도 지우고 resttemplate 관련 클래스는 남겨둬서 커버리지가 낮아짐
- 커버리지 높이려고 남겨둔 restteamplate 관련 클래스를 삭제
- codecov에서는 이를 반영 안해줌...