[우테캠] 2차 팀별 과제 회고록

오늘부로 2차 팀별 과제가 완료되었습니다!!🎉🎉🎉

이번주에는 프로젝트에 집중하느라 TIL도 작성 못하고, 다 끝난 오늘 회고록을 작성해봅니다.😭

 

이번 프로젝트에서는 물론 기술적으로 많은 성장이 있었지만,

팀원으로써 프로젝트를 진행하는 스킬(?)이 많이 성장하게 된 프로젝트였습니다.🔥

 

이 글은 제가 프로젝트를 어떤 순서대로 진행하였는지 설명하고

그 과정에서 알게 된 점에 대해서 이야기하는 방식으로 작성해보았어요.🤗

 

1. 프로젝트 기획

프로젝트 요구사항을 받고 저희가 가장 먼저 한 것은 프로젝트의 요구사항을 정리하고

팀!으로서 일하기 위해서 여러 규칙들을 정해보는 것이었습니다.👍🏻

 

정한 규칙은

• 스크럼 시간 및 대략적인 예상 일정
• Github에서의 branch flow와 네이밍 규칙 / commit 메세지
• 이슈와 PR 작성 방법
• 코드 Convenction
• 파일 구조!

이렇게 5가지 규칙에 대해 팀원분과 함께 이야기를 나눠보고 개발을 진행할 때 참고하였습니다.🤗

 

(1) 스크럼 시간

스크럼은 해당 일자의 업무가 시작되는 시간에 맞추어 매일 진행하였습니다.

평소에는 9:30에 시작하였고, 월요일은 시작 시간과 동시에 강의가 시작되기 때문에 수업이 끝난 3시에 스크럼을 진행하였습니다.

 

지금까지한 업무와 당일 진행할 업무에 대해 이야기를 나누었고,

기술적으로 막힌 부분이나 중요한 사항에 대해서 회의를 진행하는 시간을 가졌습니다.

🌹 사실 스크럼을 꾸준히 가지기는 했지만, 매주 시작일에 일주일 계획을 세우는 스프린트 회의에 관해서는 미흡한 부분이 있었습니다. 다음 프로젝트에서는 한 주가 시작하는 월요일에 대략적은 일정과 ToDo 리스트를 정리할 수 있도록 해야 겠습니다.👏🏻

 

(2) branch & commit 규칙

👇🏻 git branch 규칙은 아래 사이트를 참고하였습니다.

우린 Git-flow를 사용하고 있어요 | 우아한형제들 기술블로그

📌 Branch

1. 개발을 위한 feature branch
2. 코드 리뷰들과 개선 사항을 반영하기 위핸 refactoring branch

저는 주로 이 두 branch를 생성하여 개발을 진행하였습니다.

 

📌 Commit

1. 새로운 기능을 구현한 feature/
2. 에러 사항을 수정한 fix/
3. 주석 / 로그 등의 불필요한 코드를 제거한 style/

위 3가지 commit을 주로 작성하였고, 이때!!!

🌹 commit 메세지 뒤에 (#이슈번호)를 붙임으로써 관련된 이슈와 함께 관리가 되도록 하였습니다.😌

 

Issue와 PR에 대해서는 아후 프로젝트 진행 상황에서 더 자세히 말씀드리겠습니다.🤗

(관련해서 많은 일이 있었어요.ㅎㅎ)

 

(3) Convention

위에서 정한 규칙 중 제가 가장 신경쓰지 못한 부분이 바로 코드 Convention이었어요.😭

 

프론트엔드에서는 eslint 파일을 직접 작성하여

팀원들 간의 Convention을 IDE 단에서 바로 적용할 수 있었는데,

안드로이드에서는 그렇게 Convention을 강제할 수 있는 방법을 찾지 못했습니다.😳

 

결국 지금 되돌아보면, Convention을 잘 확인해보지 않고 제 개인 취향대로 개발한 코드가 많더라고요.

이 부분에 대해서는 다음 프로젝트가 시작하기 전에 수정해볼 예정입니다!😤

 

(4) 파일 구조

 

 

2

(1) 초반에 부족했던 협업

프로젝트를 회고해 보면서... 초반에는 협업 과정이 많이 미흡했다고 생각해요.🥲

제 생각으로는 너무나도 컸던 이슈 크기가 원인이지 않을까 합니다.

 

👇🏻 TIL에서도 언급했던 많은 세부사항을 포함하는 하나의 이슈

결국 하나의 이슈사항과 관련된 기능들을 완성하고 PR을 작성하기 전까지

팀원과 코드에 대한 이야기를 하나도 나누지 못한 상황이었고, 서로 완벽히 분리된 업무를 수행하게 되었습니다.🥶

 

👇🏻 하나의 PR에 엄청난 파일 변경 수

이 때문에 코드리뷰 자체에도 시간이 오래 걸릴 뿐만 아니라, 구현 사항에 대해 깊이 있는 이야기를 나누어보지 못했어요.

🌹 첫 주에 구현한 기능은 많았지만 PR은 하나밖에 없던 나란 개발자...

 

저희 팀은 이 문제를 다시 되풀이 하지 않기 위해 Issue와 PR에 대한 회의 시간을 가지게 되었고,

 

기능 단위로 세분화된 Issue와 PR 그리고 빠른 코드리뷰🔥

 

이 2가지 사항을 기반으로 빠른 템포의 개발을 진행하기 위해 노력하였습니다!👍🏻

 

👇🏻 하나의 화면에서도 각 기능별로 Issue를 구별하기

이렇게 만들어진 이슈들을 가지고 PR 단위를 정하고, 코드리뷰를 진행하니

이전보다 팀원과 코드에 대해 더 많은 이야기를 나눌 수 있었고, 그 덕분에 더욱 일관성 있으면서 의미있는 코드를 작성할 수 있었어요.📌

 

이뿐만 아니라, 기존의 저의 코드 스타일에서 잘못된 부분에 대해 수정할 기회도 가지게 되었답니다.🤗

대표적으로 저는 retrofit을 이용해 데이터를 받아오는 repository에서

suspend getData() = withContext(Dispatcher.IO) {
	val result = RetrofitApi.getData()
    
    /** */
}

위와 같이 withContext를 이용해 IO 스레드로 변경해주는 작업을 해주었는데,

팀원분이 조언해주길 해당 작업은 Retrofit 내에서 처리해주는 별도로 repository에서는 해줄 필요가 없다는 것을 알게 되었어요. (두둥!!)

 

🍿결론

🌹 이슈는 세분화해서 나누고, PR 크기를 적당히 나누면 코드리뷰를 하기 편하고 이는 코드를 이쁘게 만드는데 도움이 된다..

 

(2) 이슈 활용하기

저는 이번 개발을 진행할 때 사용한 기술들을 프로젝트에서 끝내지 않고 이후에 해당 기술에 대해 공부해볼 예정이었어요. 🤗

(앞으로 할 예정입니다..ㅎㅎ)

그래서 이슈별로 개발을 할 때 참고한 문서와 링크들을 정리해두기 위해 github issue의 comment를 사용하였습니다.😆

이렇게 정리해두었더니,

• 참고 문서의 위치를 찾는데도 쉽다.
• 어떤 기능을 구현하기 위해 찾아보았는지도 파악하기 쉽다.

이런 장점이 있었어요! 👏🏻👏🏻

🌹 이제 공부하는 것만 남았습니다.

 

(3) 커뮤니케이션

이전 프로젝트 회고록에서는 팀과의 실시간 소통을 위해 카카오톡을 활용했다는 말씀을 드렸었어요.

 

이번 프로젝트에서도 물론 slack을 이용해 소통을 하기도 하였지만, 그와 더불어 바로!

Gather Town 을 활용해보았습니다.

 

제안하고 싶은 아이디어가 있거나 회의가 필요할 때마다 게더에 모여 직접 이야기를 하면서 프로젝트에 필요한 안건을 정하였습니다.

 

(4) 페어 프로그래밍

이번 프로젝트에서는 하나의 페이지를 팀원과 함께 페어 프로그래밍으로 개발을 진행하였어요. 

사실 처음 해보는 페어 프로그래밍이었는데, 결과적으로 대만족이었어요. 😍

• 팀원과의 내적 친밀감(?)을 키울 수 있었습니다.
• 팅뭔의 개발 스타일을 직접 볼 수 있었고, 코드리뷰를 할 때 가장 많이 가지는 질문이 왜 이렇게 개발을 하였는가?인데 이걸 바로바로 물어보면서 개발을 할 수 있어서, 개인적인 개발 능력 향상에도 많은 도움이 되었어요. 🔥👍🏻
• 문제가 발생했을 때 함께 머리를 맞대고 고민을 할 수 있었던 점이 굉장히 좋았어요.

그러나 페어 프로그래밍을 바로 옆에서 할 수 있었다면 더욱 좋았겠지만...

환경상 그럴 수 없어 해결방법을 찾던중 사용한 것이 바로 Duckly라는 프로그램이었습니다!!

 

 📌 페어 프로그래밍에서 아쉬웠던 점

저희 팀은 프로젝트 막바지에 페어 프로그래밍을 진행하였어요.

지금와 생각해보니 프로젝트를 생성하는 시점부터 같이 , 어느 정도 틀이 잡힌 이후에 업무 분담하였다면 프로젝트 진행이 조금 더 원할해지지 않았을까 생각이 드네요.😭

 🌹 다음 프로젝트에서는 초반에 페어 프로그래밍을 해보자

 

3. 프로젝트를 끝내고...

사실 처음해보는 안드로이드 팀 프로젝트였지만, 프론트엔드와 크게 다르지는 않았어요,(eslint만 조금...)

🤗 다행히 요구사항에 포함된 기능을 전부 구현할 수 있었습니다.

 

역시 팀 프로젝트는 재미있어 😊😊😊

 

📌 협업의 측면

초반 협업은 제가 부족한 면이 있어, 제대로 이루어지지 않았다고 생각하지만 이런 점을 계속 고쳐나가려고 노력하여

팀원과 함께 성공적으로 프로젝트를 끝낼 수 있었다고 생각해요. 🤗

 

👇🏻 아래의 부분에 대해 다음 프로젝트에서 신경쓰면 더 좋을거 같아요.

• 적당한 크기의 Issue와 PR
• 처음 프로젝트를 시작할 때 페어 프로그래밍하기
• 마치 한 사람이 짠 코드인것처럼! 항상 생각하기

 

📌 기술적인 측면

이번 프로젝트에서 지금까지 사용해보지 않았던 점들을 많이 사용해볼 수 있었던 경험이었어요.

Paging3, spinner, ItemTouchHelper, Flow, Hilt 등등...

 

하지만 일정이 급해 이러한 기술에 대해 깊이 공부해보지 않고 사용방법만 보고 사용한 기술들이 많았습니다.

이 부분이 가장 아쉬웠던 점이었어요.😭

 

그러나.. 이 프로젝트가 끝난 다음주에 바로 새로운 프로젝트가 시작된다는 사실

주말 내에 최대한 공부해볼 예정입니다.🔥🔥

(홧팅..)

 

4. 앞으로..

프로젝트는 끝났디만 개발은 끝나지 않았습니다!!

 

🛠 ToDo

• Convention에 맞게 코드 리팩토링 하기
• 추가되었으면 하는 기능 추가하기
• 강사님의 코드 리뷰 정리하기
• 새로운 기술 내용 정리하기

 

5. 추가적으로

마스터 코드리뷰 적용사항

1. index 번호를 직접 사용할 경우에는 코드의 의미를 파악하기 어렵기 때문에 적절하게 사용하자
2. Naming을 보고 기능을 유추할 수 있도록 하자

---

벌써 우테캠의 반이 지나버렸어요. 저는 처음보다 조금은 나아진걸까요.ㅠㅠ

 

앞에서 말씀드렸던 기술부분을 정리해보러 가야겠네요.

홧팅!!