기여도
- 게시물 조회 페이지의 markup, CSS, CRUD 구현
좋았던 점
redux-toolkit 적용
redux만 배웠었고, 실제로 개인 프로젝트에서도 적용해보질 못했는데 한단계 더 나아가 toolkit을 적용했다. 배우는 시간이 오래 걸렸지만 확실히 props로 내려주는것보다 한번에 뽑아 쓸수 있었다. 그리고 할 수 있을지 몰랐는데 해내서 뿌듯했다.
Github의 다양한 활용: issue, milestones, Kanban
혼자 할때는 클론이나 포크정도만 사용했는데 pull requests와 branch 병합, 생성 등 다양하게 연습할 수있어서 좋았다.
게다가 이슈, 마일스톤, 칸반을 어떻게 사용할 수 있는지 알아본 과정이어서 보람찬 과정이었다.
이슈 : 아쉬운 점
redux-toolkit의 slice 적용 범위에 대한 혼란
- redux-toolkit의 slice 사용범위와 useState, props 병행여부
처음에는 useState와 props를 병행하지 않고 전부 store에서 관리하려고 했었다. 그래야되는 줄 알았다. 하지만 불필요하게 작은 슬라이스가 많이 생기는 것 같고, DB 응답 개수를 알 수 없을 때 slice로 대응이 어려울 것 같았다. 게다가 재사용하는 컴포넌트에 slice를 적용했더니 모든 재활용 컴포넌트에서 열고 닫히는 현상이 발생해서 props코멘트 토글 부분에 slice를 어떻게 사용해야하는지 몰라서 useState와 props로 데이터를 내려줬다. 다른 팀의 코드를 분석해봐야겠다.
배포를 과연 이해했나?
- path 부분
- build 전 해야하는 작업
시간이 부족해서 최적화 과정을 다루지 못햇고, webpack 설정 없이 npm run build만 적용했다. 구글링으로 build 하기 전에 환경변수 작업을 먼저 해야한다고 봤는데 우리는 그 과정이 없이 배포가 되었다....?? (백엔드, 프론트 하나의 서버에서 배포) 하나의 서버에서 localhost로 인식하고 port만 다르게 적용된거인가 아직 잘 모르겠다.
구현할 화면구조 분석(반응형 고려안함), 구현할 기능의 우선순위 부재
- 반응형을 고려하지 않은 마크업 구조 설계
- 여러 CRUD 중 우선 순위를 정하지 않고 작업
임의로 2 덩어리의 컴포넌트로 분리했는데 추가 버튼의 위치 때문에 작업하면서 마크업도 수정하게되었다. flex를 적용했을때 제목과 버튼의 상호작용이 필요해서 변경하고, 다른 flex작업을 하다보니 또 수정했다. 수정은 당연하지만 이런 걸 화면 기획할 때 더 빨리 캐치했다면 좋았을 것 같다.
그리고 실제 스택오버플로우에 많은 기능 중에서 추렸다고 생각했는데 막상 작업을 하다보니 세세하게 기능이 추가되는 것 같았다. 예를 들면, 답변 수정 이 버튼하나에 서버 요청만 적용하면 될 줄알았는데 일차적으로 어디에서 수정하는지가 정해지지 않았다. 임의로 div 를 input 으로 바꿔서 store에서 값을 적용하고, 요청 후 성공하면 입력값을 초기화 하고 화면을 바꾼다던지 작업하면서 계획을했다.코멘트 추가 구현 도 실제로 보면 Add a comment 버튼을 누르면 숨겨진 입력창과 버튼이 나와야하고 리스트 추가를 위한 서버 요청이 필요하고, 요청 후 렌더링을 위해 상태 갱신 작업이 필요하다. 점점 기능을 추가하다보니 북마크나 좋아요 부분까지 끝내질 못했다. 부수적인 기능이라고 생각해서 그걸하는 것보다 연동하면서 발생한 오류를 잡는게 좋을 것같다고 생각했다. 하지만 마무리를 하지 못한 것 같은 느낌이 들어서 기능의 우선순위를 먼저 계획하고 해야할 것 같았다.
개선할 점
- 우선순위 '상'의 개수 조절
- 환경변수 적용
- CSS 초기화 작업
- 로그인, 공용 컴포넌트 우선 구현
- 애자일식 개발 방식 : 구현 우선순위 적용 개발 -> 배포 -> 개발
- 반응형
- 최소 기능 구현 후 기능 추가
연동하면서 여러 예상치 못한 일들이 발생했다. 그래서 구현했던 기능이 최종적으로 표현이 안되는 안타까운 일이 발생했다. 그리고 화면 크기에 따라 틀어지면서 원인을 찾는 과정도 한참 시간이 소모되었다. 미리 겪었으니 메인에서 더 좋은 방법을 만들자!
