2주동안 달려서 첫번째 프로젝트를 무사히 마무리 했습니다.
지금까지 배운 모든것과 그 이상을 이용해서 만든 첫번째 프로젝트를 하면서 느낀점을 정리해보고자 합니다.

Think

기획의 중요성

모든 프로젝트가 그렇듯 처음에 기획단계를 거치게 됩니다. 저희팀은 다른 팀들에 비해 기획에 시간을 좀 많이 투자한 편인데요. 사실 팀장으로써 다른팀에 비해 기획시간이 길어질수록 불안감이 커져갔습니다. 기획을 빨리 마무리하고 개발을 시작해야할텐데 우리는 언제 개발 시작하지? 라는 생각이 점점 커져갔습니다. 하지만 프로젝트 후반 계속해서 변경되는 개발 일정에 그 전에 세워놓은 개발 일정과는 좀 다르게 흘러갔습니다. 하지만 프로젝트를 마무리하고 나는 생각은 '기획한 의도랑은 좀 다르게 개발했지만 그때 꼼꼼하게 안해놨으면 터졌을수도 있겠다' 였습니다.

비록 2주라는 짧다면 짧은 기간동안 프로젝트를 진행했지만, 우리가 무엇을 할것인지를 명확하게 정하고, 목표에 도달하기 위해 우리의 시간과 자원을 고려해서 계획을 짜는일은 정말 중요하다고 느꼈습니다.

팀플레이

저는 페어프로그래밍을 하면서 가끔 답답한 느낌을 받을때가 있었습니다. 내가 생각한 코드를 바로바로 반영해보기 어렵다는것. 속도적인 측면에서 빠르게 진행하지 못한다는 점이 답답하게 느껴졌습니다. 그래서인지 혼자서 공부를 할때가 편하다는 생각을 했었습니다. 하지만 이번에 프로젝트를 진행하면서 팀의 중요성에 대해서 다시 느낄수 있었습니다. 답답한 점이 완전 없진 않았지만 그것보다 장점이 훨씬 많았던것 같습니다.

팀으로 프로젝트를 진행하면서 가장 좋았던 부분 중 한가지는 바로 '지원사격'이었습니다. 누구나 부족한 점이 있고, 내가 미처 몰랐던 부분, 보지 못했던 시야를 팀원들이 채워주었습니다. 혼자서라면 삽질했을 시간을들 팀원들과 함께 나누면서 빠르게 문제를 해결해 나갈수 있었습니다.

누구나 한번쯤 조별 수행평가 혹은 조별과제를 해보신 경험이 있으실 텐데요. 그러면 일이 공평하게 배분되는 일은 상당히 어렵습니다. 심지어 한명이 도맡아서 일을 진행하기도 하는데요. 일단 이번 프로젝트에서는 그런식으로 한명이 모두 한다는 것은 불가능했습니다. 혼자하기에는 압도적으로 많은 양의 개발을 해야하고, 자신의 파트를 나누지 않고 일을 진행하면 자칫 꼬이거나 잘못된 점을 인지하지 못하고 삽질을 가능성이 클것입니다. 팀원과 함께 개발을 한다는 것은 노를 젓는것과 비슷합니다. 모두가 노를 젓지 않아도 배가 앞으로 나아가기는 합니다. 하지만 똑바로 나가지는 못할것입니다.

Front-end

저는 이번 프로젝트에서 프론트엔드를 맡았습니다. 사실 처음 프로젝트를 진행하기 전 백엔드를 해보고 싶었습니다. 화면을 예쁘게 꾸미는것 보단(물론 프론트엔드가 화면을 예쁘게만 하는것은 절대 아닙니다. 기능적으로도 굉장히 복잡하고 할것이 많습니다) 논리적으로 퍼즐을 푸는듯한 백엔드가 조금 더 저에게 맞다고 생각했습니다. 하지만 프론트엔드도 웹개발자가 되기위해 필요한 영역이고, 백엔드를 한다고 해도 프론트엔드의 고충(?)을 이해하기 위해 프론트엔드를 경험해 봐야겠다고 생각했습니다. 그래서 다음 4주 프로젝트때 백엔드를 해보기로 생각하고 이번 프로젝트에서는 프론트엔드에 지원했습니다.

프론트엔드 개발을 하면서 React를 사용했는데, 가장 크게 느낀점은 어떤 작업을 실행하는 '시점'이 중요하다는 것입니다. 우리가 의도한대로 화면을 보여주기 위해서는 언제 어떻게 어떤 함수가 실행되서 화면을 렌더링 시킬지가 중요했습니다. 그러기 위해서는 라이프사이클에 대해 더 많은 지식과 이해가 필요하다고 생각했습니다.

프론트엔드라면 꼭 해야하는 CSS도 저에게는 넘어야할 산이었습니다. 개인적으로 디자인에 대해서 재능이 있다고 생각하지 않았습니다. 그래서인지 CSS로 화면을 구성하는것 자체가 쉽지 않았습니다. 하지만 어쨌든 이모양 이꼴로 프로젝트 발푤르 할수는 없으니 화면을 꾸미기 위해 CSS를 공부하고, 다른 디자인도 찾아보며 참고했습니다. grid등을 사용하고 사용법에 어느정도 익숙해지면서 CSS의 작업 속도가 빨라졌고 생각보다 재미있다는 생각이 들었습니다. 덩달아 저의 디자인 능력도 같이 올라가는 생각도 들었습니다.

무엇이든 해보기 전에는 어려워 보이고 힘들것 같지만, 막상 해보면 해볼만한 것들이 꽤 많다는 사실을 다시 체감했습니다. 개발뿐만 아니라 이러한 태도는 인생을 살아가면서 많은 도움이 되기 때문에 개발경험 이상의 좋은 경험을 얻어간것 같습니다.

ISSUE

다음으로 개발을 하면서 겪었던 이슈에 대해 몇가지 정리해보고자 합니다.

axios

이번 프로젝트를 진행하면서 비동기 요청을 axios를 사용하여 진행해보기로 했습니다. axios를 이전에는 사용해본적이 없기 때문에 슥 찾아보고 fetch 처럼 사용하면 되겠지 하는 생각에서 문제점이 발생했습니다. axios는 response 데이터가 data라는 객체에 감싸져서 오기때문에 이점을 유의해야 합니다.

axios.post(url,doSomthing)
.then((response) => {
  console.log(response.data)
})
.catch((error) => {
  console.log(error)
})

이와같이 사용해야 했는데 그걸 모르고 개발을 진행하고 테스트를 했는데 함수가 정상적으로 작동하지 않아 문제가 발행했었습니다. 다음부터는 안써본 라이브러리를 사용할때는 공식 문서등을 최소 한번은 정독하고 사용하는 습관을 들여야 할것 같습니다. 기본적인 태도이면서 무심결에 지나가 발생한 문제였습니다.

redux

기존에 redux를 배우기는 했지만 실제로 사용하려고 하니 막막했습니다. 어떻게 사용해야 하는지 감이 잘 잡히지 않았고, action과 reducer등이 정확이 어떤 역할을 해주는지 알지 못했습니다. 이번 프로젝트에 진행하면서 redux를 사용하면서 막연히 redux를 사용하면 한번에 관리할 수 있으니까 state는 다 때려박으면 되겠지? 라고 생각하고 진행하다가 후회는 아무리 빨라도 늦는다는 사실을 다시 느꼈습니다. redux를 사용하면 모든 컴포넌트에서 손쉽게 store에 접근해서 데이터를 사용하고 업데이트 할수 있는것은 맞지만 때에 따라서는 redux에 무작정 state를 넘겨버리는것이 비효율적일때가 있다는 것을 생각하지 못했습니다. 예를 들면 로그인 input값인데 redux에 input값을 넘기고 데이터를 전송할때 다시 불러와서 사용하는게 썩 좋지 못하다는 생각이 들어 리팩토링을 했습니다.
미래를 보는 능력이 있다면 좋을텐데.. 머리가 좋지 못하면 몸이 고생하는거죠 ㅎ

eslint(Airbnb)

프로젝트를 진행하면서 전체적으로 코드의 일관성을 위해 eslint를 사용했습니다. 지나고 나서야 확실히 깔끔한 코드를 볼수 있지만, 스페이스바 하나도 무자비하게 빨간줄을 그어버리는 eslint 덕분에 익숙해지는동안 한숨이 푹푹 나왔습니다. 무엇보다 저는 주로 들여쓰기를 할때 탭(tab)을 사용하는데 eslint - airbnb는 더블 스페이스를 사용해서 쉽지 않았습니다... 역시 개인취향따위 무시해버리는 무자비한 eslint 입니다(lint 스타일 설정을 잘 알아보고 합니다..airbnb 너무 깐깐 읍읍)

하지만 eslint를 사용하면서 얻은 예상치 못한 수확은 PropType이라는 개념에 대해 할게된것인데요. typescript를 사용하지 않았지만 type을 고정할수 있어서 이런 부분에서 큰 이슈없이 잘 진행할수 있었던것 같습니다.

Form

로그인과 회원가입 화면에서 input 값에 required를 사용하기 위해 from으로 컴포넌트를 감쌌는데 로그인이 안되고 계속 로그인 화면으로 리다이렉트 되는 이슈가 있었습니다. 저희는 SPA로 개발을 하기 위해 비동기 요청을 보내야 했는데요. 조금만 생각해보니 앗! form은 동기 요청이잖아! 하고 생각이 나서 e.preventdefault()를 이용해서 이슈를 해결할수 있었습니다.

submit = () => {
  e.preventdefault();
  doSomething.....
}

<form>
  <button type="submit" onClick="submit">제출쓰<button>
</form>

e.preventdefault를 사용하면 form에서 동작하는 submit 이벤트를 실행하지 않습니다.
여러분은 꼭꼭 까먹지 말고 사용하시길 바래요 ㅎ

Search by name

어떤 특정한 사람의 정보를 보기 위해 이름으로 검색하는 기능을 만들었는데요. 처음에는 검색버튼을 클릭하면 인원리스트를 전부 다시 반복문을 돌려 검색한 이름의 사람을 다시 렌더링 하는 방식으로 만들었는데, 생각을 해보니 setState가 발생하면 화면이 다시 렌더링 되기 때문에 이름 검색 input에 값이 있으면 해당 이름을 렌더링 하게하고, 없으면 인원 리스트 전체를 렌더링 하게 하여 조금 더 깔끔한 코드를 만들수 있었습니다.

지금까지 2주 프로젝트를 하면서 느낀점을 끄적여봤는데요. 글을 쓰면서도 참 배운것도, 느낀것도 많았던 프로젝트였던것 같습니다. 이제 다시 시작하는 4주프로젝트도 기대가 되고 프로젝트가 끝났을때 저의 모습도 기대가 됩니다.