항해99 8주차(2021.4.19-4.25) WIL : 미니프로젝트 2주차, 마지막 과정인 실전프로젝트 시작

이번주는 22일 목요일 자정까지 미니프로젝트 과제를 수행하고, 금요일-토요일에는 새로 만난 실전프로젝트의 조원들과 프로젝트 계획을 세웠다.

1. 미니프로젝트 

이번주에는 많은 걸 하고 싶었지만 여건상 그럴 수 없었다. 지난주에 로그인/회원가입에서 시간을 너무 많이 썼고 프론트엔드 동료가 많이 어려워해서 많이 도와주다보니 더 많은 걸 할 시간이 나지 않았기 때문이다. 그래서 필수 페이지를 만들고 CRUD 기능을 구현하는데 집중했다. 나도 내 실력을 보니 많은것에 손을 대기 보다 CRUD 하나라도 확실하게 연습해서 익혀두는 것이 필요했다. 

 

CRUD : 제품게시글 작성/가져오기/수정/삭제, 상세페이지

얼추 제품게시글 정보를 가져오는 리덕스 모듈 파일(post.js)을 작성하고, 그것을 페이지 컴포넌트 안에서 쓸 수 있도록 연결한 다음, 백엔드에서 상품정보를 담당한 분과 서버 연결을 테스트 했는데, 일부 문제가 생겼다. 

위 이미지처럼 처음에는 이렇게 데이터를 서버로부터 받아 와서 메인페이지의 여러 상품게시물틀에 넣어주려고 했으나, 되지 않았다. 왜냐하면 위의 코드는 상세페이지용 코드여서, 여러 상품의 정보를 받는 것이 아니라 특정 상품의 데이터를 가져오는 것이었기 때문이다. 지난주의 클론코딩 인스타그램의 코드를 참고해서 짰던 걸 보고 가져와서 조금 손 본 것이 이번것과는 맞지 않아서 생긴 문제였다. 왜냐하면 클론코딩 인스타그램에서도 상세페이지가 있긴 하지만 상세페이지가 메인페이지의 게시물 정보를 그대로 물려 받기 때문에 메인페이지로 데이터를 한번 받아두면 끝이었기 때문이다. 그래서 저 코드에서는 원래 forEach 함수를 이용해 받아온 여러 상품에 관한 데이터들을 한 게시물씩 묶는 코드가 있었다. 하지만 이번에는 상세페이지에 한 상품에 관한 정보만 받아 오는 것이므로 forEach를 쓰지 않는게 맞아서 저렇게 고쳤다. 메인페이지에서 데이터를 물려 받으면 사실 상세페이지 데이터를 받는 미들웨어는 없어도 되지만, 상세페이지는 메인페이지의 게시글보다 더 자세하고 많은 정보를 서버에서 보내므로(메인페이지에는 없는 상품의 더 자세한 상태 같은것) 상세페이지로 보내는 데이터는 메인으로 보내는 것과 다르게 서버에서 보내기 때문이다.  사실 이걸 깨달은건 백엔드 분이 메인페이지에 정보는 여러 상품 정보를 보내주니 forEach를 써야 하지만, 상세페이지는 그렇지 않고 한 상품 정보만 간다고 하면서 forEach를 써야 하는 경우와 아닌 경우가 있다고 설명해줬기 때문이다. 클론코딩에서 리덕스를 이해하는 법을 익히고 코드를 쓰는 방법을 알아뒀고, 백엔드 분의 적절한 조언이 있었기 때문에, 리덕스 모듈 파일을 성공적으로 수정할 수 있었다. 그 결과가 위의 상세페이지 정보를 받는 코드, 아래의 메인페이지의 모든 게시물 정보를 받는 코드다. 나도 이렇게 코드를 잘 짜낼 줄 몰랐고, 백엔드분의 도움을 받아서 해낼 줄은 더 몰랐다. 이렇게 발전하는 느낌이 참 신기하기도 하고 짜릿하기도 했다. 백엔드분이 차분하게 설명해주고 도와준 덕분이 컸다. 항해99의 운영진이 말하는 서로 협력하는 사람, 같이 일하고 싶은 사람이 되어라는 말은 이런 것을 두고 한 말일 것이다. 

위에서 설명했듯이, 메인페이지에는 서버에서 모든 상품게시글 정보가 오므로, 그것을 forEach를 이용해 분류해서 각 게시글로 데이터를 나눠서 보내주었다. 결과는? 다행히 성공!

그리고 수정/작성도 성공적으로 되었다. 수정/작성이 되게 해둔 것도 성과지만, 무엇보다 가장 큰 성취는 모든 데이터가 한번에 오는 경우, 하나에 관한 데이터만 오는 경우를 나눠서 생각해서 코드를 짤 수 있게 된 것이다.

 

이 외에도 미니프로젝트를 하면서 겪은 몇몇 일과 문제 해결은 다음과 같고, 자세한 내용은 TIL로 작성해두었다.

1 . 상품 상세게시글의 채팅 기능 구현기(채팅용 실시간 통신은 되었으나 채팅은 시간 부족으로 구현 실패ㅠ)

원래는 채팅을 댓글스럽게 구현하면 된다고 봤으나, 백엔드분이 댓글은 응답-요청이라는 클라이언트-서버 통신인데 채팅 메시지를 한번 보낼 때마다 응답-요청으로 처리할 수는 없다고 했다.  대신 대화하는 참여자가 모두 주는자이도 하고 받는자이기도 하는 역할을 하게 되는 실시간 양방향 통신을 하는 것이 채팅에 맞다고 했다. 그래서 채팅을 구현하면서 websocket이란 것을 접하기도 하고, 일단 통신자체는 되게 하는 코드까지 백엔드분의 도움을 받으면서 작성하는 경험을 쌓게 되었다.

    heo-dev-0229.tistory.com/23

항해99 52일차 TIL : websocket으로 실시간 양방향 통신 테스트 하기.

2. useEffect와 비동기 처리로 인한 문제 해결. 리액트는 비동기 문제라는 약점이 있단 걸 알게 되었다.

리액트의 비동기가 문제가 무엇인지 알게 되기 + 내 지식으로는 해결할 수 없다면 훌륭한 스승을 찾아가서 배움을 청하는 것이 좋다는 것을 느끼기. 뉴턴의 말대로, 우리는 거인의 어깨위에서 더 멀리 볼 수 있는데, 그 거인은 바로 스승이다. 

    heo-dev-0229.tistory.com/24?category=931800

항해99 53일차 TIL : useEffect는 사실 비동기처리였다니!

좌충우돌을 겪으며 나온 결과물! (지금은 서버가 내려가서 헤더만 보인다)

사실 원하는 기능들이 잘 되는 것보다도 기분 좋은 건, 개발자도구를 열고 보면 원하는대로 데이터가 오고 가는 것이 보인다는거다. 다른 개발자들도 우리 사이트를 보고 개발자도구를 열어보면 데이터가 오고 가는 것이 깔끔하게 이뤄지고 있다는 것을 알거라고 자신할 정도다. 이렇게 되기 위해서 노력을 참 많이했다. 예를들어 로그아웃을 하면 오류페이지가 나왔는데, 그 문제를 튜터님에게 들고 가서 논의를 하니 리덕스 모듈 파일에서 initialState 형식이 잘못 될 수 밖에 없는 결함이 있음을 알아내고 수정해서 문제를 해결했다. 다른 문제로 코드의 어느 부분에서 재귀호출이 일어나서 서버로 무한 요청이 들어가고 있었는데 쓸데 없는 console.log를 다 지우고 중복된 코드를 없애서 해결했다. 이런 노력의 결고로 우리가 개발한 사이트가 깔끔하게 작동하는 것을 보니 뿌듯하다. 

 

hanghaemarket.shop/

항해마켓

(지금은 서버가 내려가서 헤더만 보이는 상태이므로 유튜브 영상으로 확인해보세요!)

youtube.com/watch?v=idAJS0OLPhY&feature=share

메인페이지

상품게시글 작성

제품상세페이지

미완성인 채팅창

2. 실전프로젝트

실전프로젝트는 5주 과정으로, 항해99에서 개발작업을 하는 것은 이것이 마지막이다. 이 기간이 지나고 남은 기간 동안은 회사에 지원하는 기간이기 때문이다.

 

이번 프로젝트 기간에는 이제까지 온갖 좌충우돌을 겪고 어떻게든 존버하면서 익힌 지식과 테크닉을 한계까지 짜내어서 구현해야 하는 기간이다. 주특기 2주 동안 자바스크립트를 너무 몰라서 개고생을 했지만, 다행스럽게도 클론코딩 1주와 미니프로젝트에서 틈틈이 자바스크립트에서 꼭 해야 한다 싶은 부분은 배워 두고, 필수 기술인 CRUD를 연습하고, 리덕스 사용법과 코드 작성법을 익히고 다른 잔기술도 조금씩 익혀 두었다. 그래서 이번에도 원하는 것에만 집중하는 존버로 어떻게든 해낼 거라 자신한다.

 

그리고 정말 나는 억세게 운이 좋은 놈인지 우리조는 프론트엔드 동료님들, 백엔드 동료님들, 디자인 동료님들 모두가 정말 잘 맞는 분들로만 이뤄진 느낌이다. 백엔드들은 뭐든 다 구현해줄 능력을 갖춘 분들이라서 든든하고, 디자인 부문으로 합류하신 분들도 학교와 직장에서 갈고 닦은 실력이 있으니 보기 좋고 예쁘게 디자인을 해주실거라 본다. 나를 포함한 프론트엔드 사람들의 실력은 사실 항해99의 리액트 탑티어 분들 수준은 아니다. 하지만, 다들 기본 실력은 갖추었고 으쌰으쌰해가면서 할 사람들이라서 서로 격려해가고 도와가면서 어떻게든 해낼것이다. 그래서 힘에 부칠까 걱정이 조금 되긴 하지만, 이번 과정을 거치면서 나와 프론트엔드 동료들의 실력이 급성장해낼 것 같아 기대가 크다.

 

주제

우리팀의 주제는 사진을 찍기 좋은 명소를 소개해주는 서비스를 만드는 것이다. 치열한 논의를 거쳐 압축된 우리 프로젝트의 컨셉은 우리 프로젝트의 소개글에 잘 담겨있다.

--------------------------------------------------------------------------------------------------------------------------------

SFlash(Spot + Flash)
 “인스타, 블로그 나만 모르는 곳들... 대체 거기가 어디야??”
연인과 늘 가던 곳이 아닌 새로운 곳에서 추억 사진을 남기고 싶은데 그런 곳이 쉽게 떠오르지 않는다면?

• ㅇㅇㅇ과 함께라면 꼭 특별한 날, 특별한 곳에 가지 않아도 괜찮습니다. 내 주변에 알지 못했던 인생샷 명소를 만나세요. 그리고 나만의 명소도  마음껏 자랑해주세요.
• 카페, 풍경,야경 등 여러가지 카테고리에 자신이 알고있는 명소도 공유하고 다른사람들의 꿀팁 명소까지! 한번에 알아보세요!
• 저희는 사용자들이 서로 자신들이 알고있는 숨겨진 사진 Spot(사진이 잘나오는 곳)을 지도에 직관적으로 마커로 표시해 서로 공유하고 마커로 공유해놓은 명소에 서로의 자유로운 의견을 이미지를 첨부해 표현할 수 있으며 맘에드는 사진 Spot은 좋아요를 눌러 따로 모아 볼 수 있고 카테고리에따라 자신의 취향에 맞는 사진명소들을 한눈에 보기 쉽게 정리 해놓은 sns서비스 입니다

-----------------------------------------------------------------------------------------------------------------------------------------------

 나는 다 좋지만 특히 SFlash라는 이름이 정말정말 마음에든다! 추억은 섬광(flash)처럼 지나가는 것인데 그 추억이 깃든 장소(Spot)이랑 연결했다는 의미로 해석할 수 있는게 좋고, 스플래쉬라는 소리도 맘에 든다. 스플래쉬(splash)는 영어로 물에 첨벙!하는 소리라는 뜻이 있는데 임팩트 있는 이름이라서 좋다. 상표등록이라도 해야할 것 같다. 누가 이리도 쌈빡하게 지었는지 색출해서 칭찬해줘야겠다.

 

와이어프레임도 치열한 논의를 거쳐서 그렸다. 와이어프레임도 공동작업으로 그렸고, 피그마를 이용했다. 이거 사용법에 통달한 능력자님들이 있어서 예쁘게 나왔다. 디자인 분들이 손보면 더 예뻐질듯!

www.figma.com/file/XjkfeG33ysb5LNcNGhGqgB/%ED%95%AD%ED%95%B499-7%EC%A1%B0---%EB%AA%85%EB%88%84%EC%B0%BE(%EA%B0%80%EC%A0%9C)?node-id=0%3A1

Figma

그리고 첫주에 프론트-백이 각자 해야 할 일을 분배했고, MVP(Minial Viable Product) 기준에 맞는 구현 목표들을 아래와 같이 정했다.

API와 같은 세부 사항, 와이어프레임, 주차별 진행상황, 베이스룰 등등등 조원들이 공유하는 사항들은 내가 만든 노션에 정리했다(미니프로젝트에서 한번 하고 나니 노션을 더 잘 다룬다. 역시 할 수록 느는 법이다). 금요일과 토요일에 조원들이 치열하게 고민하고 논의해서 정리가 되었는데, 나도 그렇고 조원들 모두 고생이 많았다. 이런 열정이라면 믿고 같이 갈 수 있다. 그런만큼 나도 한몫을 단단히 하는데에 초집중 할것이다.

www.notion.so/359a4c5102704e6fa1dabbff616fc5f8?v=4287d6116dff492fa96c06c812073998

7조 명누찾 계획 + 일정표

이제부터 시작이다! 걱정 대신 목표기능을 구현하는데 초집중하는 일이 남았다.