[부스트캠프] 5주차. 페어 프로그래밍과 추상화

5주차에 페어 프로그래밍이라는 것을 했다. 

자바 스프링으로 프로젝트할 때에도 페어 프로그래밍과 유사품을 경험해보긴 했지만, 

진짜 페어 프로그래밍이 무엇인지 생각해보진 못했다. 

 

실제론 내비게이터(뒤에서 보면서 첨언하는 방식)와 드라이버(직접 코드를 작성하는 방식)를 두고 개발을 한다고 한다. 

어찌보면 기존에 했던 방식과 비슷했다. 

디스코드로 화면을 띄우고, 이를 보면서 같이 보면서 한 사람은 로직을 짜고, 이에 대해 실시간으로 같이 보면서 소통하는 방식이었다. 

 

25분마다 번갈아 가며 드라이버를 바꾸는 경우도 있었지만, 나와 페어는 그렇게까지 하지는 않았다. 

대신에 깃을 조금 더 공부해서, 이를 더 수월하게 하는 방법을 생각했다. 

각자의 브랜치를 만들고, 합치는 브랜치에서 이를 모았다. 

이를 통해 upstream에 함께 풀 리퀘스트를 올리는 방식으로 진행했다. 

 

하나의 방법론이 나올때 마다 새로운 개발 방식, 새로운 기술을 가져오게 된다. 

우리는 '페어 프로그래밍은 이렇게 해야한다.', '더 좋은 페어 프로그래밍 방식은 무엇이 있을까?' 보다, 

어떻게 하면 페어 프로그래밍을 하기 수월한 환경을 만들 수 있을까?

이 부분에 집중했다. 

 

방법은 깃 플로우(혹은 브랜치 전략)를 공부하는 방식으로 선정되었다. 

 

깃 플로우는, 우리가 단순히 하나의 브랜치에서 개발을 하는 방식이 아닌, 

구현해야할 내용에 부합하는 브랜치를 따로 만들고,

해당 부분이 문제가 없다는 것을 검증한 후 병합하는 방식으로 이해했다. 

 

더 디테일하게 feat, fix, develop등의 브랜치를 두고 싶지만, 과제를 시간 내에 완수하고 싶다는 욕심이 강력하다!

이에 대한 장점은 무엇일까? 

하나의 develop, 하나의 feat 브랜치를 같이 공유해 작업하고, 모두가 이해할 수 있고 문제가 없다고 판단되면 병합하는 방식으로, 

더 검증된 코드 브랜치를 전체에 머지시킬 수 있다는 장점을 느꼈다. 

 

기존 프로젝트를 하면서도 깃 플로우를 적용했었다. 

하지만, 이 때의 목적은 하나의 브랜치를 같이 작업하면 서로 git pull을 계속해서 써야한다는 단점 때문에 그랬는데, 

이번 기회를 통해 서로의 브랜치를 가져와 검증하고, 페어 프로그래밍 때에는 하나의 브랜치로 같이 작업하면서 

깃 플로우를 진정으로 '활용' 했다고 느끼는 한 주였다. 

---

이후에 주말동안 기존 코드를 각자 리펙토링해보았다. 

함께하는 페어분이 타입스크립트를 아직 적용하기엔 스스로의 학습이 되어있지 않다고 하여, 

혼자 타입스크립트로 마이그레이션을 진행했다. 

 

이 때 느낀 것은, 내가(우리가) 만든 객체가 상당히 중복된다는 것이다. 

이를 위한 추상화가 타입스크립트에서는 상당히 잘 되어있었다. 

interface, class를 이용한 자바와 동일한 추상화가 상당히 잘 될 수 있었다. 

(추상화에 대한 개념은 블로그에서 한번 정리한 적이 있어 스킵한다!)

---

페어 프로그래밍과 분업화를 머릿속으로 비교해보았을 때, 확실히 장인들의 협업과 산업혁명의 분업화가 생각났다. 

분명 모든 사람들이 기술력이 있고, 이를 최대한 활용해 최대의 양적 효율을 끌어내려면, 분업을 통한 각자 제작의 방식이 나을 것이라고 생각된다. 

 

 

하지만, AI가 나온 이 세상에서(vs 익스텐션, 지피티, 코파일럿, 자동생성. Lets Go) 분업화가 과연 필요해질까 라는 생각이 들었다. 

오히려 이렇게 나온 코드들을 페어 프로그래밍을 통해 질적 향상을 시킬 수 있도록 하는게 더 나을 것 같다. 

페어프로그래밍이란 놈을 부스트캠프의 팀 프로젝트에서도 한번 해봐야겠다. 

 

그럼...twenty thousand...🔥