✔ 서비스 바로가기
- netlify
- heroku
Client: https://github.com/Cool-Piece/Likelion-Cool-Piece-Frontend
Server: https://github.com/Cool-Piece/Likelion-Cool-Piece-Backend
Local 환경에서 실행 시 아래와 같은 준비가 필요합니다.
-
vscode liveServer extention을 설치합니다.
-
Github OAuth App을 설정합니다.
- 로컬 주소는 라이브 서버, port 5500을 기준으로 합니다.
- Homepage URL :
http://127.0.0.1:5500/assets/html/index.html - Authoization callback URL:
http://127.0.0.1:5500/assets/html/gitCallback.html
-
Root 디렉토리에 .env 파일을 만들고 다음과 같이 설정합니다.
GITHUB_CLIENT_ID = <YOUR_GITHUB_CLIENT_ID>
GITHUB_KEY = <YOUR_GITHUB_KEY>
GITHUB_SECRET = <YOUR_GITHUB_SECRET>
- 설정이 끝나면 아래와 같이 실행합니다.
$npm install
$npm run assets
root/assets/html/index.html을 liveServer로 실행합니다.
- MongoDB 계정이 필요하며 Root 디렉토리에 .env 파일을 만들고 다음과 같이 설정합니다.
GITHUB_CLIENT_ID = <YOUR_GITHUB_CLIENT_ID>
GITHUB_KEY = <YOUR_GITHUB_KEY>
GITHUB_SECRET = <YOUR_GITHUB_SECRET>
DB_URI = <YOUR_MONGODB_ATLAS_URL>
SECRET_KEY = <CUSTOM_JWT_SECRET_KEY>
- 설정이 끝나면 아래와 같이 실행합니다.
$npm install
$npm run dev:starts
| 이름 | 파트 |
|---|---|
| 김한별 | FrontEnd, BackEnd, 팀장 |
| 박지윤 | FrontEnd, 기획, 디자인 |
| 김준호 | FrontEnd |
HTML, CSS(SASS), JavaScript, Webpack
- 피그마를 통한 기획
- 트렐로를 통해 분업화와 현재 상황 점검 및 소통, 깃 워크 플로우를 통한 코드리뷰
- 스탠딩 미팅
- SNS(Github) 로그인
- 네브바를 통한 필터링
- 댓글 작성, 수정, 삭제
- 스터디 검색, 생성, 수정
- 프로필 설정
- 기술별 필터링
- 관심 스터디 북마크
- 로그인 페이지 ui구현 및 기능
- 마이 프로필 렌더링
- 웹팩 및 초기 코드 컨벤션 스타일 설정
- 백엔드 api 완성
- 상세 페이지 ui
- 프로필 수정 페이지 구현 참여 : api를 통한 로직으로
- Oauth 방식을 통한 SNS 로그인 구현
- 서비스 디자인 (피그마)
- 스터디 생성 페이지 UI 및 기능 구현
- 스터디 수정 페이지 UI 및 기능 구현
- 마이페이지 UI 구현
- 스터디 상세 페이지 댓글 UI 구현
-
공통 레이아웃 및 인증 기능을 담당
- 네비게이션 구현
- 전체 페이지에 인증 적용
-
메인페이지 UI 및 기능을 담당
- 기능 모듈화
- 필터링 기능 구현
- 검색 기능 구현
- 페이지 갱신을 고려한 데이터 처리
- 인증이 연동된 동적 UI 구현
- 반응형 UI 구현
-
로그인 기능에 참여
- Github OAuth 를 활용한 로그인 구현
-
상세페이지 렌더링 및 기능을 담당
- 댓글 기능을 구현
- 북마크 구현
-
유저 현황 페이지 구현
-
웹팩 설정 및 Netlify 배포
-
로딩 인디케이터 적용
- 처음 프로젝트를 위한 회의를 하며 만들고 싶은 서비스와 서비스 기능에 대해 고민하고 나누었습니다. 서로의 의견을 구글 스프레드시트에 정리한 후, 공통적인 아이디어를 결합하여 멋사 프론트엔드 스쿨 참가자들을 위한 스터디 서비스를 만드는 것으로 방향을 잡게 되었습니다.
- 피그마 사용이 익숙한 팀원이 먼저 서비스를 디자인 하고, 지속적인 회의를 통해 디자인 또는 기능을 구현하여 기획 단계를 마무리 하였습니다.
- 대략적인 서비스 기획 및 디자인 후 깃을 이용한 협업을 위해 프로젝트 구조를 잡았으며, 파일 생성 및 프로젝트 관리가 용이할 수 있도록 웹펙을 통해 컴파일러를 설정했습니다.
- 서비스의 로그인, 메인페이지, 게시글 작성 및 수정, 마이페이지 로 큰 틀을 잡고 프로젝트를 시작 하였으며, 협업 툴인 트렐로(Trello)를 활용해 Todo, Doing, Done을 공유하며 프로젝트 진도 및 이슈를 체크하며 진행하였습니다.
- 팀원간의 꾸준한 커뮤니케이션 그리고 피드백의 필요성을 느껴 매일 저녁 10~30분 간 프로젝트 회의를 진행하였습니다. 각자의 코드의 부족한 부분을 코드리뷰 그리고 Q&A를 통해 개선해 나갈 수 있었습니다.
-
git workflow는 feature방식을 택하여 진행하였으나 깃을 처음 쓰는 팀원 분들이 있어서 전체적인 충돌과정 병합에서의 수정을 도와주고 그것을 해결하는 쪽으로 많이 진행되었습니다. 초반 깃 메세지 작성에 관련하여 어느정도 통일성있게 갔으나, 문서화를 하지 못하여 처음 쓰는 팀원들이 어려움을 겪은 것을 보왔습니다. 매일의 스탠딩 미팅에서 깃 관련하여 도움을 주었고 그 부분이 많이 개선되어 각 브랜치에서 작업후 합병하는 방식으로 잘 전환 될 수 있었습니다. 같은 파일을 많이 서로 수정을 하다보니 충돌이 많이 이루어졌고, 깃 히스토리를 보면서 머지 방식보다 리베이스 방식을 써서 깃 관리를 깔끔하게 해도 좋을 것 같다고 생각하였습니다. 하지만, 팀원들의 코드를 되살리거나 재 수정할 때가 있었는 데, 이럴때 머지 기록을 보면서 어느 부분에서 수정일 잘못 되었고, 어느 부분에서 에러 나는지를 잡을 수 있었습니다. 또한, husky를 이용해서 커밋 직전에 저희가 정한 컨벤션에 맞지 않으면 올라가지 않도록 설정을 하여, 코드의 통일성을 맞출 수 있었습니다.
-
웹팩을 첫 문서를 보고 셋팅을 하였는데, 생각보다 모듈화를 일일히 셋팅해주는 부분에 있어서 file-loader를 통해 이미지를 컴파일 하는 부분에서 이미지 파일이 제대로 로딩이 안되는 상황이 있었는데, 웹팩설정을 웹팩5로 전부 바꾸면서 해결 할 수 있었습니다. 웹팩을 통해 SCSS 와 모듈화를 편하게 할 수 있엇고 이런 점에서 웹팩을 쓰는 장점에 대해 익힐 수 있었습니다.
-
로그인을 기능을 쉽게 생각하고 접근하였으나, 라이브서버로 화면을 보면서 작업을 하다보니, 팀원들이 자꾸 cors이슈에 대해서 맞닥 뜨리게 되었고, 이를 해결하기 위해 공식 문서뿐만 아니라 많은 것을 테스트 해보아야 했습니다. 개발서버는 https로 배포가 되어 있었고, 라이브서버로 html을 켰을 시, http로 되다보니 cors 이슈가 발생하는 것으로 확인 되었고, 결국 개발 중에는 백엔드 서버를 로컬로 쓰면서 작업하였습니다. 배포 후에는 프로토콜이 동일하게 되면서 잘 해결할 수 있었습니다. cors 이슈로 생각했던 일정보다 많이 초과되었지만, cors이슈에 대해 제대로 이해 할 수 있게 되었습니다.
-
전체적으로 팀원들과 시간을 조율하고 프로젝트를 전체적으로 관리를 하면서, 상대적으로 팀원들의 이슈인 git,bug 등을 해결해주고 설명을 해주면서 계획했던 스탠딩 미팅이 초과되기도 하였지만, 특강을 해주며 처음 개발을 해보는 팀원의 코드를 혼자 쓸 수 있도록 격려를 하면서 잘 마무리 할 수 있지 않았나 싶습니다.
FE개발 공부를 시작하고 처음 참여하게 된 프로젝트 이다보니 깃사용, 자바스크립트를 활용한 기능 구현, 협업 시 사용되는 전문 용어 (merge, branch, 충돌) 등 에 대해 초반 어려움을 느꼈습니다. 하지만 팀원들의 친절한 설명과 반복 작업을 통해 깃을 활용한 워크플로우를 이해할 수 있었습니다. 협업 시 깃을 사용하며 최종 도착지인 main 브랜치와 그 아래 dev, 기능별 또는 작업자 별 브랜치를 만들어 작업한 후 진행 과정 중 개별 브랜치와 dev 브랜치, 최종적인 서비스 배포를 위해 main브랜치에 merge하는 과정을 이해할 수 있었고, 향후 프로젝트에 적용하는 단계까지 이해를 높일 수 있었습니다.
프로젝트 초반, 브랜치 merge 시 충돌의 원인이 될 수 있는 .map, .css파일이 계속 생성되는 이슈가 있었습니다. git reset 명령어를 통해 해당 파일을 리셋, 삭제를 시도하였지만 해당 이슈는 해결되지 않았습니다. 팀원들과의 고민하던 중 git 웹펙 자체 파일 컴파일러와는 별개로 VSCode의 Watch SaSS 익스텐션을 구동하면 필요치않은 .map, .css 파일이 생성된다는 것을 확인할 수 있었고, 해당 이슈를 해결 할 수 있었습니다.
유저 데이터를 받아오며 구현한 로직이 동기적으로 실행되어 데이터가 전달이 되지 않는 이슈가 있었습니다. JavaScript 런타임에서 여러 로직이 순차적으로 실행이 되는 중 유저의 토큰을 가져오는 로직과 유저 아이디와 이름을 불러오는 로직이 동시에 실행되어 값이 할당되지 않았습니다. 해당 이슈를 해결하기 위해 동일 로직을 async와 await을 활용하여 비동기적으로 바꾸어 주었고, 유저 토큰을 가져오는 동안 유저 아이디와 이름을 불러오는 fetch에 await을 주었습니다. API에서 유저 데이터를 불러오는 과정에서 비동기적 프로그래밍에 대한 역할과 중요성을 경험할 수 있었습니다.
바쁜 일정으로 인해 완벽한 구현에 초점을 두기보다는 서비스의 기본적인 기능구현에 초점을 두고 개발을 진행했습니다. 유저에 대한 이해를 기반으로 메인 페이지를 비롯한 스터디 생성 페이지, 수정 페이지에서 다음과 같은 보다 섬세한 기능 구현이 필요합니다.
- 구글 이메일을 활용한 로그인
- 스터디 생성 및 수정 validation alert창을 UI적으로 더욱 고려
- 스터디 생성 페이지 글 작성 에디터
- 관심 스터디 북마크 기능 활성화