가이드라인

• 개인의 성장 목표, 기술적 고민거리와 트러블 슈팅 경험 등을 문서로 정리합니다.
• [피어세션]에서 받은 질문과 피드백을 정리하여 추가해두길 권장합니다.
• 상시로 진행한 개인 회고 결과가 있다면 해당 기록으로 갈음할 수 있습니다.

회고 내용

개인의 성장 목표

Task 매니징을 더 잘하자

• Task 매니징에서 생각보다 구멍이 많았음
• 기본적인 셋업이 되어있지 않은 상태에서 Feature 개발을 먼저 나가려고 했던 것이 크나큰 실수

커뮤니케이션을 더 잘하자

• 페어 프로그래밍을 진행하며 혼자 너무 조급해하는 것 같음
• 마음의 여유를 갖고 진행하자

사용하기 쉬운 코드를 만들자

• 공통 요소를 만들면서 팀원에게 편안함을 주고 싶음
• 이거 어떻게 써요?, 이거 이렇게 하는 거 맞나요? 라는 질문 없이 사용할 수 있도록 만들기

기술적 고민거리, 트러블 슈팅 경험

아키텍처 설정

• RIBs와 클린 아키텍처를 선택했는데 Feature 단위로 모듈화를 하여 Domain/Data/Presentation 를 쪼개려고 했음
• 생각보다 많은 모듈이 생기게 되었음 -> 인터페이스와 구현체 모듈까지 생각하면 매우 많아짐
• 해당 아키텍처를 선택하면 훨씬 확장성 있는 구조를 구현할 수 있을거라고 생각하지만 반대로 너무 복잡하여 실수할 부분이 많다고 생각
• 최대한 Domain/Data 구조를 단순화 시키고 Presentation만 여러 모듈을 추가하는 구조로 변경하였음
• 이로 인해 확장성은 떨어지나 복잡도가 많이 줄어 러닝 커브가 낮아졌음

변경전(이미지에 보이는 것들이 Feature 모듈 추가마다 늘어남)	변경후(Presentation 모듈만 추가하면 되므로 노란색 부분만 늘어남)

Tuist 활용하기

• 위에서 언급한 모듈화(아키텍처)가 러닝 커브가 낮아졌지만 그래도 어려웠음
• 단순히 코드와 말로 설명하고 시각적으로 보여줄 때 매번 피그마로 그리는 것이 현실적으로 불가능
• Tuist의 의존성 그래프를 통해 해결하였음

직접 그리기	Tuist graph

코드 스타일 맞추기

• 꽤 어려웠음
• private extension vs. private func 등 사소한 부분까지 맞추기 어려웠음
• 처음에는 왜 이렇게 사용하는지 등에 대한 언급을 했으나 스타일적인 부분이다보니 각자의 장단이 있어서 더욱 선택하기 어려웠음
• 그래서 개인적으로 합당한 이유라면 내키지 않아도 하려고 생각함 (어차피 스타일적인 부분이니)
• 1주차는 페어 프로그래밍을 통해 서로의 스타일을 맞추는 기간으로 진행했음
  • 페어 하기를 잘했다고 생각함
  • 안그랬으면 PR에서 토론의 장이 열렸을 것 같아서 오히려 그 상황에서 드는 리소스가 더 클 것이라 생각

개발 참고 자료

• MVVM + Clean Architecture
• 민소네님 RIBs+Clean Architecture