[개발 공부 36일차] Devtiny Merge | News Feed

 

< 목차 >

1. 내가 구현한 페이지 및 기능

2. [Error]  missing in props validation

     - props의 타입 검증 방법

3. 깨달은 핵심 포인트

   (1) Merge

   (2) 기획 및 설계, 와이어프레임의 중요성

   (3) 완성된 코드를 다른 데에도 저장해두자

4. 금일 소감

 

 

 

1. 내가 구현한 페이지 및 기능

마이 페이지   상세 페이지

 

 

총 세 페이지를 맡았다. My Page, Detail Page, Write Page다.

CRUD랑, 이미지 업로드, 로그인 된 정보를 가지고 글을 다르게 보여주는 기능 등을 구현하였다. 메인 페이지랑 마이 페이지가 연결되는 부분이 있다 보니 기능의 일부는 안 되는 것도 있었다. 원래 더 일찍 주말에 Merge 해서 기능 완벽히 완성시키고 필수 기능 마무리 작업까지 끝냈어야 했는데 이번에 팀원 한 분과 나, 이렇게 2명이서 다 하려다 보니 필수 기능 구현 자체도 빡빡하게 한 감이 있다..

 

 

작성 페이지   수정 페이지 (작성/수정이 모두 한 페이지)

 

 

이미지 연결이 생각보다 어려웠다.

프로필에만 이미지 연결하면 되고 게시글에는 꼭 연결하지 않아도 괜찮았는데 프로필에 연결할 수 있으면 게시글에도 연결할 수 있겠다 싶어서 일단 넣었다. 저장도 잘 되는데 아직 전역 상태로 하지 않아서 이미지를 불러오는 부분이 안 됐다.

 

당장 내일 정오까지 시연 영상과 코드를 제출해야 해서 새벽까지 계속 해서 완성시켜야 한다. 그리고 Redux로 리팩토링 작업도 해야 해서 오늘도 늦게까지 작업하겠다 싶다.

 

위 페이지와 기능을 구현하며 여러 에러가 뜨고, 또 새로운 정보를 알게 되었다. 그 내용들은 다음과 같다.

 

 

 

2. [Error]  missing in props validation

[Eroor]  posts is missing in props validation

 

 

posts is missing in props validation 에러는 React에서 prop-types를 사용할 때 발생하는 경고다.

 

이 경고는 컴포넌트에 전달된 props의 타입을 prop-types를 사용해 명시적으로 검증하지 않았을 때 나타난다. 이를 해결하기 위해서는 prop-types 라이브러리를 사용하여 해당 컴포넌트에 전달되는 props의 타입을 검증해야 한다.

 

prop-types를 사용하면 컴포넌트에 전달되는 props의 타입이 예상대로인지 검증할 수 있어서, 타입 불일치로 인한 버그를 미리 방지할 수 있다.

 

 

 

props의 타입 검증 방법

(1) 터미널에서 아래와 같이 prop-types 라이브러리를 설치한다.

npm install prop-types

 

 

(2) 해당 컴포넌트에 prop-types를 적용하여 props의 타입을 검증한다.

import PropTypes from 'prop-types';
// 기존의 import 문과 다른 코드들...

const DetailPage = ({ posts, setPosts }) => {
  // 컴포넌트 로직...
};

// 여기에 prop-types 정의 추가
DetailPage.propTypes = {
  posts: PropTypes.array.isRequired, // posts는 배열이며, 필수적으로 전달되어야 함을 의미
  setPosts: PropTypes.func.isRequired, // setPosts는 함수이며, 필수적으로 전달되어야 함을 의미
};

export default DetailPage;

 

 

 

이러면 더 이상 에러가 뜨지 않는다

 

 

 

3. 깨달은 핵심 포인트

(1) Merge

Router, Firebase, Styled-component, Redux 등 초기 세팅 작업할 때 main뿐 아니라 dev Branch에도 Push 해두자. 편의성을 위해서도 dev Branch에서 Merge 한 다음에 테스트 할 때 모든 게 다 잘 적용되는지 보기 위해서도 dev에도 똑같은 초기 설정과 값을 적용해두는 게 중요하다고 느꼈다.

 

 

(2) 기획 및 설계, 와이어프레임의 중요성

와이어프레임에 작성한 의사코드

 

 

구현 사항이 많으니 사람 마음이라는 게 다급해져 일단 시작하거나 아니면 회피 성향으로 시작을 미루게 되는 등의 모습이 보이는데, 이번 프로젝트를 하며 느낀 것은 이런 건 다 중요한 게 아니라는 것이다.

 

중요한 건,

1. 전체적인 필수 구현 사항을 파악하고
2. 무엇을 만들어야 하고
3. 어떻게 해야 하는지
4. 그러려면 무엇을 해야 하는지

등을 종합적으로 파악해서 기획을 촘촘하고 섬세하게 하는 것이 정말정말 중요하다고 느꼈다. 이 기획과 설계 단계에서 방향을 잘못 잡았거나 프로젝트에 대한 이해가 잘 안 되면 구현하는 단계에서 애를 꽤나 먹게 될 것 같다. 그래서 프로젝트, 기능, 기능을 구현하려면 어떤 것을 해야 하는지에 대한 이해가 필수적이라고 느꼈다.

 

 

또, 귀찮든 어쩌든 간에 와이어프레임을 최대한 구체적으로 만들어두는 것은 무척이나 중요하다. 감이 잘 안 오더라도 일단 만들어두고 구현하는 과정에서 자세한 부분의 살을 덧붙여가는 것이 옳은 방향이라고 생각했다. 물론 한 번에 정확한 방법과 방향으로 하는 게 베스트다.

 

 

 

(3) 완성된 코드를 다른 데에도 저장해두자

혹시 모르니까 Merge할 때 날아갈 수 있는 가능성을 염두에 두고, 본인이 작업했던 Branch에 Commit 하는 것 말고도 다른 레포지토리 같은 걸 만들어서 코드를 따로 저장해두자.. 정말 혹시 모르니까 여기저기에 마치 보험들 듯이 저장해두는 것은 정말 좋은 습관이자 안전한 행위인 것 같다. 나를 위해서도, 팀원을 위해서도.

 

 

 

4. 금일 소감

당장 내일이 시연 영상 제출이라 조마조마한 마음이 좀 크다. Merge를 하니 예상은 했지만 기능이 정상적으로 작동되지 않는 것이 있어서 그거 수정하고 에러 디버깅하고 다 되면 Redux로 리팩토링하는 작업해야 한다. 할 게 많고 기한도 급해서 얼른얼른 하고 시연 영상 기획도 빠르게 할 생각이다.

 

저번 팀 프로젝트는 4명 분량 3명이서 하고, 이번에는 2명이서 했다. 다음 팀 프로젝트는 나 혼자서 하는 거 아니겠지?... 혼자 하는 게 많아서 얻는 것도 꽤 있기야 하지만 나도 다른 팀들처럼 서로서로 모르는 부분 알려주고 도움 주고 하는 팀 플레이 해보고 싶은 마음이 좀 있다,,,,, 아무튼 남은 작업도 파이팅