목차
들어가며
안녕하세요. 페어 프로그래밍 또는 짝 프로그래밍 또는 깐부 프로그래밍을 너무나도 좋아하는 joonhan 입니다.
올해 본과정에 들어와서 처음 페어 프로그래밍을 접했는데, 개인적으로 잘 맞는 학습 방법이라는 것을 느꼈습니다.
그래서 페어 프로그래밍이란 무엇인지, 페어 프로그래밍을 통한 자료구조 스터디 후기를 작성한 적이 있습니다.
참고 자료
이번에는 페어 프로그래밍을 본과정 과제인 Philosophers 를 수행하기 위해 활용해보았습니다. 그리고 이너서클 과제를 함께 수행할 동료를 찾을 수 있는 42 Peer 동아리 에서 만난 팀원 분들과 함께 코드 리뷰 스터디를 진행하며 느낀 점들을 글로 정리해보았습니다.
꼭 페어 프로그래밍이 정답은 아니겠지만, 42에서 추구하는 학습 방향이 동료 학습이고, 42가 아니었다면 감히 페어 프로그래밍을 시도해볼 엄두가 나지 않았을 것 같습니다.
이 글을 계기로 클러스터에 페어 프로그래밍을 하시는 분들이 조금씩 늘어났으면 하는 작은 소망이 있습니다. 편안한 마음으로 읽어봐주시면 감사하겠습니다.
스터디 후기
페어 프로그래밍에 코드 리뷰 곁들이기
이번 철학자 과제도 지난 과제들과 마찬가지로 2명이 팀을 이루어 프로그램을 완성하는 페어 프로그래밍을 활용해서 과제를 진행했다.
다만, 이번에는 다른 분들과 함께 총 5명이 모여 코드 리뷰 스터디를 이루어 진행했다.
Slack 에서 발견한 스터디 모집 게시물
평일 오후 1시에 모여서 각자 작성한 코드를 공유하고, 궁금하거나 이해되지 않는 부분을 서로에게 물어보고 답변하는 방식으로 진행했다.
github 에 함께 공유할 repository 를 생성했고, submodule 로 각자의 repository 를 공유하도록 했다. git submodule 을 이번에 처음 써보았는데, 여러 명이 각자의 작업 내역을 공유하기 좋은 기능이라는 것을 알게 되어 이를 글로 작성하여 스터디원들 뿐만 아니라 다른 분들도 참고할 수 있게 글로 정리하였다. 이 과정에서 git 에 조금 더 익숙해질 수 있었다.
[팔만코딩경]
우리는 코드 공동체입니다.
스터디 초반에는 처음 보는 개념과 함수들을 공부해야 하기 때문에 코드 리뷰를 받을 수 있는 부분이 없었다. 대신 과제를 어떤 방식으로 접근할 것인지, 과제에서 요구하는 것이 무엇인지 파악하기 위해 많은 이야기를 나누었다. 그리고 이전에 철학자 과제를 평가해본 적이 없어서 이미 과제를 해결하신 분들에게 어떻게 과제를 해결하면 좋을지 지식 품앗이를 요청하거나, 개인적으로 여쭤보기도 했다.
jujeon 님께서 진행하신 지식 품앗이 참여 후기
만약 처음부터 서브젝트만을 통해 문제를 해결했다면 많이 막막했을 것 같은데, 다른 분들의 도움을 받아서 수월하게 진행할 수 있었다. 그리고 가장 좋은 학습은 다른 분들 평가를 많이 다니면서 과제에 대한 이해도를 높이고, 다양한 관점에서 작성된 코드들을 많이 접해보는 것이라는 것을 느꼈다. 철학자 과제를 하면서 평가를 많이 다녔는데, 한번도 철학자 평가가 안 잡히다가 철학자 과제를 통과하고 나서야 잡혔던 것이 아쉬웠다.
스터디 중반에 접어 들면서 본격적인 코드 리뷰가 가능해졌다. 다른 동료 분들의 코드를 보며 코드에 녹아내려진 생각의 흐름과 논리를 이해했다. 그리고 이해되지 않는 부분은 바로 질문해서 해소하거나, 좋은 의견을 제시함으로써 서로의 코드 퀄리티를 높여갔다.
슬랙에서 주고 받은 정보들
스터디를 좋았던 점을 꼽으라면 하면서 각자 새롭게 알게 된 사실이나, 다른 동료 분들과 이야기하며 얻은 정보를 서로 공유를 했다는 것이다. 매일 만나서 서로 정보와 의견을 나누었기 때문에 점진적으로 과제에 대한 이해도를 높일 수 있었다.
그럼에도 코드 리뷰는 계속 되어야 한다.
사실 매일 만나서 코드 리뷰를 받는 건 어려운 일이다.
어떤 날은 문제점을 해결하지 못해서 코드 1줄조차 수정하지 못해 코드 리뷰를 받을 수 없었던 적도 있었다. 그래서 스터디원들이 아닌 다른 분들에게 발생한 문제에 대해 여쭤보기도하고, 코드를 진찰(?)해달라고 부탁했다.
코드에 마가 꼈습니다.
하지만 무엇이 문제인지, 어디서 발생하는 문제인지 감조차 잡지 못해서 코드에 마가 꼈다고 결론을 내리고 코드를 전부 날리고 다시 작성하기도 했다.
신기한 건 이해한 내용을 바탕으로 다시 처음부터 코드를 작성하면 생각보다 잘 작동한다는 것이었다. 불필요한 변수와 함수를 걷어내고, 생각의 흐름을 정리하다보니 코드를 자연스럽게 작성할 수 있었다. 글을 작성할 때도 생각이 정리되면 알아서 술술 써내려가지는 것처럼 코드도 마찬가지로 개념에 대한 이해가 정립되면 물 흐르듯 쓸 수 있었다.
코드 리뷰를 받을 때는 다른 스터디원 분들의 질문의 본질적인 의도를 파악하기 위해 노력했고, 혹시라도 놓치고 있는 개념이 있는지 파악하고자 했다. 반대로 코드 리뷰를 할 때는 상대방의 코드에서 배울 점이 무엇인지, 개선되면 좋을 것 같은 부분이 있는지, 나의 코드와 비교했을 때 어떤 점이 다르고 어떤 점이 비슷한지 비교하며 자연스럽게 코드를 작성하는 관점을 넓힐 수 있었다.
번뜩이는 아이디어는 가끔 나를 찾아온다.
주의 : 과제에 대한 스포일러가 포함되어 있습니다.철학자 보너스 과제에서는 뮤텍스가 아닌 세마포어를 사용해서 프로세스 간 통신을 구현해야 한다.
메인 프로세스에서 프로그램의 종료를 감지하는 스레드와 모든 철학자가 식사를 완료했는지 감지하는 스레드로 총 2개의 모니터링을 구현했다.
.png&blockId=609f8109-e213-4db8-aa2d-46f742dc02db)
하지만 철학자가 식사를 하다가 생존 시간이 지나버린 경우에는 모든 철학자가 식사를 완료했는지 감지하는 스레드가 종료되지 않고 계속 대기하는 현상이 발생했다.
이 문제를 해결하기 위해서 프로그램의 종료를 감지하는 스레드가 프로그램을 종료하기 전에 모든 철학자가 식사를 완료했는지 감지하는 스레드가 종료될 수 있도록 처리를 했다.
// 프로그램의 종료를 감지하는 스레드
...
if (식사 종료 감지 == TRUE)
{
// 모든 철학자가 식사를 완료했는지 감지하는 스레드가 종료되도록 처리
while (식사 횟수 감지 스레드가 종료할 때 까지)
{
식사 횟수 += 1
}
...
}
C
복사
이 문제만 해결하면 과제를 마무리할 수 있었는데, 찰나의 순간에 이런 아이디어를 떠올렸다는 사실에 스스로 놀랐었다.
모든 과제를 이렇게 해결했다면 정말 좋았겠지만, 매번 그렇지는 않아서 이번에 맞이한 행운을 두고두고 기억하고 싶어 함께 적었다.
되돌아보며
이번 과제를 하며 아쉬웠던 점은 처음부터 너무 완벽한 코드를 짜려고 하다보니 코드가 잘 나오지 않았다는 것이다. 그리고 디버깅을 하려고 해도 어디서 문제가 발생했는지 쉽게 파악할 수 없었다.
그래서 일단 작동하는 코드를 최대한 작게 만들어서 테스트를 거치고, 조금씩 덧붙여가면서 완성도를 높이는 것이 훨씬 빠르고 효과적이라는 것을 많이 느꼈다.
그리고 코드 리뷰는 많이 받아볼수록 좋다는 것을 느꼈다. 평가를 받을 때만 코드를 설명하는 것이 아닌 리뷰 시간마다 코드를 설명해야 하기 때문에 실시간 디펜스를 해야 한다. 이 과정에서 평가를 자연스럽게 준비할 수 있게 되고, 발생할 수 있는 예외 상황에 대해서도 충분히 많이 생각해볼 수 있어서 좋았다. 그리고 상대방의 질문을 정확하게 이해하는 것도 결코 쉽지 않기 때문에 코드 리뷰 스터디를 통해 상대방의 말을 이해하는 연습을 충분히 할 수 있었다.
과제를 시작해서 마치기까지 1달이라는 시간이 걸렸지만, 이 과정에서 충분히 많은 것을 공부하고 얻어갈 수 있었다. 누군가 이 과제를 하게 된다면 기꺼이 배운 내용을 공유하고 싶다. 다른 분들이 우리에게 기꺼이 시간을 내어 도와주었던 것처럼.
마치며
마지막으로 하나 아쉬웠던 점을 꼽자면, 클러스터에 회의 테이블이 충분하지 않았다는 점이다.
현재 42서울에서는 사이드 프로젝트 뿐만 아니라 과제를 수행하기 위해 결성된 여러 스터디가 존재하고 있다. 42에서 동료 학습은 클러스터의 아이맥에서 진행하도록 권장하고 있지만, 3명 이상 진행하는 스터디를 이루게 된다면 여러 불편함이 존재한다. 우선 여러 명이 1대의 아이맥 앞에서 공간을 차지하기 때문에 다른 분들이 이동할 때마다 길을 내기 위해 비켜주어야 한다. 다음으로는 제한된 공간에서 여러 명이 아이맥 화면을 제대로 보기에는 불편하다.
그래서 회의 테이블에서 전자 칠판에 화면을 띄우거나 화이트 보드에 판서를 그림으로써 하나의 화면을 동시에 바라보면 앞에서 언급한 2가지 문제가 동시에 해결된다.
하지만 현재 개포 클러스터 기준으로 회의 테이블이 적다는 느낌을 많이 받는다. 예약을 하지 않고도 이용할 수 있는 회의 테이블은 오전 10시 ~ 11시부터 이미 자리를 차지하신 분들이 많기 때문에 점심 시간 이후에는 회의 공간을 찾기 위해 지하 1층부터 5층까지 다니면서 남은 자리를 찾아 다녀야 하는 번거로움이 있다.
회의 공간을 새롭게 만드는 과정이 빠른 시일 내에 이루어질 수는 없겠지만, 지금보다 더 늘어나면 좋겠다는 바람이 있다.
