티스토리 뷰
바라왔고 기대했던 우아한테크코스가 2월 7일부터 시작되었다. 1주 차는 온보딩과 단위 테스트를 학습하는 기간으로 10개월 간 진행되는 우아한테크코스에 대한 과정과 온라인 코드 리뷰 방식에 대해 공유하고, 자동차 경주 미션이 진행되었다.
각 미션은 구현과 리팩토링 2단계를 거쳐 진행된다. 기본적으로 1단계 구현 단계에서는 랜덤으로 정해진 페어와 함께 페어 프로그래밍을 진행하게 된다.
자동차 경주 미션
자동차 경주 미션은 위와 같은 입출력을 수행하는 애플리케이션을 구현하는 미션이다. 자세한 요구사항은 여기에서 확인할 수 있다.
이번 생에 페어 프로그래밍은 처음이라
페어 프로그래밍이란 하나의 컴퓨터에서 두 사람의 프로그래머가 작업하는 방식을 말한다. 페어 프로그래밍을 처음 알게 되었을 때는 각자가 각자의 컴퓨터로 기능을 나누어 개발을 진행하면 더 높은 생산성을 얻을 수 있을 것 같은데 왜 이런 방법을 사용하지라는 의문이 먼저 들었다. 또한 내가 생각한 방향과 페어가 생각한 방향이 달랐을 때의 충돌에서 체력 소모가 클 것이라고 생각하였다.
하지만 직접 경험하지 않으면 모른다는 말처럼 페어 프로그래밍은 내 생각과 전혀 달랐다.
같은 온보딩 조의 허브와 페어가 매칭되었는데, 시작부터 새로운 방향으로 나를 이끌어줬다. 컨벤션과 환경을 먼저 설정하였는데, 평소 단축키를 설정하고 외우는 것이 귀찮아서 미루고 있던 나와 달리 허브는 다양한 단축키를 알고 있었고 개발 생산성이 어마무시한 것을 몸소 느끼게 되었다.
mermaid에 대해서도 알려주었다. mermaid는 다이어그램 작성 및 차트 작성 도구로 의존성 방향에 대한 객체 그래프를 손쉽게 만들 수 있다. 코드 기반이라 빠른 시간에 생각한 것을 시각화할 수 있고 github에서도 지원하기 때문에 리뷰어에게 코드를 이해할 수 있는 부가적인 정보를 제공할 수 있다.
위와 같은 다이어그램을 요구사항 명세서에 작성하여 제출하였고 아래와 같은 리뷰를 받아 나름 기분이 좋았다.
그리고 페어와 잡담은 경쟁력이라는 말을 입에 달고 살만큼 잡담을 정말 많이 했다. 단순한 잡담이 아닌 미션을 진행하면서 발생하는 고민, 앞으로 리팩토링 방향 등 페어 프로그래밍에 있어 필요한 잡담이었기에 재밌고 열정적으로 소통할 수 있었다. 처음 페어 프로그래밍이라는 말이 무색하게 소통하는 것에 있어 너무 편했고 어려움도 없었기에 좋은 결과물도 만들어낼 수 있었다.
페어를 진행하면서 너무 잘하는 사람인 것은 알고 있었지만 🌿허브는 상상이상으로 개발에 뛰어난 사람이었다. 프리코스 때 생산성을 향상하기 위한 팁을 정리해 놓은 글이 올라왔었는데 허브가 작성한 글이었다. 우테코 크루 중에서는 허브의 팬인 사람도 많았다. 미션이 끝나고 나도 자연스럽게 허브의 팬이 되었고, 다음에 기회가 된다면 더 어려운 미션도 허브와 같이 한번 더 해보고 싶다는 생각이 들었다.
걱정과 달리 페어 프로그래밍은 너무 재밌었고, 혼자서는 생각지도 못했던 방향으로의 생각의 확장도 할 수 있었다. 이제는 페어 프로그래밍의 장점을 잘 알게 되었고 만약 해보지 않았다면 적극적으로 추천하고 싶다.
고민했던 부분
제어할 수 없는 부분에 대한 테스트
자동차 이동을 위해서 랜덤으로 값을 생성하여 전진 또는 멈춤을 결정해야 한다. 제어할 수 없는 Random 객체에 의존하고 있기에 테스트를 검증하기 어려웠고, 0~9 사이의 값을 생성하는 만큼 10번의 테스트를 통해 생성된 값이 범위 안에 속하는지 확인하여 적절한 기댓값을 가지는 테스트를 작성하였다. 이런 경우 테스트를 진행해야 하는지, 진행해야 한다면 어떻게 작성하면 좋을까 고민했다.
🥔 웨지의 답변
값이 랜덤 하게 흔들리거나 시간 의존적인 로직들은 상태가 매번 변하기 때문에 테스트하기 어렵습니다. 그런 로직들에 대한 테스트를 용이하게 만들려면 값을 주입(DI)해줌으로 해결할 수 있습니다.
구현을 분리하신 결과, 내부에 Random을 이용해 값을 생성하는 로직만을 가진 객체가 되었습니다. 이 객체에 대한 테스트는 Random, Java SDK에 대한 테스트가 될 수 있는데요. 단위 테스트가 잘 구현되면 좋지만 Java SDK기능까지 테스트 영역에 포함되지는 않습니다. 해당 기능들은 역사가 보증하는 기능들이기 때문입니다. 그러므로 질문에 대한 제 의견은 여기까지 테스트할 필요는 없다입니다.
만약 특정한 API를 사용해보지 않아 학습 목적으로 테스트를 작성하셨다면, 본인이 API의 사용을 익히고 동료 개발자들에게 동작을 확인시켜 주는 가치가 있습니다.
위임 메서드에 대한 테스트
도메인 로직을 분리하고 일급 컬렉션을 사용하다 보니 가지고 있는 도메인에게 단순히 역할을 위임하는 메서드를 작성하게 되었다. 이런 경우 동일한 로직임에도 두 메서드 모두 테스트를 작성해야 하는지 고민했다.
🥔 웨지의 답변
네 필요합니다. 그 이유는 내부적으로 역할을 위임하고 있다는 것은 캡슐화되어 있기 때문입니다. 테스트는 해당 클래스가 표현하는 행위를 검증해야 하지, 내부 구현을 검증하려 하면 구현이 조금만 바뀌어도 테스트를 수정해야 하는 코드가 됩니다.
테스트를 위한 Getter
객체는 캡슐화되어 있기에 메서드 수행에 따른 내부 필드 변화를 확인하기 위해서는 Getter를 열어야만 하는 상황이 발생했다. 테스트 검증을 위해 Getter를 여는 것이 맞을지 고민했다.
🥔 웨지의 답변
Getter 또한 메서드입니다. 메서드 검증을 위해 다른 메서드를 사용하게 되면 의존성이 발생하게 되는데 대부분의 경우 어느 정도 감안하고 테스트를 작성합니다. 테스트를 위한 public 메서드를 여는 것보다는 나은 방법이라 생각합니다.
테스트를 위한 public 코드의 문제점은 아래와 같습니다.
- 실제로 우리가 신경쓰는 행동을 테스트하는 것이 아니다.
- 테스트가 세부 구현에 독립적이지 못하게 된다.
- public API를 하나 추가하므로 다른 개발자가 해당 메서드에 의존하게 되어 수정과 리팩토링이 어려워진다.
두 메서드가 항상 함께 호출된다면, 사실 한 가지 역할이 아닌가에 대해 고민해 보셔도 좋을 것 같아요.
새로 알게 된 부분
요구사항 명세서
요구사항 명세서는 왜 쓸까? 글을 작성할 때는 주제와 목적, 화자를 첫 번째로 고려해야 한다. 개발을 위한 요구사항 명세서가 아닌 맥락을 모르는 누구나 명세서를 보고 시스템을 파악할 수 있게 작성해야 한다. 객체 중심적인 명세서를 작성하는 것이 아닌 기능 중심으로 읽기 쉬운 글을 작성하도록 하고 연관 있는 개념끼리는 묶어서 정리하도록 한다. 그렇게 해야 읽기 좋은 명세서를 작성할 수 있다.
뷰 도메인 의존 관계
도메인이 뷰를 의존하지 말라는 요구사항이 존재하는 이유는 뭘까? 소프트웨어 개발계에서는 경험적으로 뷰 단이 도메인에 비해 훨씬 변화무쌍하고, 비즈니스의 중심이 되는 도메인 개념은 잘 변하지 않는데 비해 기술 발전으로 인해 뷰 변화는 훨씬 빠르다. 새로운 뷰가 나올 때마다 새로운 비즈니스 코드를 작성해야 했던 개발자들의 분노에서 나온 것이 뷰와 모델의 분리 개념이다. 그렇다고 도메인이 변하지 않는가? 그것도 아니다. 도메인의 변화보다 뷰의 변화가 더 많기 때문에 뷰 패키지가 도메인 패키지를 의존하도록 하는 것이다.
도메인 객체 변경 여파도 줄이기 위해 중간 계층의 dto를 활용할 수 있다. 그렇다면 dto 변환은 컨트롤러, 서비스 중 어디에서 발생해야 하는가? 위와 마찬가지로 의존 흐름을 한 방향으로 가져가는 것이 유지보수가 용이하기에 뷰의 요구사항도 들어줘야 하는 컨트롤러에 비해 견고한 서비스에서 주로 변환한다.
마치며
처음이라 많이 긴장되고 떨렸던 미션이지만 그 과정에서 많은 것을 배우고 성장할 수 있었다. 페어와 얘기를 주고받으며 소통의 즐거움을 다시 한번 생각해 볼 수 있었다.
허브가 남긴 회고를 보며 나 스스로도 많이 돌이켜볼 수 있었다. 허브는 자신이 알고 있는 지식에 대한 확실한 근거를 통해 상대방을 설득할 수 있는 힘을 가지고 있다. 개발자로의 목표 중 하나가 사용하고 있는 기술에 대해 확실한 근거를 가지는 것인데 허브를 통해 방향성을 찾을 수 있었다.
열정적인 사람과 함께해서 그런지 더 불타올랐던 것 같다. 칭찬은 너무 잘하셨기에 진심으로 나온 행동인데 상대방을 기분 좋게 해 줄 수 있었다니 한편으로 뿌듯하다.
진행하고 있는 프로젝트에 리뷰어 역할로 참여하고 있는데 리뷰를 처음 해보는 분들이 리뷰를 어려워하길래 다음과 같은 말을 해준 적이 있었다. 나도 코드 리뷰를 받을 때 삭막한 리뷰만 있는 것보다는 칭찬이 함께 있을 때 기분이 좋았기에 경험 섞인 말을 해주었다.
얼마 전 올라온 데브 경수 인스타에서도 칭찬을 섞은 소통의 중요성에 대해 설명하고 있었다. 앞으로도 많은 사람들과 함께 소통하며 살아갈 텐데 더 좋은 관계를 만들어 가기 위해 어떤 노력을 할 수 있을지 계속 고민해 봐야겠다. 소프트웨어 스킬도 중요하지만 개발도 열정적으로 학습해 나가고자 한다.