항해 99 부트캠프를 시작했다.
시작 하기 전 나에게는 두가지 키워드가 있었다.
늦은 나이? (참가자들 평균 보다는 확실히 많은 나이)
커리어 전환( 기획자에서 개발자라는..)
이러한 마음의 짐이 있었기에 시작과 동시에 파이팅이 넘쳤던거 같다.
1. 프로젝트 기간
일시 : 2022년 3월 7일 (월) ~ 2022년 3월 10일 (목)
9시 간단 ot를 진행하고 팀이 배정된다.
기본 강의가 추가로 더 제공되고
5일동안 자체적으로 기획을 통해 제작을 한다.
5일 이라는 시간이 있고 우리의 수준을 고려하여
강의에서 얻을 수 있는 기능 + 구글링을 통해 가능한 범위 내에 기획을 했다.
2. 초기 기획서
초기에는 아래 항목의 설계가 필요하다.
1) 프로젝트 제목 / 설명
2) 와이어 프레임
3) api 설계도
4) 역할 분담
팀은 4명이었는데 나머지 3명이 반려동물을 키웠던 터라
빠르게 반려동물 관련 컨텐츠로 정해졌다.
(이제와서 하는 이야기지만... 강쥐,냥이 나만 없어 ㅠㅠ 너무 귀여웠다)
아래 내용은 팀장님의 velog에서 가져왔다.
https://velog.io/@gagyeong/미니프로젝트-계획서
[api 설계]
로그인 : post , /api/login
회원가입 : post, /api/signup
날씨 정보 : get, /api/weather
글작성 db저장 : post, /api/posts
작성글 페이지 등록 : get, /api/posts
상세페이지 : get, /api/posts
수정 : get, /api/posts
삭제 : delete, /api/posts -> db에서 아예 삭제!
다른게 어려웠다기 보단 api 설계를 하는게 조금 난감했다.
우리가 구현하고 싶은 기능들을 먼저 적고
거기에 대해 api를 설계해야하는데
아는게 없으니... 이게 맞나? 싶은 생각으로 대-충 작성을 했다.
하지만 api 설계는 대-충 하다가는 정말 큰일난다는 사실을 알게되었고
미니프로젝트라 큰 이슈는 없었지만..
프론트와 백을 나누게 되면 정말 초기 설계가 나중에 협업을 할 때
굉장히 중요하다는것을 느꼈다.
3. 문제의 깃허브
보통 협업툴로 많이들 사용하는 깃허브다.
계속해서 카톡으로 알집을 주고 받을 수 없으니..
버전 관리 / 취합의 손쉬운 목적을 위해 개발자들은 깃허브를 많이 이용한다고한다.
물론 개인의 프로젝트들을 올리고 포트폴리오 활용도 많이한다.
깃허브를 처음하다보니 굉장히 많은 시행착오가 있었다...
커밋 / 푸쉬 / 풀 / 머지.. 진짜 뭐지? ㅋㅋㅋ
이러한 기능들을 혼동없어 각자가 잘 해야하는데
파일이 섞이고 사라지고 모든 라인이 엉키는 시행착오가 있었다.
항해 강의에선 sourcetree 라는 소프트웨어를 추천했는데
팀원분이 깃허브 자체에서 제공하는 깃허브 데스크탑 이라는 프로그램을 추천해주셔서
네명다 사용하기 시작하며 깃허브의 안정을 찾기 시작했다.
(깃허브 공용 repo 주소를 두세번 판거는 비밀..)
결론만 말하면 깃허브는
master(메인이 되는 줄기)를 기본으로 두고
여기에 origin(원본 파일)을 처음에 올려서
모두가 그것을 pull(내려받기) 해오고master에서 작업을 하는게 아닌!! (젤 중요)
각자의 branch(쉽게 말하면... 메인에서 뻗어 나오는 나만의 폴더..?)를 새로 생성하여 작업을 진행하게 된다.
branch는 master에 새로 파일을 merge(마스터에 브랜치를 합치는 작업) 하게 되면,
팀원 모두가 master에 있는 파일을 다시 받아서 새로운 branch를 만들어 작업을 해야한다.
그렇게 해야 각자 작업하는 내용에서 충돌이 적게 일어나서 merge를 다같이 할 때 순조롭다.
글로 주저리 적으니까 이해가 어렵지만..
약 이틀정도 굉장한 시행착오를 겪은 다음에 편안함을 얻었다.
(*실제로 후기를 들어보니 끝날때까지 깃허브의 늪에 빠져 결국 알집으로 서로 파일을 주고받기도 했다고 한다.)
[깃허브 주소]
https://github.com/U-Jinyeol/6a-team4
GitHub - U-Jinyeol/6a-team4
Contribute to U-Jinyeol/6a-team4 development by creating an account on GitHub.
github.com
[깃허브 데스크탑]
4. 팀 프로젝트의 역할 분담
우리는 크게 네가지로 파트를 나눴다.
1) 메인 페이지
2) 등록 페이지
3) 상세 페이지
4) 로그인/회원가입
처음에는 어떤게 많은 작업인지 몰라서
메인 1명 / 등록+상세 1명 / 로그인 + 회원가입 2명 이렇게 나누었다.
하지만 작업을 하다보니 서로 도움을 주어야 할 부분들이 생겼고
나중에는 모두가 같이 풀리지 않는 기능을 해결하면서 진행했다.
팀프로젝트를 하면서 느낀 점은 우리의 실력이 다 고만고만하다보니
역할분담 후 난 완료! 이런 느낌으로는 절대 완성을 할 수 없다는 것이다.
결국 이 프로젝트를 성공적으로 마쳐야 하는게 공동의 목표이기 때문에
서로 모르거나 아는것에 대해서는 적극적으로 이야기하고 알아가는것이 중요한 부분인듯 싶다.
다른조는 모르겠지만 우리조는 화면공유하여 서로 이야기하면서 실시간으로 진행하는 경우도 많았다.
(깃허브 사용법 / 코드 수정 / 주석 처리 / 기획서 작성 등등)
5. 기능 구현
1) 로그인 기능 JWT(Json Web Token)
일단 강의에서 제공되는 부분이 많아 구현을 하는것 자체는 크게 어렵지 않았다.
완벽한 이해를 하고 구현 했다기 보다는 떠듬 떠듬 대략적으로 이해를 하면서 코드를 붙여넣었기 때문에
회고록을 다 쓰면 처음부터 코드를 자세히 보면서 풀이를 해 볼 생각이다.
JWT의 장점은 발급 후 토큰 검증만 하면 되기 때문에 추가 저장소가 필요 없어서 가볍다. 필요한 모든 정보를 자체적으로 지니고
있기(self-contained)때문에 두 개체 사이에서 손쉽게 전달 될 수 있다.
즉, 클라이언트에서 바로 처리가 가능해서 서버의 확장성을 가질 수 있는 큰 장점이 있다.
자세한 내용은 아래 블로그를 통해 확인!
https://velog.io/@junghyeonsu/프론트에서-로그인을-처리하는-방법
🤔 JWT, 정확하게 무엇이고 왜 쓰이는 걸까?
Json Web Token에 대해서 정확히 알고 넘어가자.
velog.io
또한, 회원가입/로그인에서 배운점은 정규식을 통한 input 박스에 기입되는 text의 제한을 둘 수 있다는 것이다.
숫자만, 영/한/숫자 조합 20자 이내, 10자 이내 등등 다양한 활용이 가능하다.
많이 쓰는 정규식은 잘 보관해두고 복붙해서 쓰는게 필요 해 보인다.
[로그인/회원가입 화면]
2) 메인 페이지
메인 페이지는 css를 최선을 다해 바꾸어 보았지만.. 개인적으로는 만족이 안되는 비쥬얼이긴 했다!
어찌보면 게시물이 붙는 부분이 정돈된 느낌이 덜한게 원인이지 않을까 한다.
메인에서는 다음과 같은 화면이 보여진다.
현재 기온(서울기준) / 등록하기 / 로그아웃 / 등록된 게시물
3) 게시물 등록 하기 (ajax / 사진 파일 업로드 / input 박스 type 설정)
게시물 등록하기는 페이지 내에서 등록창이 등장하는것이 아닌 새로운 페이지로 이동하여 등록하는 프로세스였다.
ajax 콜을 활용해 get/post로 서버에 저장하고 불러오는 형태로 진행했다.
그래도 사전 기본 5주 강의에서 가장 많이 다뤘던 형태라 나름 가장 반가운? 익숙한 코드였다.
사진 파일 업로드는 젤 마지막에 추가한 기능인데 사진은 파일이라는 형태이기 때문에 post로 줄 때 file의 형태로 주어야 했었다.
또한 내가 진행한 방법은 서버에 파일로 저장되는 형태가 아닌
#1. 나의 ec2 컴퓨터의 static 폴더에 파일 저장
#2. 서버에는 사진 파일의 이름을 저장된 날짜와 시간으로 변경하여 문자열로 저장
ex. file-22-03-10-17-54-20.jpg
#3. get을 통해 파일명을 불러오고 body에 이미지 경로를 써주어 붙여짐
ex. src="static/file-22-03-10-17-54-20.jpg"
이렇게 되면 괜히... ec2의 컴퓨터가 굉장히 하드가 커야할거 같은 부담감이 있어
회고 멘토링때 멘토님에게 문의해보니 보통은 서버에 최소한의 크기로 변환하여 저장을 많이 한다고 한다.
그리고 굉장히 많은 방법이 있기 때문에 회사?마다 사람?마다 상황?마다 적용이 필요하다고 했다.
또한 이번에 배우게 된 것 중에 하나가 input 박스의 다양한 type이다.
text / number / email / date / time 등등 요소별로 활용할 수 있는 type이 정해져있어 편리했다.
그리고 이름/전화번호 등도 로그인/회원가입에 쓴것처럼 정규식을 통해 문자열의 입력 제한을 둘 수 있었다.
4) 게시물 상세 페이지 (쿼리스트링)
게시물 상세 페이지는 은근히 조금 애를 먹었다.. 로직은 다음과 같이 세웠다.
#1. 메인 페이지에서 게시물 클릭 시 고유값 연결
-> 우리조는 name 으로 받는 값을 지정했다.
(*추후 이름은 변경될 수 있는 값이라.... 다양한 활용을 하지 못하는 점을 알고 후회했다.)
#2. 상세페이지에서 쿼리스트링 방식으로 db에 get을 요청해 정보를 받아옴
-> 이 코드는 처음 보는 방식이었는데, 다른 사전 스터디조의 코드를 보고 룸메이트의 도움을 받아 완성했다.
결국은 get을 통해 html의 body의 본문에 지정된 id값에 바로 데이터를 붙여 넣을 수 있는 방법이었다.
*쿼리스트링은 아직 공부가 많이 필요해보인다!
4) 게시물 수정하기 / 삭제하기
삭제하기는 팀원분께서 아주 쉽게 구현을 해주셨다.
문제는 수정하기 였는데... 결국? 표면적으로 보이는 기능에는 성공을 했다.
하지만 정말 누군가 코드리뷰를 해주고.. 올바른 방식으로 인도해주시면 좋겠다 ㅠㅠ
우리는 db.post.update_one을 통해 구현하고 싶었지만, 계속해서 실패를 했고 데드라인은 다가왔다.
결국 차선책으로 로직을 바꿨다.
#1. 수정등록하기 클릭 시 기존 게시물 삭제
#2. 등록하기 누른 새로운 게시물 등록
뭔가... 모로가도 서울만 가도 된다곤 하지만 아무리 봐도 비효율적인 방식인거 같긴하다.
그래도 구현하고자 했던 기능을 모두 완성?은 해서 나름의 성과는 있었다.
6. 프로젝트 시연 영상 및 도메인 주소
[도메인 주소]
독독! 개세요?
반려견 산책 같이하기 사이트
udisplay.shop
[데모 영상]
7. 해결 기능 / 아쉬운 점
1) 메인화면, 상세페이지, 수정페이지를 불러올 때 db에서 데이터를 어떻게 가져올 것인가?
-> Jinja를 이용하여 name 값을 기준으로 데이터를 가져옴.
name 값도 수정이 가능해서 확실한 기준이 될 수가 없어 기존 name 값 데이터 삭제 후 새로운 name 값으로 포스팅 하는 방식으로 수정하기를 구현했는데 데이터에 post 번호를 추가해서 그것을 기준으로 했으면 update_one으로 좀 더 깔끔하게 구현 가능하였을 것.
2) 사진 업로드 기능 구현
-> 사진 업로드 방법이 다 static에 저장되는 방식밖에 없는지db에 등록한 사진들이 모두 저장돼서 서버용량이 걱정됨.
3) 서버에서 로그인기능 구현 오류
-> decode('UTF-8')을 수정함으로써 해결
**이건 정말 애를 먹었다. 파이썬 버전때문에 local:5000에서 돌릴 때와 서버에 배포할 때마다 코드를 수정해주어야한다.
4) 게시물 올린 사람만 수정/삭제 기능
-> 이 기능은 결국 실패를 했다.. 일단 게시물이 누구 게시물인지 토큰값을 주지 않아 모두의 게시물이 되어 버렸다.
로그인 후 게시물을 작성할 때 토큰값을 주는 부분에 대해 공부가 필요하다
*아쉬운점 _ 코드 리뷰의 부재
-> 우리조가 진행한 코드가 과연... 통상적으로 쓰는지, 효율적인지, 더 좋은 방안은 없는지 등의 리뷰가 없다.
더 좋은 방안으로 길잡이를 해주는 과정이 있으면 좋겠다.
'항해 99 > 항해 6기 회고록' 카테고리의 다른 글
220610 [항해99] 수료식 (0) | 2022.06.10 |
---|---|
WIL _ 항해99 Week4 주특기 숙련(리액트) / 나만의 사전 만들기 (redux, redux-thunk, firebase, firestore) (0) | 2022.04.03 |
WIL _ 항해99(6기) Week 2알고리즘 (0) | 2022.03.29 |