미니 프로젝트 회고

1. 미니 프로젝트를 마치며

월요일부터 시작된 미니 프로젝트가 끝났다!..

월요일 오후부터 오늘 오전까지 4일이라는 짧은 시간 안에서 결과물을 만들어냈다는 것이

다 끝나고 보니 대단하다는 생각 👏👏

특히 우리 팀은 나를 제외하고 이런 개발 프로젝트가 처음인 분들이 대부분이었는데,

끝까지 포기하지 않고 깃허브로 협업도 착착 해낸 것이 뿌듯하다 😊

발표 후 튜터님들의 피드백을 바탕으로 결과물에서 좋았던 부분과 아쉬웠던 부분, 개선되었음 하는 부분을 따로 정리해보려 한다!

 

 

2. 아쉬웠던 부분

2.1. 다크 모드 적용 디테일

담당 파트는 아니었지만, 개인 페이지에서 다크 모드 적용 시에 입력창과 방명록 부분도 변화가 있었어야 했는데

챙기지 못해 사용성 부분에서 아쉽다!

 

 

웨일 브라우저의 경우, 다크모드에서 아래와 같이 입력창을 포함한 모든 부분에 대해서 다크 모드가 적용되어 있었다.

다른 케이스를 먼저 알아보지 못한 것이 아쉬움 🥺..

웨일 브라우저 다크모드

 

2.2. 에러 처리, 유효성 검사

개인 프로젝트에서 유효성 검사를 그렇게 처리했음에도 불구하고....

정작 팀 프로젝트에서 까먹다니 😂 !....

다음 프로젝트부터는 절대 잊지 않고 챙겨야지

 

 

2.3. 다크 모드 유지

페이지 이동시 다크 모드가 유지되지 않는 점!..

이 부분에 대해서는 사실 고민했었는데 고민만 하고 시도를 못해봐서 매우 아쉽다.

 

튜터님이 현업에서는 보통 로컬이나 세션 스토리지에 변수를 적용해서 다크 모드를 유지한다고 말씀해주셨고,

추가적으로 OS별, 사용자별로 기본적으로 적용되어있는 모드(다크나 라이트)에 따라

바로 해당 모드로 보여주는 것도 좋다는 피드백을 주셨다.

 

다크모드 버튼을 클릭했을 때 로컬 스토리지에 저장해서,

페이지 이동시에 로컬 스토리지에 저장된 부분을 가져와서 일치하면 다크 모드로 유지해주는 식의 로직을 쓰면 될 것 같다는 생각.

 

 

2.4. 웹 표준 못 챙김...😂

이건 개인적으로 정말 정말 아쉬운 부분인데,

개인 페이지 구조 짜는 걸 나누어서 진행했고 한 번쯤은 마지막에 갈무리하고 싶었지만.. 🥹

또 여건이 되지 않아 구조적인 부분에서 웹 표준을 챙기지 못했다..!

이 부분은 팀원들에게도 따로 전달할 계획이다. 🙂 같이 알면 좋으니까,,

 

 

3. 좋았던 부분

3.1. Restful 하게 작성한 API 네이밍

API 라우트 연결하고 작명하는 것 또한 의도치 않게 내가 챙기고 말았는데.. (라우팅에 성공한 사람이었기 때문)

API 네이밍은 꼭 Restful 함을 챙기고 싶었다.

 

방명록은 서버가 관리하는 컬렉션이었기 때문에 members와 board라는 명사들을 사용해서

멤버별로 숫자를 카운팅 해서 만들었다.

튜터님도 이 부분을 칭찬해주셔서 좋았다. 🙌

 

REST API 네이밍 가이드

https://restfulapi.net/resource-naming/

REST Resource Naming Guide

 

 

3.2. 깃 충돌이 거의 없었다

어제 하루 만에 발생한 PR만 해도 여러 건인데 슬랙에서 실시간으로 서로 PR 보냈다, merge 끝났다, pull 해주세요 등등

바로바로 소통을 해가며 진행해서인지 충돌이라던가 꼬임이 정말 없었다!..

우리 모두 PR은 처음이었는데 아주 놀라운 부분.. 👏👏

 

 

3.3. 협업적인 측면

우선 피그 잼을 처음 써봤는데 아주 좋은 협업 툴이었다.

특히 다 같이 아이디어 회의를 하기 적합한 툴!.. (그러는 용도지만)

 

다음 프로젝트 때는 아이디어 회의는 피그잼에서,

정리와 진행사항 관리는 노션에서 하면 더 좋겠다는 생각 🙂 !.. (노션 좋아)

피그잼 덕분에 각자 작업한 개인 페이지를 합치는 부분도 서로 좋았던 부분에 스티커를 붙이며 평화롭게 진행할 수 있었다.

아쉬운 부분이 있다면 코딩 컨벤션이나 커밋 컨벤션을 세부적으로 정하고 했음 더 좋았겠다 싶다.

 

다음 프로젝트에서 시도해볼 부분이 많은 듯.. 🤔

 

 

4. 👀 KPT 회고 방법론에 따른 이번 프로젝트 개인 회고

4.1. Keep

• 기획 단계에서 피그마의 피그잼을 사용해서 자유롭게 의견을 주고 받은 것
• 어려워했던 부분에 대해서 끝까지 시도해서 해결하고 성공한 것
• 적극적으로 소통하려 했던 것
• 깃허브를 이용하며 실시간 소통하며 진행하여 충돌 없이 합쳐나간 것

 

4.2. Problem

문제점

• 기획 단계에서 좀 더 상세한 기획이 이루어지지 못한 것 (기능이나 페이지 구성, 파트 분배 같은 부분)
• 계획을 조금 느슨하게 잡아서 후반부 마무리 시간이 촉박했던 점
• 코드 컨벤션을 상세히 정하지 않아 합치는 과정에서 추가적인 시간이 소모됨

원인

• 협업 프로젝트 경험 부족

해결방안

• 프로젝트를 시작하며 기획 단계에서 시간을 너무 짧지 않게 잡으며 넣을 수 있는 기능에 대해 다양하게 생각해보기
• 중간 마감을 포함해서 정기적으로 개인 진행사항과 프로젝트의 현재 진행 방향에 대한 논의 시간을 가지기
• 기획 단계에서 코드 컨벤션과 커밋 컨벤션을 정하기

 

4.3. Try

• 코드 컨벤션과 커밋 컨벤션에 대해 알아보기
• 프로젝트 시작과 진행사항을 노션으로 정리하고 공유하기
• 기획 단계에서 개인 파트 분배를 명확하게 하기
• 깃허브와 브랜치에 대해 더 공부하기

 

 

 

일차적으로 이렇게 정리해본다.

짧은 프로젝트였지만 처음 보는 사람들끼리 이런 결과를 만들어냈다는 부분에서 놀랍고!..

짧고 굵게 성장한 느낌이다! 🙂