[부스트캠프 웹・모바일][회고] 그룹프로젝트 2주차

그룹프로젝트를 시작한지 2주가 지나갔습니다. 

 

블로그에는 올리는 것은 늦어졌지만, 기존에 기록해놓은 회고를 적으려고 합니다ㅎㅎ

 

저는 AAR방식의 회고를 사용할 예정입니다!

 

자! 그럼 회고를 시작하겠습니다.

 

 

회고

이번 주에는 기록화면의 비즈니스 로직을 제외한 모든 UI 컴포넌트를 작성하는 것
공통적으로 사용해야하는 라이브러리를 제작해 놓는 것
등 전반적인 개발에 있어서 기술적인 도전이나 해보지 못한것들을 해보기 위한 땅을 다지는것이 목표였습니다.

 

실제로는, 계획한 시간보다 생각보다 훨씬 오래걸렸고 계획을 모두 마무리하지 못하는 결과가 나타났습니다.

 

Modular 아키텍처에 관한 고민(Feature를 어떻게 나눌 것 인가)을 하였고,

 

그외 기술적 선택에 대한 토론 및 학습을 진행하였습니다.

 

부스트캠프 통틀어서 가장 많은 아키텍처관련 고민과 토론을 나눴던 시기였던것 같습니다.

 

간략하게 기록해보자면,

 

저희는 Modular 아키텍처와 Clean 아키텍처가 공생할 수 없는 하나의 아키텍처만 적용해야만 하는 것인줄 알았는데요.

 

더 자세히 공부하고 자주 토론하다보니 Modular아키텍처 내부에서 Feature별로 필요한 아키텍처를 사용하면 된다는 결론이 나왔습니다.

 

또한, Coordinator 관련해서도 저희 팀원분 중 한 분이 Ribs를 공부하고 오셔서 극한의 추상화(?)를 위해 Builder를 사용하자는 의견을 내주셨는데요.

 

저희 프로젝트에서 그렇게 복잡한 추상화는 필요하지 않을거라고 판단 + 현재 구현해야 할 기능들도 많아서 더 이상의 러닝커브 증가는 안된다고 판단해서 의견이 반려되었습니다.

 

계획대로 되지 않았던 이유는 두 가지 정도의 이유가 있는데요.

 

아무래도, 생각보다 함께 의논해야하는 것들이 많았기에 순수 개발시간이 상당히 부족했기 때문인것 같아요.

 

또한, 모든 팀원들이 알고 있는 지식이나 학습속도가 같지 않기 때문에 서로 알고있는 지식을 공유하다보니 계획을 타이트하게 세우게 되면 확실히 제한 시간내에 계획이 완성되지 않는것 같습니다.

 

팀원들과 함께 의논해야할 사항이 생기면 적극적으로 의논하는 것은 다 같이 지속적으로 지속해야할 부분이고,

 

계획을 타이트하게 작성하는것을 개선해야할 것 같습니다.

 

계획대로 되지않는 부분에 대해서 돌을 던질 사람은 없겠지만,,

 

계획을 완료하는 것으로 성취감을 얻으면서 진행해야 더 오래 지속가능할 것 같은데요.

 

계획에 맞추지 못하게 되면 상실감이 생기기 때문에 계획을 조금은 널널하게 잡는게 심리적으로 안정감을 느낄 수 있다는 것을 배웠습니다.

 

그래야 지속성도 올라가는것 같구요 😀