💡 개인 회고
기홍
- 이전까지 혼자 코드를 작성했을때는 규칙에 대해서 크게 신경을 쓰지 않았는데 eslint, prettier같은 규칙을 정해서 사용할 기회가 생겨서 좋았습니다.
- 기존에 사용해봤던 commit, push 외의 git의 다양한 기능을 활용할 기회가 생겨서 좋았습니다.
- gitHub를 사용함에 있어서 충돌에 대한 두려운 마음이 있었는데 충돌을 겪고 해결하는 과정에서 두려움이 사라지게 되었습니다.
소진
- git을 혼자서 사용할때는 branch와 같은 기능을 써보기가 어려웠는데 많은 기능을 하용할 수 있었어서 좋았습니다
- 팀원들 간에 미리 충돌을 방지하기 위한 계획을 세워놓아 큰 어려움이 없었던 부분이 만족스러웠습니다.
신영
- 이전 협업 과정에서 팀원들 간의 합의된 규칙이 거의 없었고, 코드를 어떻게 작성할지에 관한 생각 없이 기능 구현에만 힘썼던 경험이 있었는데, 이번 프로젝트를 진행하며 코드를 작성할때 생각을 많이 해보는 기회를 가지게 되었습니다.
- PR과 merge 과정에서 커뮤니케이션이 있던 점이 좋았습니다.
- 추후 각자 페이지를 작업하고 merge를 한 후 작업한 페이지를 넘어가며 동작을 시켜봤을때 잘못된 값이 넘어갈까 우려가 됩니다.
윤정
- git 관련해서 단순하게 내가 작업한 작업물을 올려놓는 저장소라고만 생각을 했었는데 공부를 하고 사용을 해보니 개발을 하는 과정에서 많은 편의성을 제공한다는 것을 느꼈습니다. git의 필요성을 느끼게 된 계기가 되었습니다.
- 팀원들 간에 규칙을 정하고 코드를 작성하니 서로의 코드를 이해하기 훨씬 수월했습니다.
💡 어려웠던 점
1. 아이디어 선정
- API와 요구사항이 나오지 않은 상태에서 아이디어 선정을 진행해야 해서 그 부분이 아쉬웠습니다.
- 좋았던 아이디어를 주어진 API에 맞춰가며 어떻게 사용할지 결론을 내지 못해 포기하게 되어서 아쉬웠습니다.
2. 기본 컴포넌트 재사용 관련
- 사전에 충분한 논의 없이 기본 컴포넌트를 한 사람이 만들다 보니 다른 사람이 코드 작성시 컴포넌트의 기능과 속성에 대한 이해가 부족해서 사용을 비효율적으로 한 것 같습니다.
- 기본 컴포넌트 관련해서 다른 코드들을 많이 참고해봐야겠다는 생각이 들었습니다.
- 팀 내부에서 기본 컴포넌트를 어떤 부분에 사용 할 것이고 어떤 기능과 변경이 있는지 내부에서 충분한 논의가 필요할 것이라는 생각이 들었습니다.
- 추후 리팩토링 과정에서 재사용을 효율적으로 하는 방안을 검토할 계획입니다.
3. 스토리북 사용 관련
- 스토리북 사용을 결정했지만 모든 컴포넌트나 페이지에 대해 스토리북 작성을 하지 못해서 아쉬웠습니다.
- 컴포넌트 조합을 페이지 별로 해보라는 멘토님의 조언을 시간 문제로 수행하지 못해 아쉬웠습니다.
멘토님께 질문 사항
서버가 다운되어서 개발 일정이 늦춰지고 있습니다. 잘못된 요청 값을 보냈기 때문인 것으로 추측합니다. 클라이언트가 요청을 잘못 보내면 서버가 다운되는 일이, 실무에서도 자주 일어나는지 궁금합니다.
현재 스토리북을 사용하고 있는데, 기본컴포넌트와 데이터가 많은 컴포넌트만 UI확인차 만들었습니다.
포트폴리오에 스토리북 사용한 내용을 어필하고 싶은데 이정도로는 부족할까요?