기동 2팀 - 리액트리 회고

KEEP(현재 만족하고 있는 부분, 계속해서 이어나갔으면 하는 부분)

기획 측면

• 구체적인 서비스 타겟층을 선정한 점

• 포인트 컬러 사용을 통해 사용자 행동을 유도할 수 있다는 점을 깨달음

협업 측면

• 프로젝트 시작 전 코드 포매팅, 깃 컨벤션, PR 규칙, 이슈 생성 관련 규칙들을 모든 팀원의 동의 하에 꼼꼼하게 정했고, 이를 잘 지키며 프로젝트를 진행했다는 점
• 브랜치 병합 시에 꼼꼼한 코드 포매팅 합의 덕분에 일관적인 코드 스타일을 유지할 수 있었다
• 이슈 기반 개발 방식을 이용한 덕분에 깃 프로젝트를 통해 팀원들이 어떤 기능을 구현하고 있는지 진행 상황을 한눈에 파악할 수 있었다
• 각자의 개발 영역을 잘 분리한 덕분에, 병합 시 컨플릭트를 줄일 수 있었다
• 피드백 요청, 논의가 필요한 내용들은 따로 라벨을 달았고, 즉시 디스코드를 통해 논의했으며 코드 리뷰 또한 24시간 내에 진행했다
• 첫 프로젝트였지만 뭔가 정돈된 느낌을 받을 수 있었고, 협업 시 개발 방식을 배울 수 있었다

• 팀원들과의 지속적인 소통을 통해 같이 나아가고있다는 분위기를 형성했다는 점
• 프로젝트 기획 기간 중 주제나 요구 사항 등을 정할 때 각자가 추구하는 방향, 의견 등을 들어보고 공통점을 찾아내려 노력했다
• 팀원들과 소통을 하면서 왜 좋은지, 얼마나 좋은지 직접 경험해보았고, 원인을 파악하고 문제를 해결하는 시간을 줄일 수 있었다고 생각했다
• 작은 문제라도 같이 고민했고, 같이 해결해나갔으며, 누가 먼저랄 것도 없이 서로의 의견을 물었다 이러한 분위기가 형성되니 다른 의견이라도 거리낌 없이 제안할 수 있었고, 의견에 조언들이 더해져 더 좋은 결론을 낼 수 있었다 또한, 문제상황에 마주했을 때 팀원들과의 자유로운 의견 교환을 통해 해결책을 더 빠르게 찾을 수 있었다
• 내가 개발하지 않은 부분 이더라도 개발 상황과 문제를 공유하며 마치 함께 개발한 것과 같은 간접 체험도 경험할 수 있었다

시간 관리 측면

• 2주라는 짧은 시간이 정해져있고 결과를 내야하는 프로젝트인 만큼 어떤 일이든 데드라인을 촘촘히 정해놓고 그 시간 안에 끝내려 노력했다는 점
• 짧은 시간 안에 나의 역량을 쏟아붓기위해 '할 수 있을까?'라는 생각보다는 '시간 정했지 그럼 그때까지 해내야지' 이런 마인드를 기르려 노력했고, 내가 해낼 수 있다고 생각하는 시간보다 더 타이트하게 데드라인을 정했다
• 물론 지키지 못하는 경우도 있었지만, 시간을 정해놓으니 좀 더 빠른 시간 안에 할 일들을 끝낼 수 있었고, 잠을 줄여서라도 해내기 위해 노력했다
• 덕분에 프로젝트 초반에 생각했던 기능들을 90%이상은 구현해낼 수 있었다

PROBLEM(개선이 필요하다고 생각하는 부분, 잠재적인 문제)

기획 측면

• 디자인 시스템의 사용법 미숙
• 와이어프레임 제작과 디자인 작업이 분리되어 진행되지 못하였다는 점
• 컴포넌트 구성에 대한 사전협의가 부족했다는 점
• 만약 와이어 프레임 작성 작업을 통해 컴포넌트를 분류하고, 컴포넌트 종류별로 등장할 변화들의 속성을 미리 정의해 둔 다음 디자인을 진행했다면, 디자인 기획이 도중에 크게 변경될 가능성을 방지하여 기능 개발에 좀 더 몰두할 수 있었을 거란 아쉬움이 있다

• 반응형에 대한 충분한 고려가 이루어지지 않았다는 점
• 웹 화면만 고려하고 모바일 화면 구성은 진지하게 고민하지 않았다 단순히 화면을 줄이면 된다고 생각했기 때문이다 안일한 반응성 전략으로 인해 결국 결과물에서 반응형 화면은 우선순위 최후미로 밀려났고, 최종 결과물에서 일관된 반응성을 적용하지 못했다

개발 측면

• 코드의 질보다 구현에만 집중을 했다는 점
• 이 부분은 지난 과제들을 하면서도 느꼈지만 코드의 깔끔함, 효율성, 왜 이 코드가 여기에 들어가야하는가에 집중하지 못했다는 점이 매우 아쉽다
• 아무래도 시간이 정해져있다보니 '일단 구현하고, 나중에 고치자'는 생각이 머릿속을 사로잡았고, 이런 방식으로 코딩을 하다보니 언제 오류가 나도, 언제 무너져도 이상하지않을 코드가 완성됐다
• 또한, 각 페이지 별로 중복되는 코드가 많이 발견됐다 컴포넌트를 잘 나누지 못했을 수도 있고, 내가 방향을 잘못 잡았을 수도 있다...
• validation 측면에서도 고려하지못한 부분이 많아 대대적인 리팩토링이 필요할 것 같다

• 시간이 부족하다는 이유로 기술 적용을 미룬 점
• Context API와 웹팩 alias 절대경로 설정을 빡빡한 개발 일정을 핑계로 미뤘다
• 대표 색상이 기획 단에서 변경된 까닭에, 색상 상수화 작업을 미뤘다
• 당시에는 개발을 완료하고 나중에 일괄적으로 적용하면 된다고 안일하게 생각했다 하지만 프로젝트가 끝나고 나니 수정해야 할 코드가 산더미가 되어버렸다

기록 측면

• 매일 매일 생기는 이슈들이나 생각들을 자세히 기록하지못했다는 점
• 깃 프로젝트로 진행 상황이 공유되다보니 프로젝트 중반부까지는 회의록 정도만 기록을 해왔었다 하지만 생각해보니 기획하다가 부딪힌 어려움 또는 각자 개발하다가 해결한 크고 작은 에러나 배운점들을 프로젝트 초반부터 기록했다면 좋았을 걸 하는 아쉬움이 든다
• 프로젝트를 하다보면 매일 매일 배운점이 생기고 그날 해결하지 못한 에러들도 생긴다 이런 이슈들을 해결해 나간 과정이나 내가 실수했던 부분들을 적어 놓는다면 나중에 나만의 오답노트가 될 수 있을거라 생각한다

TRY(Problem에 대한 해결책)

기획 측면

• 다음 프로젝트에서는 와이어프레임과 디자인 작업을 분리하여 진행하여, 개발 도중 기획이 크게 변경되지 않도록 조치하기

• 와이어프레임 작성 과정에서 반응형 화면도 준비하기

개발 측면

• 코드의 질보다는 구현에만 집중을 한 것에 대한 해결책
• 현재 프로젝트 관련
• 코드를 찬찬히 들여다보며 리팩토링해야 할 부분을 적고, 이틀에 1개씩은 꼭 해결하자 (최종 프로젝트 시작 전까지)
• 이해가 잘 되지않았는데 코드를 작성했던 부분은 다시 공부하고 완벽히 이해한 후 코드 작성하기
• 최종 프로젝트 관련
• 코드의 질 60% 구현 40% 유지하면서 코딩하기 시간만 있다면 구현은 다 가능이기때문에 구현보다는 코드의 질에 조금 더 집중해보자 (팀원들과의 협의하에 진행)
• 왜 이 코드를 써야했는지 끊임없이 질문을 던지고 답해보기 답을 할 수 없다면 나의 코드가 아니라는 마음가짐으로 공부하고 다시 코딩 계속 반복

• 시간이 부족하다는 이유로 기술 적용을 미룬 점에 대한 해결책
• 상태 관리 라이브러리가 필요하다고 생각하면 바로 도입해보기
• 추후 불필요한 로드가 발생하지 않도록 공통 설정을 미루지 않기
• Eslint + prettier + husky까지 적용해 보기

기록 측면

• 매일 매일 생기는 이슈들이나 생각들을 자세히 기록하지못했다는 점에 대한 해결책
• 팀원들과 매일 TWL(Today We Learned) 작성하기
• 간단하게라도 적어보고 한 15분 정도 공유하는 시간 가지기
• 공유를 한다면 동일한 문제에 부딪혔을 때 쉽게 해결이 가능할 것이고, 풀리지 않았던 문제 역시 이야기를 나누며 같이 풀어나갈 수 있을 것
• 회의록 정리 관련
• 이번 프로젝트의 경우 팀원 중 한 분이 도맡아서 회의록을 정리해주셨는데, 다음 프로젝트 때는 로테이션으로 돌아가면 좋을 것 같다
• 돌아가면서 진행하면 회의 내용도 한번 더 짚어볼 수 있고, 함께 진행한 회의인 만큼 모두의 노력이 차곡차곡 쌓이면 더 좋지 않을까 싶다