[K015] 박진성

✅ Week1

진행 상황

-> 처음 팀원들과 손발을 맞추며, 기획 단계를 진행하였다

• 아이디어 빌딩
• 기획 상세 논의
• FlowChart 작성
• 와이어프레임 작성 (Figma)
• FeatureList 작성
• BackLog 작성
• Design 작성

-> 팀 그라운드 룰과, GitHub 협업 규칙을 긴밀하게 논의하였다

• 오프라인 미팅 정하기
• 지각 / 소통 / 정리 / 스크럼 마스터 / 회의록 서기 규칙 정하기

느낀점 & 개선사항

첫 기획단계에서 생각보다 많은 시간을 할애하게 되었다. 능숙하지 못한 Figma 로 와이어프레임 과 디자인 작업을 해야 했고, 작성해야 할 문서 양이 방대하였다. 원래 간단히 앱 Flow 나 할일 목록을 적은뒤 개발을 시작하곤 하였던 터라, "너무 기획에 시간을 많이 쏟는게 아닐까?" 라는 생각을 잠시 하였다. 하지만 BackLog 까지 작성을 마치고 나니, 총 6주간의 프로젝트 흐름이 한눈에 그려졌다. 또한 6주동안의 계획을, MVP 모델과 FINAL 모델로 나누어, 1차 목표 2차목표를 분리할 수 있었다. 앞으로 개발을 시작하게 되면, 차츰 더 깨닳아 나가겠지만, 기획 문서 작성에 시간투자를 많이할 수록, 개발을 할때 수월하겠다 라는 생각이 들었다.

다음 주차 목표

이제 본격적으로 개발을 시작하는 주차가 될 듯 한데, 팀원들과 어떤식으로 손발을 맞추게 될지 상당히 기대가 된다. 분업보다는 협업을 경험하라는 말씀을 많이들 해주셨는데, 핵심 비즈니스 로직은 최대한 협업 페어 프로그래밍 방식으로 진행을 하고, 나머지는 분업도 진행 하면서 개발을 이어나가고 싶다. 또한 이번 프로젝트 개발에서는, 반드시 구현에 급급하지 않고, 하나라도 더 배워간다 라는 마음가짐으로, 여러가지를 시도해 보고 싶다. 여러가지 에러에 부딪히면서 성장하고 싶다.

✅ Week2

진행 상황

-> 개발에 착수하여, 분업과 협업(페어프로그래밍) 을 병행하며 진행하였다

• 프로젝트 Setting
• 상세 회원가입 페이지 레이아웃
• 상세 회원가입 페이지 로직 & API 연결(완료 전)
• 홈 NaverMap Setting, 위치 Tracking 로직 구현

느낀점 & 개선사항

우리 팀은, upstream remote 를 origin remote 로 fork 해서, 분업하는 방식으로 진행하고 있다. 
해당 과정을 멤버십 첫주차 때부터 해왔지만, 협업으로 진행하니 어려움이 많았다.

페어프로그래밍 으로 upstream 에 merge 한 셋팅 코드를, 내 로컬에 받아서 합친 후 작업을 이어나가야 할 상황이었는데, 
rebase 로 진행하였더니, 각 commit 마다 conflict 를 해결해야 하는 상황이 발생 하였다. 
또한 conflict 마다 commit 메세지 수정 여부를 물어봤었는데, 나는 모든 커밋 위에 새로운 rebase commit 이 쌓이는 줄 알고, 모든 commit 메세지를 수정하였다.
하지만 내가 작업했던 commit message가 "merge conflict 해결" 이라는 메세지로 바뀌게 되었다.

1. rebase 의 단점을 몸소 체험하게 되어 좋은 경험이었다
2. 로컬에서 작업하다가, remote의 코드를 합쳐야 될때는 merge를 쓰는게 좋을 것 같다

네이버 지도 현위치 tracking 로직을 구현하였는데, 생각보다 권한, GPS 확인 Flow가 길어서, Fragment 의 코드량이 많아졌다
권한체크, GPS 켜져있는지 확인 등 Fragment 나 Activity 의 override 함수를 통해 진행해야 되는 로직들은, 
어떤식으로 코드를 분리해야 스파게티 코드를 방지할 수 있을지 고민이 된다..

1. 권한 체크 로직을 class 화 할 순 없을까?
2. NaverMap 관련 로직 또한 class 화 할 순 없을까?

다음주차 목표

다음주차땐, 홈 지도쪽을 거의 끝낼 것 같은데, 건강한 페어 프로그래밍을 통하여 최선의 산출물을 내는 것이 목표이다!