[CodeSquad] 페어 프로그래밍 회고

🕊 2주차 미션

  클래스 과정 2 주차에 페어 프로그래밍으로 미션이 주어졌다. (1주차는 pr 승인된 후에! 리뷰를.. 😅) 팀으로 @Miller 와 함께 했다. 밀러가 만나기 전에 '코드 윗 미' 라는 툴을 살펴봤는데 괜찮을 거 같다고 사용해보자고 하셔서 신문물을 경험하게 되었다. 같은 프로젝트에 상대방과 내가 동시에 코드를 작성할 수 있는 신기한 툴이었다. (물론 자주 튕겼다 🙄) 툴이 불안정하기도 하고 Gradle 로 프로젝트를 생성하면 프로젝트가 무거워져서 더 버벅거릴까봐 바닐라 프로젝트로 진행을 했다 었다. 'maven repository 로 라이브러리를 다운 받으면 되겠지 하는 안일한 생각' 으로 하루를 보내다 다음 날 host 를 바꿀 때 플로그인 의존성 관리의 소중함을 깨닫고 Gradle 로 당장 바꿨지만 말이다.

♻ TDD practice

• 간단한 계산기를 TDD(Test-Driven-Development) 방법론을 적용해가며 구현해봤다. 컴파일 에러가 발생한 상태로 테스트 코드를 작성하고 해당 에러를 하나하나 없애가며 설계를 하는 과정이 뭔가 어색했다. 설계는 언제든 변경될 수 있고 이에 따라 테스트 코드 또한 변경될텐데 초장부터 컴파일 에러를 🙄?! 하는 생각이었지만 간단한 프로젝트여서 그런지 무리 없이 진행되었고 밀러 덕에 생각했던 것보다 훨씬 더 많은 것을 작성해 볼 수 있었다. 너무 감사하다.

🕒 1단계 (02.22)

• 간단한 미션이었고 호눅스가 미리 페어 프로그래밍을 경험해보라고 던져주신듯 했다. 설계 관련해서 이야기를 나누고 네비게이터, 드라이버 역할을 번갈아가며 구현을 했다. 네이게이터를 하면서 드라이버의 생각을 묻기도 하고, 드라이버 역할을 하면서 본인의 생각을 말하기도 했다. 드라이버가 전적으로 코드를 작성하되 너무 아바타 식으로만 작업을 하는 것보단 어느 정도 본인의 생각을 어필하는 것이 서로의 이해를 위해서도 좋았고, 의견을 취합해 가면서 작업을 한다는 느낌이 들어 자연스럽게 그러한 방향으로 진행하게 되었다. 이름을 지을 때도 막힘 없이 술술 넘어갔다. 보기 좋은 이름보단 그냥 네비게이트 역할을 할 때 '서로 (둘만) 이해하고 있으면 됐다' 생각한 거 같다. 리펙토링할 때 잡았어야했는데 역시나 네이밍으로 리뷰 때 지적을 받았다.

🕕 2단계 (02.23)

• 서로 생각이 섞여 있다보니 네비게이터 역할을 할 때 지금까지 작성해온 상대방의 의도도 고려하여 네비게이트하는 것이 어려웠다. 원래 상속을 잘 사용하지 않았고 웬만하면 사용하지 않으려고 하는 편인데 밀러가 네비게이터 역할을 할 때 상속을 제안해서 상속을 사용하는 방향으로 진행했다 (밀러는 내가 상속을 싫어했다는 것을 모른다 🙄). 평소 코딩 스타일과 완전 다른 설계 방향으로 나아가다보니 생각할 것도 많았고 재미있는 경험이었다. 다음 날 3단계에 상속을 사용해보라는 요구사항을 보자마자 밀러에게 (속으로) 감사했다. 또 Optional 이라는 개념을 사용하는 밀러를 보고 감명받았다. 내내 느낀 거지만 밀러는 책을 정말 열심히 보신다. 밀러의 책장 넘기는 소리가 그리워질 거 같다.

🕘 3단계 (02.24)

• 클래스 수업 시간에 랜덤 값을 테스트하는 방법에 대해 알게 되었다. 테스트를 위한 메서드를 만드는 게 아니라 인터페이스를 만드는 방식이라니 전자는 실제 클래스 내에서 의미 없이 자리를 차지하지만 후자는 테스트가 필요할 때만 주입 받아 사용할 수 있으니 정말 깔끔했다. 3단계를 진행해야하지만 어제 끝나버려서 밀러와 4단계를 진행했다. 스파크 자바라.. 처음 들어보기도 했고 3단계가 다 되었다 하더라도 리펙토링이 전혀 안 되어있는데 4단계가 진행이 될까? 싶었지만 어째 3단계에서 예외처리를 하며 컨트롤러를 정리해놓은 구조가 딱딱 들어맞아서 무리 없이 진행되었다. 무엇보다 밀러 덕에 스파크 자바 의존성 문제를 해결할 수 있어서 4단계를 시작할 수 있었다. 컨트롤러에서 상태값을 저장하고 있는 괴상한 구조이지만 어쨌든 기능을 완성한게 신기하다. Jackson 라이브러리를 사용하지 않아 Map 으로 일일이 html 에서 출력할 값들을 매핑하다보니 모양이 좀 안 좋아 보이긴 하지만 말이다.

🕛 4단계 (02.25)

• 페어 프로그래밍 마지막 날이다. 아침에 너무 일찍 깨서 몽롱한 상태로 1시간을 걷다 왔는데 정신이 말짱해지기는 커녕 더 축 처졌다. 그래도 마지막 날이라 가벼운 마음으로 남은 미션에 임했다 하려 했으나 컨트롤러에 상태값을 저장하는 형태를 벗어나기 위한 작업량이 꽤 많았다. 밀러가 Repository 패턴을 설명해주면서 여기에 상태값을 저장하자고 했다. 듣고 생각해보니 밀러가 설명한 Repository 에서 필요할 때마다 UserId 값을 계속 요청하고 가져오기에는 무리가 있을 거 같아 쿠키 사용을 제안했고 밀러가 동의하고 스파크 자바에서 쿠키 사용법을 뚝딱 찾았다. 쿠키 (쿠킴이 생각난다) 만으로는 다음 로직들이 실행되기 어려워 밀러가 DTO 클래스를 활용하여 뚝딱 처리했다. 작업 후에 컨트롤러가 너무 비대해 보여서 컨트롤러 뒷 단에 서비스 클래스를 따로 만들 것을 제안했는데 밀러가 좋다고 하고 뚝딱 컨트롤러 코드를 서비스로 옮겼다. 마지막으로 Repository 가 List 일급객체이다보니 id 를 찾고 삭제하는 로직이 비효율적이었다. 그래서 List 가 아닌 Map 으로 쿠키를 흉내내서 작업해 보는 것이 어떻냐고 동의를 구했다. 그렇다 밀러는 뚝딱이다. 얼추 틀을 잡은 뒤엔 구조가 변경되면서 발생한 잔에러를 처리하고 테스트 코드에서 미처 발견하지 못했던 케이스를 해결했다. 점심 먹고 오자고 해놓고 서로 캠 꺼놓고 버그 잡고 있었다. (캠 꺼놓고 채팅창에 해결했다고 메시지를 보냈더니 3분 만에 답장이 와있었다 🙄) 또 6시 이후에 안 하기로 했는데 둘 다 프로젝트를 읽고 있었다. 살펴보니 아쉬운 점이 있었고 이에 대해서는 시간이 맞을 때 같이 작업해보기로 했다!

💭 마무리

  페어 프로그래밍은 에너지가 배로 소요되는 기분이다. 혼자 작업을 할 땐 머리 속에서 생각나는 것을 바로 손으로 전달해서 치면 되는데, 페어 프로그래밍은 상대방에게 나의 생각을 이해시키고 내가 의도하는 방향으로 이끌어야하는 점, 그리고 상대방의 의도대로 내가 코드를 작성해야하는 점 때문에 마치 시험을 보고 있는 기분으로 집중력을 유지해야했다. 의견 충돌이 있을 때에도 상대방을 설득시키려 소통을 해야했다. 미션 기간 동안 의견 충돌이 얼마 있지도 않았고 그마저도 몇 분 내로 협의가 되었음에도 정신 소모는 상당했다. 항상 누군가와 팀을 이루어 개발을 해야하기에 밀러와의 페어 경험은 큰 도움이 될 것 같다.