얼마 전 난생 처음으로 페어 프로그래밍을 접하고, 경험해볼 수 있는 기회가 있었다. 페어 프로그래밍이란 2명의 개발자가 짝을 지어 1명은 Navigator, 1명은 Driver의 역할을 번갈아가면서 수행하여 프로그래밍하는 방법을 일컫는다. Navigator는 Driver에게 코드를 어떻게 작성할지 지시하고, Driver는 Navigator의 지시를 무조건적으로 수용하는 것이 아니라 토론하고 타협하며 코드를 작성한다. 즉 페어 프로그래밍은 혼자 프로그래밍을 진행할 때 미처 생각하지 못했던 부분을 팀원과 함께 보완함으로써 궁극적으로는 양질의 코드를 작성하는 것에 그 의의가 있다.
이렇게만 읽어보면 페어 프로그래밍이 절대적으로 긍정적이라고 생각할 수 있지만, 마냥 그렇지만도 않다. 2명이 한 팀이 되어 코드를 작성하는 것은 후술하겠지만 생각보다 힘든 점이 많다. 일단 가장 큰 단점은 서로가 잘 맞지 않는 성향이거나 다툼이 생기면 페어 프로그래밍 과정이 순탄치 않다는 것이다. 그러므로 페어 프로그래밍을 진행하며 서로에게 의견을 피력할 때 권위주의적인 태도와 어투를 지양할 필요가 있다. 또한 2명의 의견을 하나로 취합하여 프로그래밍, 리팩토링 과정을 진행해야 하기 때문에 혼자 프로그래밍을 진행할 때보다 시간이 많이 걸릴 수밖에 없다. 그럼에도 불구하고 페어 프로그래밍의 이점은 굉장히 많다고 느꼈는데, 이에 대해 지금부터 본격적인 회고를 작성하면서 하나씩 짚어보고자 한다.
📌 페어 프로그래밍 요약
- 진행 인원
: 2명
- 진행 기간
: 22.09.12 ~ 22.09.23(주말 제외, 약 2주)
- 진행 과제
: 요구사항에 부합하는 11개의 기능 구현
- 진행 과정
(1) 과제 하나씩 구현
(2) 과제 하나씩 1차 리팩토링
(3) 전체 리팩토링 반복
2주간 진행한 페어 프로그래밍 과정을 요약하면 위와 같다. 본격적인 시작에 앞서 총 11개의 기능을 전부 구현하고 리팩토링을 진행할지, 각각의 기능을 구현할 때마다 리팩토링을 진행할지 고민했었다. 전자의 경우 리팩토링을 진행할 때 기억이 희미해질 것 같아서 우리 팀은 후자의 방식으로 진행하기로 협의했다.
💖 좋았던 점
일단 페어 프로그래밍을 함께 진행한 팀원과는 성향과 작업 방식이 유사했기 때문에 원활한 소통을 토대로 프로그래밍을 수월하게 진행할 수 있었다. 구체적으로는 하나의 기능을 구현할 때마다 노션에 따로 요구사항을 어떻게 구현할지 기능별로 대략적인 구현 방법을 팀원과 함께 논의하여 기술하고 시작했다. 세세하게 기능별로 구현 방법을 먼저 생각한 후에 작업했기 때문에 훨씬 수월하게 코드를 작성할 수 있었던 것 같다. 또한 기능 구현과 리팩토링 과정을 거칠 때마다 특정 방식을 왜 사용했는지, 새롭게 알게된 부분은 무엇인지 기록하면서 진행했다. 문서화 작업을 틈틈이 한 덕분에 나중에 다시 돌아와서 코드를 접했을 때도 작성했던 문서만 보면 기억을 되살리기 용이해서 좋았다.
💔 아쉬운 점
아쉬운 점이 있다면 먼저 리팩토링을 처음 접하다 보니 대략적으로 얼마나 시간이 소요될지 가늠하기 어려웠다는 점이다. 처음에 대략적으로 계획을 세울 때 기능 구현과 얼추 비슷한 시간을 리팩토링에 할애했는데, 생각보다 리팩토링 과정을 거치면서 생각할 부분이 많았다. 한 번 보고 다시 돌아와서 또 검토할 때 보이지 않았던 새로운 부분들이 보여서 그만큼 리팩토링에 시간이 배로 소요되었던 것 같다. 이처럼 리팩토링 경험 미숙으로 인해 촉박한 마감 기한을 앞두고 후반 과제들은 철저하게 리팩토링을 진행하지 못했을 뿐만 아니라 Navigator와 Driver라는 각각의 역할이 혼재된 채로 진행했던 아쉬움이 있었다. 또한 기능 구현을 할 때는 리팩토링 가능성에 너무 매몰되면 안 되겠다는 생각을 했다. 리팩토링까지 함께 생각하면서 기능 구현을 시도하니 애초에 기능 구현 자체도 시간 소모가 꽤 컸다. 먼저 기능을 구현할 때는 구현에 초점을 맞추고, 그 후에 리팩토링을 꼼꼼하게 하는 방식으로 진행하는 것이 더 효율적이겠다는 생각이 들었다.
👍 리팩토링 원칙
페어 프로그래밍을 통해 총 11개의 기능을 구현했는데, 처음부터 리팩토링 원칙을 세우고 진행하지는 않았다. 과제를 진행하면서 리팩토링을 거듭할수록 팀원과 함께 리팩토링에 관련된 규칙 내지는 컨벤션을 자연스럽게 수립하게 되었고, 이는 다음과 같다.
🔸 알기 쉬운 식별자 이름
사실 너무 당연한 부분이지만, 식별자 이름만 잘 지어도 어떤 내용을 담고 있는지 유추하기 쉬워지기 때문에 그만큼 코드 자체의 가독성을 향상시킬 수 있다. 개수를 세는 변수가 있다고 가정할 때 단순히 num으로 명명하는 것보다 currentCount처럼 구체적으로 명명하는 것이 훨씬 가독성 향상에 도움이 된다. 특히 함수의 매개변수는 v, i 등과 같이 대충 명명하고 넘어가기 쉬운데, 리팩토링 과정을 거치면서 매개변수 역시 구체적으로 작성하고자 노력했다.
🔸 변수는 명사형, 함수는 동사형
앞서 언급한 식별자 명명의 중요성과 연결된 내용이다. 변수는 대명사처럼 사용할 수 있어야 하기 때문에 명사형, 함수는 함수 몸체 내부에서 수행하는 행위를 대표해야 하기 때문에 동사형으로 명명하는 것이 가독성에 도움이 되는 것 같다. 특히 이 원칙이 진가를 발휘한다고 생각하는 부분이 함수가 메서드를 프로퍼티로 가지는 객체를 반환하는 경우다. 이 경우에 객체의 이름을 cat와 같은 명사형으로, 그 안의 메서드 이름을 eat, play와 같은 동사형으로 지으면 cat.eat, cat.play처럼 아주 명료하고 직관적인 코드를 작성할 수 있다.
🔸 함수화로 로직의 중복 제거
만약 동일하거나 유사한 로직이 코드 상의 여러 곳에서 재사용되고 있다면, 이를 함수화하여 중복을 제거하고자 했다. 불필요한 코드의 중복은 가독성 향상과 추후 유지보수 가능성을 고려하면 함수화하여 관리하는 것이 바람직할 것이다. 물론 어느 정도까지 함수화하는 것이 바람직한지에 대해서는 아직도 고민이 많다. 일단 이번 페어 프로그래밍에서는 중복되기는 하지만 classList.toggle 등 함수 내부 로직이 메서드 하나로 해결되는 경우에는 따로 함수화하지 않았다. 다만 그러한 메서드 여러 개가 중복되어 사용되는 경우에는 따로 함수화하여 호출하는 방식으로 리팩토링 과정을 거쳤다. 이 원칙은 사실 직관이 많은 영향을 미친다고 생각하기 때문에, 앞으로 프로그래밍을 더 해보면서 가치 판단을 위한 직관을 키워야겠다고 생각한다.
🔸 이벤트 핸들러 등록
이벤트 핸들러를 등록하는 부분에 있어서도 아직 명확한 가치 판단이 되지 않은 상태이긴 하지만, 그럼에도 이번 페어 프로그래밍을 통해 어느 정도 스스로의 가치관을 수립할 수 있었던 것 같다. 우선 동적으로 생성되는 요소인 경우 HTML 문서가 로드되어 DOM이 파싱되기 전에는 이벤트 핸들러를 등록할 수 없는 이슈가 발생하기 때문에 동적으로 생성되는 요소의 상위 요소에 이벤트 핸들러를 위임하여 등록하는 방식을 사용하고자 했다. 또한 동적 요소가 아니더라도 하나의 상위 요소 하위에 있는 다수의 요소들에게 동일한 이벤트 핸들러를 등록해야 하는 경우 역시 상위 요소에 이벤트 핸들러를 위임하여 등록하되, matches 등의 메서드를 사용하여 조건에 부합하는 이벤트 타깃만 이벤트 핸들러의 콜백 함수 내부 로직이 실행될 수 있도록 했다. 사실 하위 요소의 개수가 몇 개일 때 이벤트 핸들러를 등록해야 하는 것이 바람직한지 페어 프로그래밍을 함께 진행한 팀원과도 많은 논의를 했지만 아직까지는 명확하게 무엇이 옳다고 느껴지지는 않는다. 이 역시 앞으로 프로그래밍을 하면서 키워야 할 역량이라는 생각이 든다.
🌱 새로운 지식
페어 프로그래밍을 진행하면서 상술했듯 리팩토링에 대한 가치관을 수립했을 뿐만 아니라 기존에 무지했던 프로그래밍 지식들을 알게 되거나, 헷갈렸던 개념들을 정리하고 익숙해질 수 있는 계기가 되었다. 이 부분은 현재 작성하고 있는 TIL에 기록 중이지만, 그 중에서도 특히 기억에 남는 몇 가지를 회고하며 소개하고자 한다.
🔹 이벤트 관련
🔸 scroll
- 관련 메서드와 프로퍼티
:
scrollY와pageYOffset
:scroll과scrollTo
- 이벤트 발생 횟수 조절 방법
:
throttle과debounce
- 정리 링크
: https://velog.io/@nalsae/220913-%EC%98%A4%EB%8A%98%EC%9D%98-%EB%B0%B0%EC%9B%80TIL
🔸 transitionend
- 사용 목적
:
transition종료를 이벤트로 캐치하기 위해
- 주의할 점
: 정적으로 존재하는 요소 관련
- 정리 링크
: https://velog.io/@nalsae/220923-%EC%98%A4%EB%8A%98%EC%9D%98-%EB%B0%B0%EC%9B%80TIL
🔹 프로퍼티, 메서드 관련
🔸 localStrorage
- 관련 메서드
:
setItem,getItem
- 주의할 점
: 저장 값에 따른 참조 시 주의사항
- 정리 링크
: https://velog.io/@nalsae/220914-%EC%98%A4%EB%8A%98%EC%9D%98-%EB%B0%B0%EC%9B%80TIL
🔸 getComputedStyle
- 관련 메서드
:
getPropertyValue,setProperty
- 주의할 점
: 동적 생성 요소에 사용 시 특징
: 리플로우 발생 이슈
- 정리 링크
: https://velog.io/@nalsae/220914-%EC%98%A4%EB%8A%98%EC%9D%98-%EB%B0%B0%EC%9B%80TIL
: https://velog.io/@nalsae/220917-%EC%98%A4%EB%8A%98%EC%9D%98-%EB%B0%B0%EC%9B%80TIL
🔸 String
- 관련 메서드
:
padStart,padEnd
:replace
- 정리 링크
: https://velog.io/@nalsae/220915-%EC%98%A4%EB%8A%98%EC%9D%98-%EB%B0%B0%EC%9B%80TIL
: https://velog.io/@nalsae/220918-%EC%98%A4%EB%8A%98%EC%9D%98-%EB%B0%B0%EC%9B%80TIL
🔸 RegExp
- 관련 메서드
:
test
- 정리 링크
: https://velog.io/@nalsae/220918-%EC%98%A4%EB%8A%98%EC%9D%98-%EB%B0%B0%EC%9B%80TIL
🔸 Image
- 관련 프로퍼티
:
src,width,height
- 사용 목적
: Javascript로 이미지 요소 정보 취득
- 정리 링크
: https://velog.io/@nalsae/220921-%EC%98%A4%EB%8A%98%EC%9D%98-%EB%B0%B0%EC%9B%80TIL
🔹 즉시 실행 함수 관련
- 사용 목적
: 캡슐화와 정보 은닉
: 네임 스페이스
- 정리 링크
: https://velog.io/@nalsae/220913-%EC%98%A4%EB%8A%98%EC%9D%98-%EB%B0%B0%EC%9B%80TIL
: https://velog.io/@nalsae/220921-%EC%98%A4%EB%8A%98%EC%9D%98-%EB%B0%B0%EC%9B%80TIL
😊 마무리
솔직히 그동안 이론 공부의 비율이 더 컸기 때문에 절대적인 코드 구현 시간이 부족하다 보니 코드 구현 자체가 너무 낯설고 어렵게 느껴져서 초반엔 힘들기도 했다. 문법 지식을 공부하는 것과 이를 응용하여 코드를 작성하는 것은 역시 완전히 다른 차원의 일임을 체감하게 되었다. 스스로 좌절하는 과정을 반복해서 겪었지만 그만큼의 재미와 성장이 수반되었기 때문에 페어 프로그래밍 과정 내내 즐겁게 진행할 수 있었다. 매일 약 10시간이 넘도록 코드를 작성하고 어떻게 하면 조금 더 좋은 코드로 바꿀 수 있을까 치열하게 고민한 덕분에 코드를 작성함에 있어서 스스로 가지고 있었던 두려움을 좀 해소할 수 있었던 것 같다. 기능 구현에 급급했던 과거의 나에 비하면 확실히 성장했다는 느낌이 들어서 스스로 뿌듯하기도 하고 말이다. 특히 혼자 코드를 작성할 때 생각하지 못했던 부분을 팀원과 함께 논의하는 과정에서 코드를 바라보는 관점이 조금은 넓고 단단해진 것 같아서 만족스러웠다. 아무래도 혼자 코드를 작성하고 계속 접하다 보면 편협한 시각으로 스스로의 코드를 바라볼 수밖에 없기 마련인데, 타인의 새로운 시각으로 바라볼 때 전혀 다른 코드가 나올 수도 있다는 사실이 신기하기도 하고 흥미로웠던 것 같다. 앞으로 페어 프로그래밍을 한 번 더 진행할 예정인데, 앞서 회고를 작성하면서 부족하다고 느꼈던 지점들을 개선하고 보완할 수 있도록 노력해봐야겠다.
