우리팀은 정각 9시에 칼같이 줌으로 모인다. 첫 프로젝트때도 현재도 우리팀의 특징이라면 편안하고 좋은 분위기면서도 사적인 이야기는 아예(?) 하지 않고 프로젝트에 대해서만 이야기한다는 점이다. 하루종일 함께 얼굴을 보고 이야기 한지도 꽤 되었음에도 그렇다는점이 가만히 생각해보면 좀 웃기면서도 또 나름대로 만족스럽다. 오늘도 9시가 되자마자 팀원의 첫 대사는 '그럼 어제에 이어서 여기서 보면 될것같네요옹~?' 이였다! ㅋㅋㅋ 열정맨들이다. 열정맨들과 함께하니 나도 더 열심히 해야할 것 같고 막 그렇다. 좋은 영향력을 주는 팀원들이다.
어제에 이어 사용자에게 필요한 화면을 추가하고 구체화시켰다.
첫 프로젝트때 컴포넌트를 어떻게 나눌것인지 미리 짜두지 않은채로 코드를 짜서 아쉬움이 있었기에 이번에 우린 미리 컴포넌트를 나누고 또 어디를 <div>태그로 묶을 것인지에 대해 정해두기로 했다.
Figma 작업창에 동시에 접속할 수 있는것이 참 편리하고 좋았다. 4명이서 각자 몇몇 페이지를 맡아 그렸는데, 내가 만든 네모박스를 다른 팀원이 슬쩍 복사해가는것이 웃겨서 나도 팀원의 박스를 복사해 오기도 하고 웃으며 재미있게 작업했다. 모두가 각자의 분량을 다 그린뒤엔 모두가 함께 페이지 하나씩 보며 이 부분을 컴포넌트로 해야할지 말지에 대해 회의했다.
마이페이지 설정 페이지는 재사용되는 것이 아니기에 컴포넌트로 두지 않기로 했다. 왠지 모르게 찝찝하지만
그렇다면 메인페이지에서만 나타나는 네비바의 '닉네임,프로필사진의 드롭다운' 또한 컴포넌트로 두지 않아야할까?
리액트를 처음 배울때 리액트는 '컴포넌트 기반 라이브러리' 라고 배웠는데 그래서 나는 재사용이 되든 안되든 모든것을 컴포넌트로 나눠야한다는 입장이었고, 다른 팀원은 컴포넌트는 재사용 되는것에만 사용 되는것이라고 말했다. 또 다른 팀원 한분은 설정 부분은 컴포넌트로 두지 않아도 되지만 드롭다운이 있는 프로필 닉네임 부분은 있어야한다고 하셨다. 이유는 가독성이 좋기 때문이라고 하셨다.
컴포넌트를 나누는 이유는 뭘까? 정신없이 진도 나간다고 궁금해 하지도 않았는데 알고 써야할 것 같아서 오늘 일정이 끝나면 밤에 좀 공부해 봐야겠다고 생각했다.
component는 '구성요소' 라는 뜻을 가지고 있다. 각 컴포넌트들은 독립적인 기능을 지는 하나의 '소프트웨어' 로 취급할 수 있고, 이를 '모듈' 이라는 개념으로 설명할 수 있다. 그래서 이러한 '모듈' 단위의 개발은 재사용성과, 유지보수에 강한 장점을 지니고 있다. 재사용성의 이유도 있지만 유지보수의 이유도 있다는것을 알게 되었다. “UI를 재사용할 수 있고 독립적인 단위로 쪼개어 생각”할 수 있게한다. "컴포넌트는 독립적이며, 재사용 가능하게 만든 부품 조각들을 말한다. 리액트로 만들어진 홈페이지는 즉 컴포넌트의 조합입니다.
여기서 리액트가 무엇인지 좀 짚고 넘어가야할 필요성이 있는것 같다.
사용자의 View에만 초점을 둔 Facebook이 개발한 라이브러리다.
웹을 개발할 때, 헤더, 메인 콘텐츠, 버튼, 사이드바 메뉴 등을 만들텐데 리액트로 만들게 된다면 이 부분들을 하나의 컴포넌트로 묶어서 관리할 수 있다. 사이드바 컴포넌트, 헤더 컴포넌트 이런식으로 말이다. 컴포넌트로 만들어두었기 때문에 개발하다가 특정 부분에서 오류가 생겼다면, 그 컴포넌트만 수정하면 되고 코드를 간결하게 만들 수 있다.
프론트엔드에서는 지난 첫프로젝트에서 CSS만 사용했다면 이번엔 스타일컴포넌트를 사용하기로 했다. 또 props로 계속 내려 받는 것 대신에 redux를 이용하여 상태관리를 하기로 했다. 코드 짜는 기간에 들어가기전에 미리 공부를 해야겠다.
백엔드부분을 내가 잘 몰라서 자신있게 1:N로 해야할지 N:N로 해야할지 논의중에 내 의견을 이야기할 수 없었던 부분이 아쉬웠다. 시간이 여유롭지는 않더라도 틈틈히 백엔드 부분도 공부를 해서 내 의견도 내고 싶다는 생각을 했다.
우리는 배달비나눔 모집글에서 신청완료, 모집마감, 신청취소 세가지 경우가 있다는것에서 삼항식을 어떻게 써야할지 의문이 들었다. 그러다가 '이중 삼항 연산자'라는것이 있다는것을 알게 되었다.
let number = 0
if (isNumberOne) {
number = 1000
} else if (isNumberTwo) {
number = 100
} else if (isNumberThree) {
number = 10
}
이 코드를 이중 삼항 연산자로 써보면 이러하다.
const number = (
numberOne ? 1000 :
numberTwo ? 100 :
numberThree ? 10 : 0
)
처음엔 A가 true면 B가 true면 C 이런식으로 적혀있는 글을 보고 ?????? 뭔소리여대체 말장난인가?? 했는데 if문과 비교를 해보니 쉽게 이해할 수 있었다. 나도 어려운 내용이라도 쉽게 풀어 설명할 수 있는 사람이 되고싶다.
기획을 하는 단계에 있는데 나의 습관적인 말이 '사용자가 봤을때는 ~ 하는게 좋겠네요' , '사용자 입장에서는 ~겁니다' , '사용성면에서 어쩌구저쩌구' 라고 많이 말하는 나를 발견하게 되었다. 회의중 팀원들에게 '개발적으로 그부분은~ ', '그럼 불러오는 방식이 까다로워집니다' 라는등 말을 많이 들었기 때문이다. 예전에 기획자로 일을 할때 개발자에게 많이 듣던 말이다. 사실 지금은 사용자보다 기술이 더 중요한데 나도 모르게 '사용자 사용자' 하게된다.
나는 이제 개발자인데 조금은 더 개발자스럽게 생각하고 개발을 더 고려하는 내가 되고 싶다고 생각했다. 물론, 사용자를 위해 개발하는것이라는것을 안다. 결국엔 개발자가 되어도 철저히 사용자를 생각하는 개발자가 될것이다. 그러기위해서는 지금은 좀 내려놓고 더 개발적인 부분에 더 초점을 맞출 필요가 있다고 생각했다. 지금은! 내일부터는 기획을 할때 기획에 꽂히기 보다 어떻게 구현을 할지 큰그림을 머릿속으로 매순간 그려보아야겠다.