지난 번에 이어 이번에는 새로운 팀원과 2차 페어 프로그래밍을 진행하게 되었다. 1차 페어 프로그래밍 때도 정리했던 페어 프로그래밍의 의의에 대해 짚고 넘어가자면 다음과 같다. 보편적으로 페어 프로그래밍이란 2명의 개발자가 짝을 지어 1명은 Navigator, 1명은 Driver의 역할을 번갈아가면서 수행하여 프로그래밍하는 방법을 일컫는다. Navigator는 Driver에게 코드를 어떻게 작성할지 지시하고, Driver는 Navigator의 지시를 무조건적으로 수용하는 것이 아니라 토론하고 타협하며 코드를 작성한다. 즉 페어 프로그래밍은 혼자 프로그래밍을 진행할 때 미처 생각하지 못했던 부분을 팀원과 함께 보완함으로써 궁극적으로는 양질의 코드를 작성하는 것에 그 의의가 있다.
이렇게만 읽어보면 페어 프로그래밍이 절대적으로 긍정적이라고 생각할 수 있지만, 마냥 그렇지만도 않다. 2명이 한 팀이 되어 코드를 작성하는 것은 후술하겠지만 생각보다 힘든 점이 많다. 일단 가장 큰 단점은 서로가 잘 맞지 않는 성향이거나 다툼이 생기면 페어 프로그래밍 과정이 순탄치 않다는 것이다. 그러므로 페어 프로그래밍을 진행하며 서로에게 의견을 피력할 때 권위주의적인 태도와 어투를 지양할 필요가 있다. 또한 2명의 의견을 하나로 취합하여 프로그래밍, 리팩토링 과정을 진행해야 하기 때문에 혼자 프로그래밍을 진행할 때보다 시간이 많이 걸릴 수밖에 없다. 그럼에도 불구하고 페어 프로그래밍의 이점은 굉장히 많다고 느꼈는데, 이에 대해 지금부터 본격적인 회고를 작성하면서 하나씩 짚어보고자 한다.
📌 페어 프로그래밍 요약
- 진행 인원
: 2명
- 진행 기간
: 22.09.26 ~ 22.10.07(주말 제외, 약 2주)
- 진행 과제
: 요구사항에 부합하는 10개의 기능 구현
- 진행 과정
(1) 1 ~ 8번 기능 구현
(2) 1 ~ 8번 기능 리팩토링
(3) 9 ~ 10번 기능 구현
(4) 9 ~ 10번 기능 리팩토링
(5) 전체 리팩토링 반복
2주간 진행한 페어 프로그래밍 과정을 요약하면 위와 같다. 전체적인 진행 방식은 앞서 진행했던 페어 프로그래밍과 유사하다. 다만 저번 페어 프로그래밍 때 시간이 부족했던 점을 개선하고자 했다, 특히 9 ~ 10번 기능 구현이 까다롭다고 판단하여 팀원과 협의 후 진행 방식을 조금 수정하였다. 구체적으로는 1 ~ 8번 기능 구현을 먼저 진행한 후 1차 리팩토링을 진행하고, 시간이 많이 소요될 것으로 예상되는 9 ~ 10번을 구현하기로 결정했다.
💖 좋았던 점
저번과 마찬가지로 이번에도 페어 프로그래밍을 함께 진행한 팀원과 성향도 유사하고 소통이 잘 이루어졌기 때문에 수월하게 전체적인 과정을 마무리할 수 있었다. 특히 이번에는 저번에 체감했던 아쉬운 점을 최대한 보완하고 개선하고자 노력했는데, 진행 과정 중에 이를 잘 지킬 수 있었던 것 같아 만족스럽다. 구체적으로 살펴보면 먼저 저번에는 시간 부족으로 후반부로 갈수록 구현 및 리팩토링이 미흡했다는 결론을 도출하여, 이번에는 먼저 전체 구현부터 완성하고 리팩토링을 진행하는 것으로 계획을 변경했다. 그 결과 10번 기능을 제외하고는 균등한 퀄리티를 이끌어낼 수 있었다. 또한 저번에는 시간 부족으로 인해 후반부로 갈수록 Navigator와 Driver의 역할이 혼재되어 페어 프로그래밍의 의의가 퇴색되었던 것 같다는 결론을 도출했었다. 이번에는 Navigator와 Driver의 역할 수행을 최대한 분리하고자 노력했고 전체적으로 저번보다 개선된 것 같아서 만족스러웠다.
그 외 다른 부분은 저번 페어 프로그래밍 때의 좋았던 점과 유사하다. 기능 구현 전과 후에 요구사항 및 새롭게 알게 된 점을 노션에 기록하며 문서화 작업을 수행했고, 그 결과 다시 돌아와서 예전에 작업했던 코드를 살펴볼 때 복기가 용이했다. 그리고 모듈화와 컴포넌트에 대한 개념을 정리하고 코드로 구현해볼 수 있어서 좋았다. 확실히 이론으로만 접했을 때 와닿지 않던 부분들이 직접 코드로 구현할 때 체감되는 경우가 있는 것 같다.
💔 아쉬운 점
일단 결과적으로 보면 10번 기능을 구현하지 못하고 페어 프로그래밍이 종료되었다는 아쉬움이 남지만, 그만큼 9번 기능에 많은 고민과 노력을 들여 후회가 남지는 않는다. 마감 기한으로 인해 스스로 느끼는 기능 구현에 대한 압박감을 컨트롤 할 수 있어야 한다고 생각하면서도, 마냥 쉽지 않다고 새삼 느끼게 되었다.
또한 컴포넌트에 대한 이해가 제대로 선행되지 않은 채 CBD, SPA 기반 라이브러리를 유사하게 구현하려고 하니 어떻게 구현해야 할지 감이 오지 않았을 뿐만 아니라, 어찌저찌 1차적으로 완성한 기능도 아쉬움이 많이 남아서 결국에는 아예 갈아엎고 처음부터 구현을 하게 되었다. 물론 그만큼 시행착오를 겪었기 때문에 다양한 방법으로 컴포넌트에 대해 고찰해볼 수 있었지만, 이 과정에서 소요되는 시간이 길어졌기 때문에 결국 시간이 부족해졌다는 점은 어쩔 수 없는 아쉬움이 남는 것 같다. 이를 통해 어떤 기능을 구현할 때 관련된 개념, 아키텍처 등에 대한 선행적 이해가 필수불가결하다는 것을 깨달았다. 이때 단편적인 것으로 이해하는 것에 그치지 않고, 직접 설명할 수 있을 정도로 체화해야 구현 방향을 좀 더 명료하게 정하고 구현을 시작할 수 있을 것 같다. 구현 방향만 제대로 정하고 코딩을 시작해도 헤매는 시간이 현저히 줄어드는 것은 당연한 수순일 것이다.
그리고 시간적 제약 때문에 제대로 실천하지는 못했지만, 구현해야 하는 기능별로 요구사항 정의나 기능 명세를 꼼꼼하게 문서화하지 못했던 점이 아쉬움으로 남는다. 물론 전반적으로 간단한 기능들이기 때문에 크게 문제는 없었지만, 후반부로 갈수록 복잡한 기능 구현을 마주했을 때 문서화 작업의 미비로 깜빡한 요구사항이 한두 개씩 있었다. 다음에 복잡한 기능을 구현할 때는 꼭 요구사항을 세세하게 정의하고, 내가 아는 프로그래밍 지식 중에 어떤 것을 사용하여 구현할지 구체적으로 기록해야겠다. 더불어 구현해야 할 기능, 혹은 애플리케이션의 전체적인 구조를 그림으로 그려두면 구현하는 데 큰 도움이 될 것 같다.
👍 리팩토링 원칙
전체적으로 저번 페어 프로그래밍 때 수립할 수 있었던 스스로의 리팩토링 원칙을 유지하며 진행하되, 추가적으로 고려했던 사항까지 기술하면 다음과 같다.
🔸 기존 리팩토링 원칙
- 링크
🔸 고정 값의 상수화
이 부분은 저번 페어 프로그래밍이 끝나갈 때쯤 대두된 고려사항이라 이번에 좀 더 신경을 쓴 부분이다. 코드 상에서 변하지 않는 원시 값은 불변성을 유지해야 하므로 const 키워드를 사용하여 전역에 상수화했는데, 이뿐만 아니라 상수라는 것을 인지하기 쉽도록 명명 시 대문자를 사용하고자 했다.
🔸 변수의 위치
변수의 스코프를 어떻게 설정할지에 대해서도 많은 고민을 했던 것 같다. 특히 이번 페어 프로그래밍에서는 전반적으로 ES 모듈을 사용한 과제가 대부분이어서 전역 변수 사용에 대해서는 크게 고민거리가 없었다. 하지만 변수를 지역 스코프 안에서 사용하게 할 것인지, 모듈 스코프 안에서 사용하게 할 것인지에 대해서는 고민의 여지가 있었다. 물론 상황에 따라 선택지가 달라지겠지만, 웬만하면 지역 변수로 사용하는 것을 원칙으로 했다. 다양한 함수에서 변수를 참조할 수 있다는 것은 그만큼 변수의 값이 가변적일 가능성이 커진다는 의미이므로 위험하다고 판단했기 때문이다.
🔸 성능보다 가독성
성능과 가독성 사이에서 타협점을 찾는 것은 항상 느끼지만 제일 어려운 부분인 것 같다. 그런 이유로 저번 페어 프로그래밍을 진행하면서도 굉장히 혼란스러웠던 부분이라 따로 리팩토링 원칙에 기술하지 않았다. 그 예로 저번에는 querySelector 메서드를 한 번이라도 덜 호출하고자 노력했고 가독성에 있어 아쉬웠던 점이 느껴졌던 것 같다. 하지만 프론트엔드에서 처리해야 할 데이터 수가 백엔드에 비하면 상대적으로 적기 때문에 치명적인 경우가 아니라면 메서드 호출 시 발생하는 성능 차이가 크지 않다는 것을 깨달았다. 그래서 이번 페어 프로그래밍을 진행할 때는 웬만하면 성능보다 가독성에 우선 순위를 두는 방향으로 진행했다.
🌱 새로운 지식
저번 페어 프로그래밍에 이어 이번 페어 프로그래밍 역시 프로그래밍 지식에 있어 기존에 무지했던 부분을 새롭게 알아갈 수 있었다. TIL에 따로 기록 중이지만, 그 중에서도 특히 인상 깊었던 몇 가지를 소개하고자 한다.
🔹 이벤트 관련
🔸 drag
drag관련 이벤트의 사용 방법:
dragover,drop,dragstart,dragleave
:dataTransfer객체
- 주의할 점
:
drop이벤트의 선행 조건으로dragover이벤트 발생
- 정리 링크
🔸 커스텀 이벤트
detail프로퍼티 사용 방법: 커스텀 이벤트 발생시
detail프로퍼티에 정보 전달
- 정리 링크
🔹 메서드 관련
🔸 Array.from
- 만들 배열의 요소 개수만 알고 있을 때 사용 방법
:
length프로퍼티를 미리 인수로 지정
- 정리 링크
🔸 classList
toggle과add,remove: 반복문을 돌면서
toggle을 수행하는 것보다remove수행 후add하는 방법도 존재
🔸 Date
- 사용 방법
: 이전 달의 마지막 날 취득 방법
- 정리 링크
🔹 연산자 관련
🔸 단축 평가
&&과||: 좌항과 우항의 불리언 값에 따라 유동적으로 값 반환
- 정리 링크
😊 마무리
확실히 1차 페어 프로그래밍 때 스스로 리팩토링에 대한 가치 판단이 일부 정립되어 이번 2차 페어 프로그래밍 때는 리팩토링 과정을 진행하면서 고민하는 시간이 줄어들었다. 물론 상술했듯 리팩토링과 관련하여 아직 옳고 그름을 판단하는 데 어려움은 있지만, 앞선 2번의 경험으로 적어도 리팩토링의 지향점을 판단할 수는 있게 된 것 같다. 또한 1차 페어 프로그래밍 때에 비해 확실히 기능 구현을 할 때 머리 속으로 어떻게 구현할 지 훨씬 명료하게 그림이 그려지는 느낌이 들어서 성장을 체감했다. 물론 후반부의 복잡한 로직을 구현할 때는 많이 헤매고 좌절하기도 했지만, 팀원과 함께 치열하게 고민하면서 즐겁게 이번 페어 프로그래밍도 마칠 수 있었던 것 같다. 저번 회고를 마무리하면서도 작성한 부분이지만 결국 페어 프로그래밍은 혼자 코드를 작성할 때 생각하지 못했던 부분을 팀원과 함께 논의하는 과정에 그 의의가 있다. 새로운 팀원과 함께 새로운 시각으로 코드를 바라봄으로써 스스로 코드를 바라보는 관점이 조금은 넓고 단단해진 것 같아서 신기하고 흥미로웠다. 또한 이번 페어 프로그래밍 전에 헷갈렸던 모듈화나 컴포넌트에 대한 개념을 수립할 수 있어서 좋았다. 앞으로 다시 페어 프로그래밍을 진행할 기회가 있다면, 앞서 회고를 작성하면서 부족하다고 느꼈던 지점들을 개선하고 보완할 수 있도록 노력해봐야겠다.
