📚 클린코드 7장 오류 처리 및 8장 경계 을 읽고 생긴 궁금증을 정리해 보았습니다
< 느낀 점 >
오늘의 내용은 알고 있는 당연한 것들을 자세하게 쓴 느낌이라 개념을 정리하는 듯한 기분이었다 스프링 학습을 시작하면서부터 예외 처리는 자연스럽게 해 주고 있었기 때문에 왜 해야 되는 것인가를 좀 더 깊게 학습한 느낌에 가까웠다 이유를 알고 있는 것과 설명하는 것에는 생각보다 큰 간극이 존재하는데 왜? 를 설명하는 것에 조금 가까워진 느낌이었다!
경계 파트의 경우에는 나를 지난 학기 아주 힘들게 만들었던 소프트웨어 테스팅 이론 과목이 떠올랐다... 아주 고달프고 어렵고 힘겹고 무언가 내가 잡지 못하고 있다는 생각이 계속 들었는데 클린코드를 읽을 때 해당 과목에서 배운 것들을 가장 잘 활용하고 있다는 생각이 든다 다시 돌아가도 그 과목을 더 열심히 공부해서 더 나은 성적을 받을 자신은 없지만... 다시 들어도 좋을 과목이라 생각한다! 다들 들으세요 비록 매주 고통에 시달릴지라도 진정한 학문을 공부한 느낌이었고 대학 과목 느낌이었어서 좋았다 현업에 대한 이야기도 많이 듣고! 어쩌다 보니 과목 영업으로 끝난 느낀 점 회고 끝
1. 현업에서의 테스트 문화
(1) [카카오페이 테크 블로그]
카카오 페이에서 테스트 코드 주제로 다양한 글을 작성한 것을 볼 수 있었다 그중 사례로 보는 모바일 자동화 테스트를 보면 다음과 같은 프로세스를 거친다고 한다
QA Engineer가 자동화 테스트 코드 작성과 로컬 테스트를 완료하고,
Pull Request를 통한 코드 리뷰 진행 후 코드를 머지합니다.
이후 Trigger 또는 스케줄링에 따라 Jenkins에서 자동화 테스트가 실행되고
Device Farm으로 원격에서 모니터링할 수 있게 됩니다.
실제 단말들은 Device Farm Provider에 연결되어 있으며,
Appium을 통해 자동화 테스트를 수행합니다.
또한 테스트에 사용되는 앱은 테스트가 진행됨에 따라 artifact를 통해 MoBiL로 부터
최신 빌드된 앱을 자동으로 받아와서 설치됩니다.
실행에 따른 상세 로그들이 수집되어
OpenSearch와 Grafana Dashboard, Report를 통해 진행 상태 또는 결과 확인이 가능합니다.코로나로 인해 재택 근무로 전환된 후에는 다양한 그라운드 룰을 도입하며 테스트 관련해서도 룰이 있었다고 하는데
Line coverage 92.04%를 유지하는 프로젝트가 있는 반면,
테스트 코드가 거의 없는 프로젝트도 있습니다.
풍부한 테스트 코드는 평소에 힘을 느끼기 어렵지만,
버그가 생기거나 대규모 리팩터링 시 큰 도움이 된다고 생각합니다.
하지만 모든 코드 리뷰에 테스트 코드가 있지 않았고,
뒤늦게 테스트 코드만 작성하는 날을 잡아서 밀려있던 테스트 코드를 작성하기도 했습니다.
코드 리뷰는 코드의 품질을 유지하기 위한 최소한의 수단입니다.
그래서 어느 정도 기계적으로 코드 품질을 유지할 필요가 있다고 생각했습니다.
코드 커버리지는 테스트 코드가 얼마나 많은 코드를 실행하는지를 나타내는 지표 중 하나로
코드 커버리지가 높을수록 많은 코드가 테스트로 검증되었음을 의미하는데요.
부끄럽게도 모든 프로젝트가 높은 코드 커버리지를 유지하지는 못했습니다.
코드 커버리지는 신뢰성과 관계가 있고,
안전하게 코드를 수정하기 위해선 어느 정도의 코드 커버리지가 뒷받침되어야 합니다.
팀에서 목표한 코드 커버리지가 있지만,
코드 리뷰를 등한시했던 것처럼 쉽게 타협의 대상이 되곤 했습니다.
코드 커버리지가 높다는 것은 풍부한 테스트 코드가 있다는 것을 의미하는데,
테스트 코드는 신뢰성 있는 코드를 유지해주는 장점도 있지만
코드 리뷰에 도움을 주기도 합니다.
작성한 코드가 복잡하다면?
코드의 흐름을 어떻게 따라가야 할지 보기 어렵다면?
이럴 때 코드 리뷰 시간이 오래 걸리곤 하는데,
테스트 코드가 있다면 작성자의 의도를 쉽게 파악할 수 있고,
리뷰에 더 집중할 수 있습니다.
PR Template에 코드 커버리지 항목을 추가해서 일정 수준 코드 커버리지를 권장하면,
리뷰어들이 테스트 코드로 동작을 예상하고
잠재적인 버그를 찾아내는데 도움이 될 것이라고 기대했습니다.위 사례들을 통해 특별히 테스팅을 담당하는 포지션이나 부서가 있지 않고 개발자들이 각자 자신의 코드에 대한 테스팅 코드를 짜는 형식임을 알 수 있었다!
(2) 우아한 형제들 기술 블로그
위 SPOCK 프레임워크를 도입한 사례를 통해 생각보다는 정해진 툴을 사용하고 도입이 제한적이기보다는 새로운 테스팅 기술을 빠르게 도입하고 사용하는 것이 자유롭구나! 하는 생각이 들었다 1번의 사례와 함께 보자면 팀 단위로 자유롭게 결정하고 진행하는 것이 가능해서 회사 단위의 정책보다는 팀이 정해서 이끌어가는 문화가 개발 문화의 대다수라는 생각이 들었고 그래서 팀에 더욱 잘 맞는 룰을 만들 수 있는 것 같다는 생각이 들었다
SPOCK이라는 기술이 나온 지는 십 년 된 것 같은데 아직도 많은 사람들이 배우는 단계이고 (테스팅이라는 것 자체가 도입되고 자리를 잡은 지 얼마 되지 않았다는 이야기를 들었다) 그래서 자료가 많지 않았는데 네이버 D2의 글을 참고하시며 작성한 것을 보니 몇몇 기업에서는 빠르게 도입했나 보다!
https://spockframework.org/spock/docs/1.3/spock_primer.html#_blocks
위 공식 문서의 친절한 설명을 통해 도전 가능...
2. 어디까지 DTO를 생성해야 하는가? Null 처리를 하면 안 되는 것인가?
이건 내가 프로젝트를 진행할 시절... 문득 모든 send와 receive에 걸맞는 모델을 만드는 게 과연 옳은 것인가? 너무나도 많은 model을 생성해야 하는데 같은 모델을 사용하는 거면 사용하지 않는 필드가 있더라도 해당 부분은 null 처리 혹은 기본값을 지정해 넘기면 되지 않을까? 하는 궁금증에서 파생되었다
예를 들어 User의 데이터를 1번부터 10번까지의 API에서 사용하는데 1번 API는 모든 필드 사용, 2번 API는 번호 빼고 다 사용, 3번 API는 이름 및 성별 빼고 다 사용... 이런 식이라면 10번까지 API에 대응하는 DTO를 모두 생성하는 것보다 적당히 하나는 null 또는 기본 데이터를 사용할 수 있지 않을까? 하는 생각이었다
실제로 서비스를 구현해 보니까 유저 같은 데이터의 경우에는 많은 API에서 사용하기 때문에 각각의 DAO를 만들다 보니 개수가 너무 많아졌고 거기서 이게 맞는 건가... 싶은 생각이 들었다
나와 비슷한 고민을 하는 분들이 많아서 여러 글들을 보았는데 평소 강의를 듣던 김영한 님은 이렇게 답변해 주셔서 참고하고 프로젝트를 진행했었다.
사실 따로 글을 작성하려고 했는데... 클린코드 덕분에 잊고 있었던 주제를 작성해 본다 ㅎㅎ 한 주제는 정말 고민을 많이 했어서 따로 작성할까 싶다
공통화 할 수 있으면 공통화해서 사용하고 그렇지 않으면 완전히 분리해서 사용합니다.
실무에서 API는 상황에 따라 다르지만 클
라이언트의 요구사항을 어느정도 반영해야 하는 경우가 있기 때문에
각 요구사항에 맞춘 DTO들이 나오게 됩니다.
결론은 상황에 맞게 둘다 사용해야 합니다!
예를들어서 너무 차이가 나는 서비스 API 들은 명확하게 DTO를 분리해야 합니다.
반면에 유사한 API에 비슷한 역할을 하는 DTO라면 통합해서 하나로 관리해야 합니다.
여기서 DTO를 통합할지 분리할지 단순히 데이터가 유사한 것도 판단의 근거가 되겠지만, \사실 더 중요한 판단 근거는 향후 변경의 라이프사이클 입니다.
예를 들어서 A 기능을 하는 API와 B 기능을 하는 API가 있는데,
하나는 고객사이드 API이고,
하나는 어드민API 라면 처음 개발당시의 모습이 완전 100% 똑같아도,
이 API는 변경의 라이프라이클이 다릅니다.
바로 이 변경의 라이프사이클이 중요한 포인트가 됩니다.
변경의 라이프사이클이 같고,
데이터도 유사하다면 같은 DTO를 사용하면 됩니다.
반면에 변경의 라이프사이클이 다르다면,
데이터가 유사해도 다른 DTO를 사용하는 것이 좋습니다.3. 오픈소스의 삭제로 프로그램이 다양한 기업들의 프로그램에서 대거 오류난 사례
이건... 공부를 하다가 관련 글을 본 적이 있어서 자세하게 알아보려고 서치했는데 무슨 기업이었는지 어느 언어였는데 죄다 기억이 나지 않아서... 알면 알려 주십셔 결국 합의를 통해 오픈소스를 다시 등록했다고 했는데 어떤 키워드를 써도 나오지 않습니다 흑흑
