중간발표가 끝났고, 예상대로 mvp를 완성시키지 못한 채 발표와 피드백을 받게 되었다. 모든 조가 완성을 시키지 못했다. 그럼 그렇지 3주안에 어떻게 이걸? ..
전 기수 분들과 멘토님들이 오신다 해서 발표장이 바글바글할 줄 알았으나 백 프론트 각각 단 한 명의 멘토님들 앞에서 발표를 하게 되었다.
하지만 멘토링은 생각보다 굉장히 날카로웠다. 많은 것을 깨닫게 되었다.
첫 번째로는, 테일윈드 CSS를 썼는데 테일윈드는 반응형 옵션을 잘 제공해주고 있다.
하지만 그것을 써먹지 못하고 ui가 깨지는 현상이 있다는 것. 때문에 무지성으로 이용하나 생각이 들 수 있다는 것이었다.
=> 반응형을 지원하는 것은 알고 있었고 그렇게 하려고 했으나, 내부 엘리먼트들이 반응형을 이용하기 꽤 까다로워서 중간에 포기하고 작업했었다.
피드백을 듣고 다시 반응형을 추구하기 위해 뜯어 고치고 있다.
두 번째, 가장 기본이 되는 Eslint와 Prettier 설정이 안되어 있다.
=> 띠용 초기 프로젝트 설계 당시 설치 다 하고 했었는데 이게 무슨 소리시지 했었는데.. 설치만 하면 안되고 설정까지 따로 해줘야 하는 것이었다. ㅋㅋㅋㅋ 너무 머쓱했다.. 바로 설정을 해주었다.
세 번째, 깃 브랜치 작업을 더 안전하게 했으면 좋겠다.
=> 현재는 메인에서 각자 브랜치를 따와서 작업하고 머지하는 방식이었다. 하지만 그러다보니 오류가 있는 상태에서 머지를 하면 배포하거나 오늘처럼 시연을 할때도 오류가 있는 상태의 웹을 보여주게 된다. 이렇게 되면 자동배포를 한 것이 아무 의미가 없게 된다. 때문에 실험적인 기능은 dev 브랜치를 만들어 놓고 거기에 작업을 하고 완성이 된다면 올리는 형태가 더 안정적이다. 이 부분은 깃의 브랜치 관리 전략을 잘 몰랐다. 다음 프로젝트부터 적용해 봐야겠다.
네 번째, 기초적인 자바스크립트 문법.
맵에서 키값 지정을 하지 않거나 axios에서 async 에 then을 쓴다던지, 어디서 붙여온건지 let와 const가 무분별하게 쓰인 흔적이 보인다.
=> 와... 역시 경력자들은 그게 보이나보다.. 어떤 기능을 구현하든 제대로 알고 써야겠다고 반성했다. 하지만 let const는 알고 쓴건데.. 흠
다섯 번째, 사용하지 않는 컴포넌트 임포트 지우기
개발중이더라도 사용하지 않는 임포트는 제거해서 깔끔하게 유지하는게 좋다고 했다.
=> 음 혹시나 또 쓸일이 있으면 다시 쓰기 귀찮으니까 놔두고 나중에 끝나면 다 지워야지 했었는데 개발중에도 깔끔하게 정리하는게 맞다고 생각하게 되었다.
이런 멘토링 너무 좋다.. 현업에 가서 사수에게 코칭받는 느낌이 이런걸까..
개발문화가 좋은 회사에 가고 싶은 욕구가 더 올라갔다.
