Pastel

짤고 굵었던 99일이 지나갔다. 

• 항해99를 진행하며 실제로 체감한 항해의 장/단점 (솔직 후기)
  • 장점
    • 열정있는 사람들과 협업을 경험하고 프로젝트를 가져갈 수 있다는 점. + 디자이너, 백엔드와의 협업 경험  
    • 어차피 공부는 혼자하는것이고 옆에 열심히 하는 사람들과 함께 도와가며 성장해야지 라는 마인드로 간다면 실망하지 않고 원하는것을 얻어갈 수 있을것.  
    • 자신이 그동안 만났던 팀원들과 좋은 경험을 만들고 좋은 평가를 받았다면 앞으로 개발자가 될 인재들의 인맥을 만들 수 있다는 것. 관련학과 또는 업종에 몸담았던 것이 아니라면 개발자 인맥은 거의 없다. 이러한 점에서 같은 방향을 바라보는 사람들과 정보를 공유하고 의견을 나눌 수 있다는 것은 큰 도움이 될 것이라고 생각한다. 
  • 단점 
    • 여러가지 세션, 자료등을 제공해주지만 완전 입문자 입장에서는 부족하다고 느낄 수 있다. 봐도 이해안갈 수 있고 좀 더 친절한 설명을 바랄 수 있다. 때문에 어느정도 독학이나 사용하고자 할 언어에 대해 공부를 해 간다면 급하게 흘러가는 항해속에서 좀 더 숨통이 트일 것 같다.
    • 멘토링 같은 부분은 좀 더 길게 봐 줬으면 좋을 것 같다. 

• 실전 프로젝트 (경험담)
  • 프론트엔드/백엔드를 담당한 입장에서 가장 많이 배운 것
    • 백엔드와 디자이너 사이에서
      • 프론트를 담당한 입장에서, 프론트는 디자이너가 원하는 css작업과 팀이 원하는 기능을 구현해야 한다. 1주일 단위의 작은 프로젝트들은 그렇게 까지 많은 것을 바라지 않고 연습하는 기간이라 크게 문제가 되지 않는다. 그러나 실전프로젝트 기간에는 경험이 많이 없는 입장에서 새로운 기술을 도입하고 기능을 구현해야 하는 일의 기한을 예측하는 것이 쉽지 않았다. 이것은 많은 기술들을 경험하고 협업하는 과정에서 배울 수 있는 것이라고 생각한다.   
    • 라이브러리 
      • 우리조는 뷰작업(인피니트 카루셀, 페이지네이션, 모달 등)을 라이브러리에 의존하지 않고 직접 구현했는데, 그 이유는 어느정도 원리를 알고 사용하는것이 성장하는데에 더 도움이 될 것이라고 생각해서이다. 그 과정동안 마냥 쉽지만은 않았고 생각할것도 있어서 많은 것을 배웠다고 생각한다.
    • 재사용성 
      • 팀에서 프로젝트 구현의 방향성은 빠르게 mvp를 구현하고 챌린지적 요소를 더하는 방식을 선택했다. 때문에 디자이너님의 디자인이 나오자마자 작업에 들어갔는데, 이 과정에서 재사용성에 대한 부분은 조금 부족하다고 생각했다. 자신이 맡은 부분 구현하느라 재사용성을 생각하는데에는 소홀했다고 생각한다. 앞으로는 조금 더 같은 개발자 경험 향상과 편의성을 위해 이부분을 고려해야겠다고 생각했다.
  • 실전 프로젝트 때 가장 좋았던 점
    • 좋았던 점 중 하나는 디자이너 협업 경험이다. 사실 혼자 공부하고 팀만들어서 디자이너님까지 구하는 것은 어려움이 있을 수 있다고 생각한다. 또한 백엔드들과 찐하게 얘기하면서 프로젝트 하는것도 개인이 사이드 프로젝트 할 때 이런 경우는 크게 없을것이라 생각한다. 넷상이지만 2~3개월동안 그래도 안면도 트고 가끔 수다도 떨면서 지내던 사람과 프로젝트를 같이하는 것은 소통하고 진행하기에 좀 더 수월하지 않을까 생각한다.( 물론 한번도 얘기안한사람과 팀이 될 수도 있고 자신과 안맞는 사람과 팀이 될 수도 있다.)
• 99일 간의 항해는 확실히 힘들고 어려웠다. 하지만 나는 이렇게 버틸 수 있었다. (자기관리)
  • 팀원들에게 양해를 구하고 나가거나 쉬고 올 수 있다. 하지만 실전프로젝트에는 길게 자주 쉬는 건 아무래도 팀원들에게 피해가 될 수 있을 것이다. 그래서 짧게 짧게 기분전환하는것이 좋을 것 같아서 집 가까이에 카페를 가거나 식후 30분정도 산책을 가서 기분전환했다. 

1. 이번주 한 것

클론 코딩 주차가 끝나고 7주차가 되었다. 많은 부분이 개선되어 진행이 되었어도 언제나 1주의 시간은 아쉬움을 남기는 것 같다. 이번주차에는 맡은 파트가 로그인/회원가입이라 이부분에 많이 신경썼다. 이미 한번 해본거라 어렵지 않게 했는데, 에러 핸들링 같은 세세한 부분에 조금 더 신경쓰며 하였다.

그리고 이번주는 항해 99  같은 반 사람들과 모임을 가졌는데 ㅋㅋㅋㅋㅋㅋ상당히 재밌었다 집만 더 가까웠으면 3차까지는 갔을 것 같은데 아쉽게도 그러지 못했다.. 다들 좋으신 분들이라 실전 프로젝트를 잘 마무리하고 기회가 된다면 또 만나면 좋겠다.

이번 실전 프로젝트때에는 이전에 사용했었던 기술스택에서 타입스크립트, 리액트 쿼리, 소켓 등을 추가해볼듯 하다. 

기대가 많이 되지만  처음써보는 스택들에 만드는 속도가 느려져서 팀원들에게 누가 될까봐 걱정이 되긴한다... 최선을 다해야 겠다..

1. 이번주 한 것

이번주는 미니 프로젝트 주차가 끝나고 클론 프로젝트 주차가 시작되는 날이다. 

미니 프로젝트때는 처음 백엔드와 소통하고 협업하는 주차인데 굉장히 많은 것들을 배웠다. 

팀원들도 너무 착하고 좋았지만, 처음이라 미숙해서 프로젝트를 제대로 마무리 못한게 아쉬웠다. 

우선 백과 프론트의 협업에서 중요한점인데, api를 짤 때 좀 더 자세히 같이 와이어프레임을 짜면서 하면 더 좋다는 점이다.

나는 처음에 백에서 설정해 놓은 api가 이해가 잘안갔다. 그런데 와이어 프레임을 만들고 코딩을 하면서 이해를 했는데, 백에서 설정한 api가 프론트에서 사용하기 어렵게 되어있었다. 근데 이걸 처음에 잘 몰라서 그냥 지나쳤었는데, 막상 기능 구현하려고 보니까 뭔가 잘못된걸 깨달았다. 그래서 기술매니저님께 여쭤보니, 객체를 배열에 담에서 주는 형식이 일반적이라고 하셨다. 그리고 api 명세도 중간에 바뀌기도 했고, 그래서 진행이 원활하지 못한것도 있다. 나도 css같은걸 미리미리 해놨어야 하는데 기능구현하고 하려니까 기능도 안되고 css도 제대로 못한점이 잘못이다. 기능도 뭔가꼬여서 제대로 안되기도 했고... 

좀 더 차근차근히 로직을 짤 필요가 있다고도 느꼈다. 약간 조급해져서 되는대로 짠 것도 있기도하고, 그러다 꼬여서 더 시간을 잡아먹은것도 큰 이유인것 같다. 로그인 기능에서도 괜히 쿠키로 보내려다가 시간을 많이 잡아먹기도 했다. 

전체적으로 경험의 부족에서 나온 것 같다. 이번 클론코딩주에서 만회하고자 노력해야지.

1. 5주차동안 한것

• 심화주차 종료
• 미니프로젝트 주차 진행중
• 혼공스 스터디 

AXIOS

axios란?

- axios는 node.js와 브라우저를 위한 promise 기반 http 비동기 통신 라이브러리

- 비동기로 http 통신을 가능하게 해주며 return을 promise 객체로 해주기 때문에 response데이터를 다루기 쉽다.

- 비슷한 기능으로 fetch가 있다. 

기본 문법

axios({
  url: 'https://test/api/cafe/list/today', // 통신할 웹문서
  method: 'get', // 통신할 방식
  data: { // 인자로 보낼 데이터
    foo: 'diary'
  }
});

보통 단축 request method를 이용한다.

GET : axios.get(url[, config])
POST : axios.post(url, data[, config])
PUT : axios.put(url, data[, config])
DELETE : axios.delete(url[, config])

async/ await을 쓰고 싶은경우

// async/await 를 쓰고 싶다면 async 함수/메소드를 만듭니다. 
async function getUser() {
  try {
    const response = await axios.get('/user?ID=12345');
    console.log(response);
  } catch (error) {
    console.error(error);
  }
}

config에 header 적용

import axios from "axios";

// axios.get(url, config)
// axios.post(url, data, config)

// 어떤 요청을 보낼 지, 별칭 메서드 사용
axios.post('/cat', // 미리 약속한 주소
	{name: 'perl', status: 'cute'}, // 서버가 필요로 하는 데이터를 넘겨주고,
	{headers: { 'Authorization': '내 토큰 보내주기' },} // 누가 요청했는 지 알려줍니다. (config에서 해요!)
).then(function (response) {
    console.log(response);
  })
  .catch(function (error) {
    console.log(error);
  });

전역으로 axios 객체 만들기

모든 요청에 적용되는 설정의 default 값을 전역으로 명시할 수 있다.

주로  서버에서 서버로 axios를 사용할때 요청 헤더를 명시하는데 자주쓰인다.

import axios from "axios";

...

const instance = axios.create({
	baseURL: "요청보낼 서버 도메인" // 요청을 www.aa.com/user로 보낸다면, www.aa.com까지 기록
});

// 가지고 있는 토큰 넣어주기!
// 로그인 전이면 토큰이 없으니 못 넣어요.
// 그럴 땐 로그인 하고 토큰을 받아왔을 때 넣어줍시다.
instance.defaults.headers.common["Authorization"] = USER_TOKEN; 

export default instance;

2. 좋았던 점

• 그동안 백과 프론트의 협업을 기대했는데, 당연히 쉽지는 않지만, 반쪽짜리가 아닌 백엔드와 같이 할 수있는 프로젝트를 시작해서 좋다.

3. 개선할점 / 아쉬운점. 

• 내가 가진걸 활용하는 것도 중요한 것 같다. 지금까지 만든 것들도 잘 활용해보자

4. 목표

• 지금까지 계획한 기능들은 다 작동될 수 있도록 해보자!

참고자료

https://inpa.tistory.com/entry/AXIOS-%F0%9F%93%9A-%EC%84%A4%EC%B9%98-%EC%82%AC%EC%9A%A9#:~:text=Axios%20%EB%9D%BC%EC%9D%B4%EB%B8%8C%EB%9F%AC%EB%A6%AC,Ajax%EC%99%80%20%EB%8D%94%EB%B6%88%EC%96%B4%20%EC%82%AC%EC%9A%A9%ED%95%9C%EB%8B%A4.

https://velog.io/@kysung95/%EA%B0%9C%EB%B0%9C%EC%83%81%EC%8B%9D-Ajax%EC%99%80-Axios-%EA%B7%B8%EB%A6%AC%EA%B3%A0-fetch

1. 오늘한것

- json-server를 이용하여 2페이지정도 기능만 구현되는지 확인

사실 task분담이 걱정이 되었는데, 여러방법을 생각해보았다.

자신이 하고싶은 페이지로 나눠서 구현, 페이지 flow 대로 나눠서 구현, 특정 컴포넌트가 많이쓰이는 페이지 별로 나눠서 구현 등등이 있었다.

프론트 팀원분은 페이지 flow대로 나눠서 해보셨고, 나는 하고싶은 페이지를 정해서 협업해봤다. 그래서 특정 컴포넌트가 많이 사용되는 페이지 별로 나눠서 해보기로 했다. 

아직까지는 좋은점은 자주쓰이는 특정 컴포넌트가 모여있는 페이지가 있으니 관리가 쉽다는 점이다. 내가 맡은 다른페이지를 만들기도 쉽다는 점.

안좋은점은 flow를 그냥 상상해서 해야한다는 점..?

또 어려운점은 내가 맡은 페이지는 메뉴 갯수마다 input갯수가 달라지는데, input갯수를 만드는 건 쉽지만 submit 되었을때 각 매뉴 객체마다 새로 받은 input값들을 넣어줘야하는데 이부분이 조금 어려운것 같다.

2. 개선할점 / 아쉬운점. 

- 한페이지를 너무 오래잡고 있었다. 일단 만들기 쉬운부분 먼저 쳐내고 어려운 페이지를 더 많이 고민해보자.

3. 잘한점 

- 그래도 팀원들과 소통은 잘하고 있는것 같다...! 

3. 고민해 볼 것

- 랜덤한 갯수의 input값들을 submit할때 어떻게 처리해야하는지 고민

4. 다음 목표 및 개선해야할점

- 주 1회 알고리즘 풀이( 평일에는 힘들것 같으니 주말을 이용)

- CSS grid, Grid Garden

- 새로운 미니 프로젝트에 다양한 custom hook에 도전, pagenation 적용해보기

- uselocation  알아보기

- 읽어볼만한 책 찾기 

참고자료

1. 오늘한것

- 미니프로젝트 시작

- S.A 작성

-  프론트와 백엔드와 같이 API 명세서 작성

- 폴더 구조 짜기

오늘은 처음으로 백엔드와 프론트엔드가 협업하게 된다. 

팀원들도 다 너무 좋은 분들이라 팀도 마음에 든다!  

우선 S.A를 작성하게 되는데 주제를 정하는데, 이전기수를 참고해 보니까 대부분 CRUD 기반으로 주제만 정한 것 같다. 그럴 수 밖에 없는게 CRUD연습을 지금껏 해왔기 때문이다.

우리는 배달의 민족 서비스를 카피한 서비스를 만들기로 계획했다. 손님이 주문할 수 있고, 그 주문내역을 오너가 확인 할 수 있는 것이다. 

우선 와이어 프레임을 짜고 폴더 구조를 짜는데, 어우 하나 쉬운게 없구나 느꼈다 ㅋㅋㅋㅋㅋㅋㅋ 지난 주차 폴더 구조를 짠 방식으로 좀 짜봤는데, 맞는건지도... 이게 효율적으로 짠 건지도... 삽질해봐야 알것 같다 ㅎㅎ

또 같이 api 명세서 같이 작성을하는데 이걸 보고 있는데 약간 상상이 안가서 의견같은걸 못냈다. 근데 곧 감이 잡힐 것 같다. 

2. 개선할점 / 아쉬운점. 

- 와이어프레임을 같이 짜면서 api를 짰으면 좀 더 이해가 쉬웠을 것 같다. 

3. 잘한점 

- 아직까지는 계획한대로 흘러가는 것 같다! 

3. 고민해 볼 것

- 프론트와 백엔드간에 협업시 서로 알아둬야할 내용에 대해서 

4. 다음 목표 및 개선해야할점

- 주 1회 알고리즘 풀이( 평일에는 힘들것 같으니 주말을 이용)

- CSS grid, Grid Garden

- 새로운 미니 프로젝트에 다양한 custom hook에 도전, pagenation 적용해보기

- uselocation  알아보기

- 읽어볼만한 책 찾기 

참고자료

1. 오늘한것
- 과제 기능구현 및 마무리

이번에는 맡은 부분을 다 만들고 정리해서 배포하는 작업을 했다.

heroku에 json-server를 올려서 데이터 통신 하는 방식이다.

팀과제도 끝나고 challege 과제( Form의 유효성을 체크하고, 유효성을 체크 하지 못했을 때 사용자에게 유효성을 체크 하지 못한 이유에 대해서 안내하는 기능을 구현) 부분도 적용해서 내가 맡은 페이지에 보람을 느꼈다. 

 뿐만아니라 과제를 위해 고생한 팀원분들도 고생했다! 제일많은 CRUD 기능이 들어간 디테일페이지를 하느라 고생하신 분도 계시고, 홈 페이지에 간이 로그인 기능까지 추가해서 로그인하지 않으면 디테일페이지에 진입하지 못하게 만들어서 더 그럴듯한 모습으로 만드신 분도 계시다.. 모두 처음하는 협업일텐데 잘 도와줘가면서 해낸것 같다. 

다음 발제는 미니프로젝트이고, 이제 진짜 백엔드와 협업하게 된다. 어떻게 팀이 될지 모르지만 좋은 분들과 같이 했으면 좋겠고 기대가 된다!

배운것

- RestAPI

Representaitional STate Transfer의 약자

=> 자원을 이름으로 구분하여 해당자원의 상태(정보)를 주고 받는 모든 것을 의미한다.

=> HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고, HTTP Method(POST, GET, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용하는 것을 의미한다.

RESTful 하다는것?

=>RESTful은 일반적으로 REST라는 아키텍처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어이다.
‘REST API’를 제공하는 웹 서비스를 ‘RESTful’하다고 할 수 있다.

-PATCH vs PUT vs POST

CRUD에 매칭되는 메소드를 따져보자면,

POST => Create

PUT => Update

post는 자원에 대한 생성을 담당하고, put은 자원에 대한 수정을 담당.

PUT vs PATCH

patch도 수정을 담당하는 메서드이다.

둘의 차이점은 

patch는 수정만 담당하며 리소스의 일부분만 수정할 때 사용한다.

put은 리소스의 모든 속성을 수정하기 위해 사용한다. 

ex)

name만 바꾸고 싶은 상황

{ name: "park" } 을 patch와 put으로 보내줬을 때

{
  id: 1,
  name: "kim",
  age: 25
}

// PUT =>
{
  id: 1,
  name: "park",
  age: 25
}

// PATCH =>
{
  name: "park"
}
// id와 age 프로퍼티가 사라진다.
// put은 리소스의 모든 속성을 수정하기 때문

2. 개선할점 / 아쉬운점. 

- getCommentThunk부분 extrareducer 부분에 fulfilled을 써야 되는데 fulfilledwithvalue라고 써서 useSelect를 해도 값을 받아올 수 없었음. 정말 어처구니 없는 실수...  해결한 방법은 thunk가 완료된 이후에는 값이 받아와지는걸 볼 수 있었는데, 그 중간에 뭔가 값을 넘겨 받는 과정에서 문제가 있을 거라 생각했다. 근데 그 중간과정은 extrareducer 밖에 없었고 자세히보고 찾을 수 있었다.. 나를 믿지 말아라...

- 여지껏 addcomment action으로 받아온 payload를 reducer의 배열에 push해야하는데 =으로 action.payload를 할당해버림... 생각하자! 

3. 잘한점 

- 마무리 작업으로 CSS 작업을 했는데, 스타일드 컴포넌트로 어느정도 짜임새 있게 구성해 놓으니 UI를 다시 구성할 때, 편하게 바꿀 수 있었다.

3. 고민해 볼 것

- 실전 프로젝트 주제

4. 다음 목표 및 개선해야할점

- 주 1회 알고리즘 풀이( 평일에는 힘들것 같으니 주말을 이용)

- CSS grid, Grid Garden

- 다양한 custom hook에 도전, pagenation 적용

- uselocation  알아보기

- figma 한번 훑어보기

- 읽어볼만한 책 찾기 

참고자료

https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html

https://aws.amazon.com/ko/what-is/restful-api/

https://zereight.tistory.com/974#:~:text=%EC%97%AC%EA%B8%B0%EC%84%9C%20POST%EB%8A%94%20Create%EC%97%90,PUT%EC%9D%B4%20%EB%8B%B4%EB%8B%B9%ED%95%98%EB%8A%94%20%EA%B2%83%EC%9D%B4%EB%8B%A4.&text=PATCH%EB%8F%84%20%EC%88%98%EC%A0%95%EC%9D%84%20%EB%8B%B4%EB%8B%B9%ED%95%98%EB%8A%94%20%EB%A9%94%EC%84%9C%EB%93%9C%EC%9D%B4%EB%8B%A4.

1. 오늘한것
- 과제 기능구현

오늘은 내가 맡은 기능 구현을 다하고 다른 팀원의 기능까지 한번 해보고싶어서 새로 레포지토리를 파서 해보았다.

맡은 부분은 posting시 form의 유효성 검사 부분인데 만들면서 form을 어떻게 재사용할까 고민하면서 해봤는데 어차피 기능별로 폴더구조와 컴포넌트를 나눈거라 그냥 둬도 괜찮은 것 같다.

그리고 유효성 검사는 form에서 onSubmit이 될 때 받은 데이터를 조건문으로 값을 검사한 후 조건이 맞지 않으면 alert를 띄우는 방법이 있었는데 custom hook을 찾아보다가 여러개의 input을 받아서 유효성 검사를 한 후 유효성 검사를 한 후 조건마다 error메시지를 같이 return 해주는 custom hook이 있어서 적용해보았다.

당연히 직접 만들어서 써보고 싶었지만 먼저 흐름을 알고 하나씩 바꿔가며 적용해보고자 했다.

잘 되던걸 지우고 업그레이드 된 걸 적용시키려니까 조금 아깝긴 했지만... ㅋㅋㅋㅋㅋㅋ

처음 그 hook에 대해 작성된 포스팅을 봤을때 이해가 안가고 , 오류가 나는게 많아서 그냥 다른방법 찾아볼까 했다. 그래도 이거 있는것도 못적용시키면 나중에 어뜩하것나... 싶어서 싹지우고 하나씩 적용해서 해보니까 어떻게든 됐다...! 좀 custom hook에 대한 벽이 조금은 내려간 느낌. 

2. 개선할점 / 아쉬운점. 

조금 아쉬운건 useForm이라는 hook에 매개변수 받는 값을 설정해줄 수 있는데, redux의 action함수를 넣고 싶었는데 잘 되지 않아서 그냥 hook을 두개 만들어서 따로따로 써버린 것... 이러면 hook을 만든 의미가 없기 때문에 좀 더 찾아서 보완해봐야 한다.

거의 필수적인 것 flex, align-items, justify-content, margin, padding.. 등만 조합된 컴포넌트를 만들어서 재사용 했는데 이

 스타일드 컴포넌트에 너무 많은 css를 변수로 받아서 사용하는 것이 아닌지 매니저님께 여쭤보았다.  나중에 디자이너와 같이 일하게 되면 어느정도 짜여진 컴포넌트들이 나오게되고, 지금은 짜여져 있는 디자인도 아니고 중간에 계속 바뀔게 나오기 때문에 그렇다고 한다. 물론 나중에도 그럴일이 없지는 않다고 하시지만... 또 MUI 같은것을 나중에 사용하고 싶으면 어느정도 진입장벽이 있기 때문에 미리 조금씩 봐도 괜찮다고 하신다.

나는 간단하게 최소 단위로만 구현해보고 아~ 뭐 쉽겠네 생각했는데... 오만한 생각이었다. 기능뿐만아니라 컴포넌트 나누기, custom hook적용, 유효성 검사,  redux, styled component, 만들때 세세한거 하나 모두 내가 할 일이구나 느끼고서는 다시는 그런생각을 안하기로 했다. ㅋㅅㅋ

팀원들 모두 열심히 구현하고 있다. 나도 내가 맡은 페이지는 별로 할게 없을 줄 알았는데, 업그레이드 하자면 할만한 것들이 많았다... 진짜 진짜 다시는 무시하지 않으리라 다짐했다...

3. 잘한점 

custom hook과 기능별 컴포넌트를 만들어 놓으니 다른곳에 사용할때 정말 편하게 적용할 수 있었다...!

이래서 컴포넌트와 hook을 쓰는구나 느낌!!

3. 고민해 볼 것

- 실전 프로젝트 주제

4. 다음 목표 및 개선해야할점

- 주 1회 알고리즘 풀이( 평일에는 힘들것 같으니 주말을 이용)

- CSS grid, Grid Garden

- 다양한 custom hook에 도전, pagenation 적용

- uselocation  알아보기

- figma 한번 훑어보기

- 읽어볼만한 책 찾기