🌊 EFUB SWS
EFUB의 SWS 활동은 10명으로 구성된 한 팀이 기획부터 개발, 서비스 배포까지 함께하는 프로젝트다.
우리 베이커리 팀의 프론트엔드 팀원은 총 5명이었으며, 나는 그 중 프론트 리드로 참여했다.
내가 리드가 될 수 있는거임? 감자도? 싶긴 했지만 아무튼 리드..로 활동하게됐다.
이번 SWS 활동이 나의 성장에 매우 큰 도움이 된 것 같다.
새롭게 알게 된 지식도 많고, 내가 어느 부분이 부족한지 알게 된 기회였다.
항상 하던대로만 개발하던 안 좋은 습관을 가지고 있었는데, 팀원들의 깔쌈한 코드를 보면서 내가 얼마나 우물 안 개구리였는지를 알게 됐다.
기술적으로 배운 지식은 시리즈를 따로 파서 제대로 정리할 생각이고,
오늘 회고록에선 느낀점과 새롭게 배운 점들을 간단히 적어보려한다.
1. Github은 기능이 너무 많아
깃허브는 정말 기능이 많구나...를 알게 됐다 :0
특히 SWS는 매주 과제를 제출해야하는데, 코딩 컨벤션, 칸반보트 세팅, 프로젝트를 설명하는 리드미 등이 제출물이었다.
딱히 어려운 부분이 아닌데도 이게 있냐없냐에 따라 프로젝트 전반적인 협업 퀄리티에 크게 차이가 생기는 것 같다.
그동안 별로 중요하지 않다고 생각하고 미뤄오던 것을 드디어 제대로 할 수 있게 되어 매우 좋았다.
👀 PR 템플릿 & Reviewers 지정
SWS 전에는 한번도 제대로 PR을 써본 적이 없었다. 항상 냅다 머지해놓고'이거랑 저거 만들어서 머지했습니다~'하고 카톡에 통보만 했었다...
1) PR 템플릿을 정해놓고 사용하니 팀원들끼리 협업하는기 매우 편했다.
- 프로젝트 root 디렉토리에
.github폴더를 하나 만들고,pull_request_template.md파일을 만들면 끝!
2) Reviewers : 또 pr을 머지하기 전에 팀원들에게 변경된 코드를 확인해달라고 요청하는 기능이 있었다.
- Reviewers : 이 PR을 리뷰를 해 줄 팀원을 지정
- Assignees : 이 PR 작업의 담당자를 지정
Reviewers가 된 사람들이 해당 pr에서 변경된 코드를 모두 확인하면 초록색 체크 표시가 뜬다.
++ 찾아보니 issue 템플릿도 있다는데, 이건 어떤 식으로 사용하는지 더 알아봐야겠다.
📃프로젝트 칸반보드 사용하기
깃헙에는 issue들을 해야하는 일, 진행 중인 일, 완료된 일을 관리 할 수 있는 보드를 제공한다.
이슈를 연동해서 사용할 수 있다는 점이 매우 좋았다.
하지만 개발 시간이 부족하다보니, 오히려 너무 급해서 칸반보드는 거의 사용하지 못했다.
📈 브랜치 사용법
그동안 항상 브랜치를 나누지 않고 개발했었다.
하지만 팀원에 많아짐에 따라 효율적으로 브랜치를 나눠 작업할 필요성이 있었다.
페이지 퍼블리싱을 할 땐 담당자/맡은페이지 로 브랜치를 생성했다.
하지만 기능을 개발할 땐 feat 브랜치 하나만 파서 사용했다.
프로젝트 후반엔 각자 맡은 부분만 건들지 않고 다른 페이지의 로직까지 이것 저것 손보기 시작했기 때문이다...🤔
💹 브랜치 명령어
그 외... 기존의 git checkout 명령어가 조금 바뀌었다고 한다. 기존의 git checkout이 너무 많은 기능을 가져서라고 한다.
- checkout: Switch branches or restore working tree files
- switch: Switch branches
- restore: Restore working tree files
2. 로그인 그거 도대체 어케하는거임
Caker는 카카오소셜 로그인을 통해 유저 인증을 진행한다.
서버로부터 받아온 토큰을 모든 api의 헤더에 넣어 보내야했다.
어 그럼.. 토큰을 어디에 보관해야되지?
순간 머릿 속에 리덕스가 떠올랐다. 세미나 때 배웠던 리덕스를 사용해 간단한 코드를 작성해보았다. 하지만 제대로 작동하지 않았다. 흠 역시 내 코드가 한번에 돌아가면 그건 그거대로 이상한거다ㅎㅎ
내가 만든 리덕스 코드는 토큰을 저장하긴 하지만, 새로고침을 하면 다시 initial state로 돌아가버리는 문제가 있었다. 이 점은 전혀 예상하지 못했고, 어떻게 해결하는지도 알지 못했다. 시간 관계상 더 이상의 리덕스 삽질은 무리라고 판단했다.
그리해서 난 localstorage에 토큰을 저장해 사용하기로 했다.
토큰 외에도 user info를 localstorage에 저장했는데, 보안에 좋지 않다는 것을 알면서도 이렇게 개발했다.
로컬스토리지에 저장하는 방식의 문제점은, 로컬스토리지에 저장된 값을 바로 불러올 수 없다는 점이었다. 무조건 새로고침을 해야만 사이트가 제대로 작동했다.
💜 Redux Toolkit
프로젝트 막판에 다른 리드분이 redux toolkit를 사용해 완벽한 로그인 코드를 만들어주셨다. 물론.. 아직 이 부분 코드는 하나도 이해하지 못했다. 그냥 redux도 모르는데 toolkit?어쩌구?를 내가 알리가 없다
나의 목표는 redux toolkit을 활용한 로그인을 공부해 이번 멋사 중앙해커톤과 대동제 사이트 프로젝트에 활용하는 것이다.
고작 일주일 밖에 시간이 없긴 하지만, 그래도 최대한 프로젝트에 적용해서 내 것으로 만들어보고자 한다.
코드 만들어주신 @@님께 다시 한번 감사합니다...
3. API 깔끔하게 관리하기
모든 페이지에서 중복되어 사용되는 api들이 있다.
예를 들면 포스트를 불러오는 getPost 요청이나, 마이페이지에서 사용되는 getUser 같은 api들 말이다.
각자 서로 다른 페이지를 구현하지만, 모두들 비슷비슷한 api를 개발하게 된다. 그렇다면 각자 개발하는 것 보단, 누군가 한번만 개발하고 남이 가져와서 사용하면 매우 효율적일 것이다.
api 폴더, services 폴더 등으로 구분해서 종류 별로 api를 모아두고, export해 다른 페이지에서 사용할 수 있게 구분했다.
+ 기획 그대로 개발하지 못한 것 🥲
개발을 하다보니 중간중간 기획했던 내용이 누락되고 변경되는 경우가 많이 생겼다.
깜박하고 ui가 만들어지지 않았거나 api를 만들지 않았거나, 시간 부족의 문제로 프론트에서 구현을 못하거나...ㅠㅠㅠ
이번 뿐만이 아니라 지금 하고 있는 프로젝트에서도 ui엔 있지만 기능을 구현할 수 없는 부분이 많이 생기고 있다....
어떻게 해야 이런 상황이 안생기도록 사전에 방지할 수 있을까 고민해보았다.
필요한 기능을 한번에 볼 수 있도록 api 단위로 적어 정리하고 다함께 체크하는 과정이 필수적일 것 같다.
지금 해커톤 작업 중인데 필요한 api를 먼저 작성해보고 백엔드 팀에 컨펌을 받았는데, 구현해야하는 기능에 무엇이 있는지 체크하기 좋은 것 같다.
바보짓 모음
-
컴포넌트 밖에다가 변수 선언해놓고 왜 define이 안되냐며 화 박박냄
-
캘린더에 class가 적용이 안돼서 3시간동안 삽질 했는데, 알고보니 type이 안맞는 거였음. 이거 이후로 뭔가 안되면 typeof부터 찍어보게 됨
-
버튼 컴포넌트에 onclick 함수를 넣었는데 왜 실행이 안되냐며 화 박박냄. 알고보니 내부
<button>태그에는 함수를 안썼음. 하하
