🍉 First Project 최종 배포링크
배포링크 : https://cafe.beanus.tk/
🍉 회고
1. 팀 협력
😉 over communication은 좋다.
NaNMerge팀에서는 오전 9시와 오후 5시 하루 2번의 공식적인 회의를 진행한다. 회의시간에는 Merge를 진행하고 Merge하는 동안에는 코드 작성을 금지하는 팀룰도 있었다.
이러한 덕분인지 2주동안 프로젝트를 진행하면서 Merge과정에서 크리티컬한 이슈없이 진행할 수 있었고, Merge 과정에서 conflict이 발생하더라도 모든 팀원이 모여있기 때문에, 각각의 개발자가 의도한 코드를 빠르게 파악할 수 있었다.
🥲 100% 확신을 견제하자
기술적인 이슈에 대한 이견이 생길 때에는 우리가 아는 것에 대해 100% 확신을 가지는 것을 주의해야한다. 실제로, status code를 어떻게 정할지에 대해 이야기하던 도중, 한 팀원이 400번대의 response를 보내면 응답을 받는 클라이언트에서 해당 status code와 body를 객체로 받을 수 없다는 의견을 강하게 어필한 적이 있었다.
하지만 찾아본 결과 axios에서 error에 대해 error.response로 받을 수 있다는 것을 구글링을 통해 발견하게 되었다. 만약 모두가 어떠한 의심없이 넘어갔었다면 비효율적인 코드작성과 잘못된 결정으로 이어졌을 수도 있겠다는 생각이 들었다.
이렇듯 내가 아는 것, 그리고 팀원이 아는 것에 대해 100% 믿음과 확신을 가지고 접근하는 것을 견제해야한다.
2. 코드 작성
🥺 styled component 모듈화
react는 컴포넌트를 통한 모듈화를 통해 중복코드를 제거하고 효율적이고 일관된 코드를 작성할 수 있다는 장점을 가진다. 이 때문에 styled component의 모듈화를 통한 재사용성은 잘게 쪼개진 컴포넌트에 css를 적용하기에 적합하다고 생각하여 styled component를 사용하게 되었다.
하지만 정확한 디자인이 정해져있지 않아서였는지, steyld component의 기능에 대해 잘 모르고 있어서였는지, styled component를 통해 반복해서 적용할 수 있는 부분들이 많았음에도 효율적이지 못한 코드를 작성한 것 같아 아쉽다.
다음 프로젝트에서는 초기에 전체적인 프레임을 정하고, 재활용할 수 있는 styled component를 구축 해야할 것 같다.
🤔 기능을 구현할 때에는 다양한 케이스를 고려해야한다.
게시물 수정 삭제, 댓글 수정 삭제와 같은 경우 userId와 loginId가 같으면 ui상에 보이도록 하였다.
하지만 내가 생각하지 못했던 부분이 있었다.
웹 회원인 test1가 회원탈퇴를 하였을 때, 현재 로직에서는 test1이라는 아이디를 사용할 수 있게 된다. 그렇게 되면 구test1 회원이 쓴 게시물과 댓글을 현 test1이 수정 삭제가 가능해진다.
이를 방지하기 위해서는 userId와 loginId로 수정 삭제 가능을 판별하는 것이 아니라 고유한 값인 테이블 id를 사용하거나, 회원탈퇴를 따로 관리하는 것이 필요한 것같다.
🍉 KTP First Project
Keep (유지할 항목)
- 이슈 사항 발생 시 모두에게 공유하여 빠른 해결을 도모하고, 코드의 conflict을 최소화한 것이다. 본인이 작성한 코드가 다른 개발자의 코드에 영향을 미치는 것이 있다면 메신저로 빠르게 공유하여, 다음 merge에서 conflict 발생을 최소화할 수 있었다.
- 상황에 따라 merge 순서를 정하는 것이다. merge를 하다보면 수정한 코드임에도 merge 과정에서 reset되는 경우가 발생했다. 때문에 동일 파일에서 작업을 한 경우 등등 상황에 따라 merge 순서를 결정하는 것 또한 좋았던 것 같다.
- merge할 때, 팀원 모두가 모여서 진행하는 것이다. 모든 팀원이 모여 merge를 진행하다보니 각각의 개발자가 의도한 코드를 빠르게 파악할 수 있었고, merge 이후 발생하는 conflict도 큰 이슈없이 해결할 수 있었다.
- 시간에 대한 약속이다. 공식 회의 시간은 오전 9시, 오후 5시로 하루에 2번 회의시간을 가진다. 다행히 팀원 모두가 회의시간을 준수한 덕분에 회의를 원활히 진행할 수 있었다.
Problem (문제라고 생각하는 항목)
- 전체적인 UI를 기획하고 코드를 작성하는 것이 필요한 것 같다. first project에서는 전체적인 UI를 확실히 기획하고 진행하지 않았다. 그 결과 페이지별로 각 개발자의 디자인 스타일이 반영되어 있어, 디자인의 통일감이 떨어진다는 아쉬움이 남는다.
- 사용 스택의 장점을 활용할 수 있는 코드 작성이 필요하다. 예를 들면, 공통으로 사용되는 styled component를 생성하여 코드 작성의 효율성을 높이는 것이다.
- 1차 기능 구현 완성기간과 최종 마감기간 사이에 넉넉한 시간을 두는 것이 필요한 것 같다. 1차 기능구현 완성에서 생각보다 많은 에러를 발견했고, 발표를 준비하는 과정에서도 아쉬운 점들이 발견되기도 했다. 다음에는 1차 기능구현과 마감기간 사이의 시간을 넉넉하게 두어 에러사항을 면밀히 살펴볼 수 있는 시간이 있으면 좋을 것 같다.
- 서비스가 실제 런칭된다는 가정과 함께 세세한 부분을 고려할 필요도 있는 것 같다. 예를 들면, 네트워크 환경이 좋지 않은 지역에서 우리의 서비스를 이용한다면? 게시글 작성, 게시 도중에 서버에 문제가 생긴다면? 등등 실제 발생할 수 있는 부분들을 체크할 필요가 있다.
- try catch와 같은 에러 핸들링을 제대로 이행하지 못했다. 요청에 대해 pending이 되는 경우 혹은 500번대 status code를 받으면 어떻게 핸들링 할 것인지 등 에러 핸들링을 소홀히 했었던 것 같다. 즉, 완성도가 떨어지는 것이다.
Try (Action Items)
[ ] 2주차 프로젝트 기능 구현 점검 및 회고
[ ] 4주차 프로젝트 주제 고민
[ ] 4주차 프로젝트 스택 학습(redux, redux-persist 등)
