[파이날 회고] 북담

========================

본 글은

IT 언론 저널 'OUTSTANDING' 처럼

Mobile First 지향합니다.

 

그래서 한 줄에 한 구문(문장)만을

적으려고 합니다.

========================

"신뢰받는 개발자가 되자"

인성, 품성, 성품, 실력을 갈고 닦아

신뢰받는 개발자가 되자.

 

프로젝트 기간 : 2021. 12.27 ~ 2. 25

프로젝트명 : 북담

프로젝트 Notion : https://bit.ly/3B5gPAB

 

인트로 페이지

 

작성하기 페이지

 

Good work

1. (First 프로젝트와 비교해)

상대적으로 프로덕트 기획을 꼼꼼하게 한 점

중요도 : ★★★★★****

 

퍼스트에서 미진한 기획으로 고생을 많이 하였다.

(예, 개발자가 기획되지 않은 영역은

상상하면서 프로그래밍 하는 등)

 

전문가들이 해야 한다고

강조하는 이유가 다 있더라.

 

하지만 주먹구구는 우리의 본능이다.

개발은 본능을 거스르는

고도의 사고와 의도적인 관리가 필요한 영역.

 

파이날에서는

Wire Frame, Prototype을 활용하여

흔들리지 않는 편안함을 느껴보았다.

 

모바일 우선으로 기획을 하여서

모바일과 데스크 대응이 모두 가능했다.

 

기획 단계에서 미리 필요한

컴포넌트와 props를 생각하여

프론트엔드 기획에서 작업 로드를 줄였다.

 

 

2. 문제 해결을 위한 적극적 의사 소통과 해결

중요도: ★★★★★

 

팀원 모두 반나절 이상을 소비하며

해결하려던 에러가 있었다.

 

Feedpage에서

사용자의 아이콘을 클릭하면

해당 사용자의 정보를 볼 수 있는

Userpage로 이동하게 된다.

 

이때 페이지의 주소를 사용자 아이디로 하게 되고

사용자의 정보를 담고 있는

객체 followInfo를 전달해서

Userpage에서 해당 정보로

업데이트가 되어야 한다.

(/userpage/logoses ==> 뭐 이런식이다.)

 

이때 useHistory 함수를 사용했는데

일반적으로 상태를 변경시키는

setState로 변경하고

 

history.push를 사용해도

페이지의 상태값 변경은

페이지가 모두 렌더링되고 난 다음

setState가 적용되는데

 

렌더링 완료되기 전에 history.push로

페이지 이동을 하니

빈값만 상태함수에 전달되고 있었다.

 

(Error-Handling 보기 ↓↓)

https://github.com/codestates/BookDam/issues/138

 

팀원 4명이 모두 달라 붙었고

이미 시간은 새벽 1시를 넘어가고 있다.

결국에는 모두 해결하지 못하고 헤어졌지만

결국에는 해결이되었다.

(비동기 처리 setState를 버리고

상태값을 직접 전달하는 방법으로)

 

이외에도 부모 컴포넌트의 상태값을

변경시켜주는 핸들링 함수를 활용하는 문제,

깃 커밋과 머지 관련 문제들처럼

개인이 혼자서 확신없이

해결해야 하는 문제들을

팀원들과 함께 해결하였다.

 

이러한 경험은

'방법은 있다.

끈기와 함께 할 이들이 있다면

해결된다'는

그런 확신이 나에게 생겼다.

 

 

3. 과욕을 부리지 않음 점

중요도: ★★★

 

퍼스트 프로젝트에서

2주간의 짧은 시간을 고려하지 못하고

태스크의 범위를 많이 잡았던 점이

결국에는 레포를 공개하지 못하게 발목을 잡았다.

 

그래서 파이날에서는

기술적 난이도와 실력을 객관화하여

프로젝트의 완성도 있는

(개인적으로 공개 가능한) 퍼포먼스를

내려고 팀원들과

정말 많은 의견 교환의 시간을 가졌다.

 

좋은 의견이 많이나왔지만

위와 같은 기준에 의거하여

cut 당하는 점이 슬프기는 하였다.

 

하지만 한정된 시간과 자원을 가지고

결과를 만들어 내는 것에 대한

의식은 꼭 필요한 것이라고 생각한다.

 

Bad Work

1. 그래도 여전히 아쉬운 부분은 기획이다.

와이어와 프로토로

정밀하고 디테일한 기획을 한다고 했지만,

그래도 모두들 이구동성으로

기획이 아쉽다고 한다.

 

개발자인데 기획이 아쉽다고 느끼는 점이

뭔가 혼란스럽다.

결국 개발자도 기획의

바탕 위에 작업을 한다.

 

 

2. 효율적인 코드 구현을 잘 했는지에

대한 철저한 검토가 없었다는 점

위의 setState는

이번 프로젝트의 한 개의 컴포넌트에서

선언된 상태값들이다.

 

컴포넌트도 많은데 

그 안에 선언된 많은 상태값과 함수들

React를 배웠고 배운대로 구현하였지만

효율성이라는 관점에서

이렇게 하는게 맞는지

추가 검토하지 못하였던 점이

아쉬운 부분이다.

 

이렇게 많이 선언된 값들은

프로그램의 성능을 저하시키는 요소일 것이며

최적화를 위한 노력들이 남겨져 있으리라

예상된다! 공부하자!

 

(공부자료: React 성능 최적화 보기 ↓↓)

https://uzihoon.com/post/ef453fd0-ab14-11ea-98ac-61734eebc216

 

 

3. (개인적으로) 새로운 기술과 라이브러리에 대한

학습이 부족했던 점

나는 퍼스트 프로젝트에서 백엔드를 하였고 

파이날에서 프론트엔드를 담당하였다.

 

그러다보니 다른 프론트엔드 분들은

퍼스트에서 기본 CRUD를 하고

파이날에서 응용을 하시는데 비해

나는 파이날에서 기본 CRUD와

CSS, 퍼블리셔 작업을 구현할 수 밖에 없었다.

 

그래서 다른 분들은 무한 스크롤,

Swiper, React 상태관리 심화 등을

학습하고 적용할 때 

Redux, Styled component, Axios 등

기본적인 내용을 다룰 수 밖에 없었다.

 

그나마 전역 상태 관리 React-redux 환경설정

학습을 상대적으로 충분히 할 수 있어서

다행이라고 생각한다.

 

전역 관리는 무조건 해야 한다고 생각한다.

안 하고 나중에 소위 빵구난다.

 

conclusion

1. 협업하는 과정에서

사람을 잃으면 안된다고

다시 한번 생각한다.

 

일 중심이 아닌

사람 중심의 생각을

가지고 어떻게 하면

조화롭게 할 수 있는지

고민하자.

 

2. 일을 하며

다른 사람들에게 지지를 

얻을 수 있도록

늘 공부하고 겸손하자.

같이 해야 멀리 갈 수 있다.

 

3. 개발자 하기 참 잘했다.