[싸피일기] Web(front) 페어 프로그래밍 회고

싸피의 1학기는 페어 프로그래밍을 주축으로 돌아간다.

하나의 과목이 끝날때마다 페어와 함께 관통 프로젝트를 진행하기 때문에 끊임없이 협업을 경험할 수 있다는게 싸피의 장점😊 

 

 

이때까지의 페어 프로그래밍

 

 

이때까지 Java, 일타싸피, Web(front)까지 총 세 번의 페어 프로그래밍을 진행하였다.

그런데 Java와 일타싸피를 거치면서 어떤 방식으로 협업을 진행해야할지 고민이 들기 시작했다. 번번히 최종 프로젝트 과정이나 결과가 마음에 들지 않았기 때문이다.

 

Java 프로젝트를 진행할 때는, 서로 하나의 모델을 구현하고, 이후 이를 통합하는 컨트롤러를 구축하는 방식으로 진행했다. 그러다보니 비슷한 기능임에도 불구하고 중복으로 개발하는 비효율이 발생했다. 그리고 비슷한 기능임에도 함수명에 일관성이 없어 컨트롤러를 구현할 때 불편함이 있었다.

 

일타싸피때는 역량을 고려하지 않고 지나치게 구현 난이도가 높은 알고리즘을 선택하여, 결국 마감 시간 내에 제대로 된 프로그램을 구현하는데 실패하였다. 

 

두 번의 페어 프로그래밍을 겪으면서, 공통적으로 부족했던 부분이 무엇이였을까 생각해보았다. 개발 전, 페어와 충분한 설계를 거치지 않고 바로 개발에 착수했다는 점이었다. 그러다보니 작업이 효율적으로 이루어기지도 어려웠고, 여러 아이디어를 검토할 기회도 없었다.

 

 

 

 

 

 

 

Web(front) 페어 프로그래밍

 

 

그래서 이번 페어 프로그래밍에서는 페어와 사전 설계를 충분히 하고 협력다운 협력을 진행하고자 노력했다. 먼저, 작성할 html 파일을 결정하고 각 페이지 별로 간단히 그림을 그려보았다. 이 단계에서 시맨틱 태그단위로 페이지를 나누고 각 태그에 들어갈 요소와 대략적인 배치를 결정했다.

 

그리고 피그마를 이용해 목업을 만들어보았다. 모든 페이지에 공통으로 들어갈 nav와 aside를 우선으로 만들었다. 내가 nav를, 페어가 aside를 담당했는데 피그마에서는 작업창을 서로 공유할 수 있기 때문에 바로바로 완성된 부분을 복사해서 목업 제작에 활용할 수 있었다. 그리고 목업을 제작하면서 계속해서 제안을 하는 등 페어와 꾸준히 이야기를 나누었다.

 

이 과정을 거친 다음에 개발에 들어갔다. 개발을 할 때도 vscode의 liveshare 플러그인을 설치해서 함께 실시간으로 작업 과정을 공유했다. 

 

 

Plus

 

목업 제작에 시간을 들였음에도 불구하고, 충분한 논의 후에 작업했기 때문에 비효율적인 시간 낭비나 수정이 발생하지 않아 정해진 시간 내에 목표로 한 메인 페이지, 상세 페이지, 회원가입 페이지를 모두 제작할 수 있었다. 또한 변경된 사항을 제외하고는 목업으로 계획했던 대로 구현되었기 때문에 결과물도 만족스러웠다.

 

 

Minus

 

파일 구조에 대한 논의가 부족해서 나는 css를 적용할 때 인라인 방식을, 페어는 embeded방식을 적용해서 일관성이 떨어진다는 점이 아쉬웠다. 이후 꾸준히 페어 프로그래밍을 진행하면서 어디까지 함께 설계해야할지를 고민해가야 할 것 같다.