만들면서 배우는 클린아키텍처 독서: 테스트, Product Adapter(out.dataaccess) 개발 및 테스트, 알고리즘 문제풀이

오늘 하루 왜이리 짧은지 모르겠다. 예상하지 못한 부분에서 막히는 것 때문인가? 책상에 앉은지 얼마 안된 것 같은데 3-4시간이 훌쩍훌쩍 지나간다. 독서도 관심있는 주제라서인지 내가 계획한 시간보다 더 보게 된다. 이것까지만 보자..! 하는게 자꾸만 이어진다. 출퇴근 할 때에는 환승이나 이동을 해야해서 강제로 독서가 멈췄는데, 강제가 없으니 생각보다 절제가 힘들다.

---

만들면서 배우는 클린아키텍처

 

계속해서 공부하고 있는 클린아키텍처인데, 공부할 수록 생각이 깊어진다.

 

얼만큼 테스트를 작성해야 충분한 걸까?

 

책에는 고민해보면 좋을 내용과 내가 고민이던 부분에 대한 내용이 정말 많다. 그래서 정말 재밌다. 고민에 대한 해답도, 더 깊은 고민을 주기도 한다.

 

---

지난 회사에서의 추억

 

나는 테스트의 중요성을 스스로 인지하고, 테스트 주도 개발을 하고 싶었다. 테스트는 개발을 할 때도, 그리고 개발된 시스템을 파악하는데도 유용하기 때문이다. 지난 회사에서 담당한 프로젝트에서 거대한 레거시 코드를 보고 크게 당황한 적이 있다. 이것이 레거시인가? 프로덕션은 이정도구나 하는 생각과 함께, 어떻게하면 이 거대한 레거시를 파악할 수 있을까? 하는 생각으로 이어졌었다.

 

---

레거시를 분석하는 방법

 

거대한 레거시를 분석하는 일은 불가피했다. 그런데 누군가는 불가능하다고 하기도 했다.(사수) 하지만 나는 반드시 분석해야했다. 내가 담당하는 서비스를 담당자가 모른다면, 이건 너무 무책임한 것 아닌가.. 그래서 나는 입사 초기, 레거시 코드를 효율적으로 이해하기 위해 많은 고민과 다양한 시도를 해보았다. (지금 생각해보니 생각나는건 2가지 뿐이네..)

 

나는 레거시를 분석이 지금에서 끝나지 않을 것 같았다. 분명 시간이 지나면 또 까먹고, 다시 분석하는 내 모습이 그려졌다. 하지만 이 또한 불가피하다. 나는 천재가 아니다.. 한번보면 다 기억하는 괴물이 아니다.. 그래서 나는 지금 정리를 잘해두어, 미래에 다시 찾아볼 때, 빠르게 파악할 수 있는 방법으로 레거시를 분석하고 정리하고자 했다. 이런 고민으로 나는 코드 문서화를 시도했다.

 

 

---

코드 문서화: 문서 작성

 

기존 레거시의 코드 문서화는 전혀 없었다. 정말 없었다. 문서까지하면 일은 누가하냐 하는 사수님의 가치관 때문에(?) 없었다. 그리고 무엇보다 사수님이 만들었기에, 문서가 필요해? 하는 마인드도 한몫했고, 자기만 알수 있게 정리한 문서가 있었으나, 이는 공유하기 싫다고 안하셨다. 그래서 나는 맨땅에 헤딩을 시작했다.

 

잘 정리되고 설계된 프로젝트의 코드 문서화도 어렵다. 근데 거대하고 괴물같은 레거시에서는 더 어렵다. 나는 해당 파일의 의존성관계를 정리하고, 사용되는 메서드를 정리하고자 했다. 자세하게까지는 아니여도, 해당 메서드를 통해 어떤 결과를 예상할 수 있는지 정리를 하고 싶었다. 잘못된 의존성의 문제도, 중복되는 메서드도 정리하고 싶었다. 하지만 이는 정말 힘들었고 비효율적이었다.

 

정리를 하면서, 모르는 부분 이해가 안되는 부분은 사수님께 물어보고 작성하고 수정했다. 그리고 이를 모든 개발자 및 기획자가 볼 수 있도록 위키로 공유했다. 이해하기 쉽도록 도표와 같은 시각 자료를 공유했다. 그런데 놀랍게도(?) 아무도 보지 않았다. 정리 해보라 하던 사수조자 안봤다. 피드백도 없었다. 보는건 나 혼자였다.(심지어 존재하는지도 몰랐다고한다.)

 

나만 작성하고, 나만 보더라도 상관없다. 다음 개발자, 또다른 누군가는 언젠간 볼테니깐.. 그런데 정말 큰 문제가, 문서로 정리하는 일이 쉽지 않았다. 분석을 하면서 잘못된 부분을 고치고 수정하는데, 자꾸만 템플릿이 변경이 됬다. 가장 최근의 분석 정리한 파일과, 가장 최초의 분석 정리한 파일의 양식이 크게 달라졌던 것이다. 정리했던 것을 또다시 정리해야하는 문제가 생겼다.

 

그래서 나는 다른 방법을 찾아보고 시도했다.

 

 

---

코드 문서화: 테스트 코드 추가

사수님과 팀장님께 단위테스트를 추가하는 것이 어떻겠는가? 이야기를 했었는데, 돌아오는 말은 (단위)테스트를 작성하고 개발하면 개발못해요 라는 말로 돌아왔다. 테스트를 작성할 줄도, 작성할 생각도 안하는 사람들과 내가 할 수 있는 더 이상의 대화와 행동은 없었다.

 

테스트 코드는 좋은 코드 문서이다.  이는 분명한 사실이다. 이 외에도 테스트를 통해 얻을 수 있는 장점은 분명했다. 그리고 무엇보다도 테스트를 통해 기능개발에 있어 시간을 단축시켜준다는 것도 명백한 사실이다. 그래서 나는 혼자서 내 로컬에만 있는 테스트 를 추가했다.

 

단위 테스트는 작성할 수 없었지만, E2E 처럼 테스트 UI를 만들고 테스트 하고싶은 코드를  테스트했다. 기능을 분석하면서 각 서브도메인에 필요한 sql 데이터를 생성하기 위해 init-schema 를 만들어 테스트를 진행했다. 그리고 나만의 문서가 탄생했다.

 

특정 기능에 장애가 발생했을 때, 내게 해당 장애 조치에 대한 업무가 주어지진않았지만, 혼자서, 어느부분에서 장애가 발생했다 파악할 수 있었다. 이슈를 해결할 때, 신규 기능을 개발할 때, 많은 도움이 되었다.  단위 테스트를 통한 기능을 파악하는 수준까지는 할 수 없었지만, 통합테스트(E2E)를 통해 기존 기능의 유효성에 대한 확신과 기능에 대한 이해와 분석이 깊어졌으며, 다시 기능을 확인(복습)할 때, 편리했다.(해당 기능에는 어떤 데이터들이 필요하고, 어떤 로직을 거치는지 파악하기 쉬웠다.)

 

 

 

 

이 후, 다시 코드 문서를 작성하는 일도 혼자서 하고 있었는데, 사수가 이제서야 자기도 보게 같이 올려서 보자고 했었다. 근데 자기는 작성하지않고 분석한 내용에 대한 피드백도 없으면서, 이렇게 정리하지말라만 이야기했었다. 지금생각하면 어이가 없다. 내용이 틀린게 아니라 정리하는방식이 자기맘에 안든다나 뭐라나..

 

무튼 테스트 코드(?)를 작성하면서 나는 지금의 고민을 많이 하지는 않았었다. 얼마만큼의 테스트 코드가 올바르고, 신뢰할 수 있고, 충분한 것인가? 어떤 테스트코드가 잘 작성된 테스트 코드일까? 하는 고민은 적었다. 테스트 코드가 부족하다는 친구의 피드백 덕에, 이 고민을  많이 하게 되었다.

 

책에서는 얼마만큼의 테스트가 충분할까? 에 대한 답으로, 얼마나 마음 편하게 소프트웨어를 배포할 수 있는가? 를 기준으로 삼았다. 그리고 나는 이것을 기준으로 잡아도 되겠다는 생각이 들었다. 지금 개발 중인 프로젝트에에 적용해본다면, 테스트로 개발 중인 기능이 정상작동한다 확신할 수 있는가, 신규 기능을 구현하고서 병합할 때, 마음이 불안하지 않는가? 로 이야기 할 수 있을 것 같다.

 

테스트에 대한 부분은 아직 모르는 내용이 많고, 실제 프로덕션에서는 어떤 식으로 진행하는지도 궁금해서 많은 사람들과 이야기를 해보고 싶다.

 

 

---

Product Adapter(out.dataaccess) 개발 및 테스트

 

오늘은 Product Adapter(out.dataaccess) 개발 및 테스트 를 마치고자했다. 어제까지 문제를 해결(?) 했고, 남은 부분은 해당 영속성 계층의 기능을 테스트만 하면되는 부분이었기에, 크게 어려울 것이라는 생각을 하지 않았다. 그리고 실제로 2개의 메서드는 너무나도 쉽게 개발했다. 그런데 내 발목을 잡은 한개의 메서드가 존재했다.

 

 

내 발목을 잡은 메서드. Optional<List<Product>> 를 어떻게 반환해야할까..

 

내가 아직 Java에 대한 미숙함 때문에 이렇게 막히는 것 같다. 근데 이 미숙함을 어떤 것으로 공부해야할 지 감이 잘 안온다..

 

내가 작성한 테스트코드, 이제 구현만 하면되는데..

테스트 코드 작성에는 어려움이 크게 없는데, 실제 구현에서 막혔다...

내가 직면한 문제 요구하는 값과 실제 반환하는 값이 다르다.

 

어..... 어...... 이거 어떻게 해야하지.....? 어떻게 공부를 해봐야할지 감이 잘 안온다.. ㅠㅠ Optional 과 stream, map 을 일단 내일 공부해서 문제를 해결할 수 있도록 노력해봐야겠다..

 

그리고 코드를 테스트 하기 위해 다시 작성한 코드를 보면서 내가 무엇인가 잘못한것같다는 직감이 왔다.. Querydsl 을 사용하는 부분에서 문제가 존재한다.. 분명 나는 동적쿼리를 사용하고자, Querydsl을 사용하는거였는데.. 이건... 잘못됬다...  이 부분도 내일 고쳐봐야겠다..