[으라챠피디아] 프로젝트 최종 회고(2)
- 목차
6. DB를 사용하지 않고 model 데이터를 만들어 데이터를 직접적으로 변경한 느낀 점
mysql을 사용한다면 data를 변경할 때 sql query를 통해 데이터를 수정한다.
하지만 이번 프로젝트에서는 db를 사용하지 않았기 때문에 query를 사용하지 않고 js를 통해 내가 직접적으로 data를 변경해줘야 했다.
이 과정에서 model에 직접적으로 접근할 수 있는 권한을 가진 함수들을 dao 영역에 넣어놓고 최대한 model이 무결하게 관리되도록 신경을 많이 썼다. (무결한 다오씨..ㅎ)
모든 함수들이 최대한 순수함수가 되도록 노력했다. (기존 model값 수정이 아닌 재할당을 통해 아에 새로운 배열을 주는 방식)
이 과정을 통해 순수함수의 중요성과 배열 메소드들을 활용하며, 상황에 맞는 배열 메소드를 알게 되었고(find) db를 사용했을 때와는 또다른 js의 즐거움을 느낄 수 있었다.
또한 이렇게 구현하고 보니 몽고db의 메소드들과 유사하다는 느낌이 들어서 db를 마치 직접 만든 것 같다는 착각(?)이 들어서 더 재미있었다.
7. javascript는 꼭 타입을 다시 한번 확인하자.
javascript는 동적 타입 언어이기 때문에 내가 처음 원했던 타입의 값이 그대로 결과까지 이어진다는 보장이 없다.
하지만 나 혼자서 js 혹은 나를 너무 믿고 타입 체크를 하지 않으면 예상치 못한 에러로 또다시 삽질의 늪에 빠질 수 있다.
- Path Variable을 통해 들어온 값들은 모두 문자열이 되었지만 이를 파악하지 못하고 왜 if 절에서 걸리지 않나 한참을 해맸다.
- 서버에서 호되게 당해놓고, 클라이언트에서도 dom 프로퍼티 value 값으로 들어온 값이 숫자라고 굳게 믿고 또다시 삽질을 했다.😭
누구나 실수는 할 수 있다. 더구나 나는 배우는 학생이니 실수해도 좋다. 하지만 이를 반복하는 것은 결코 좋지 않다. 앞으로는 목숨처럼 타입을 한번 더 체크하도록 하자.
8. 다른 사람의 코드 읽는 연습을 하자.
프로젝트는 결코 혼자 할 수 없다. 개발자로서 협업은 선택이 아닌 필수이다.
서버 작업을 완료하고 클라이언트 작업에 들어갔을 때 다른 팀원들이 상태 관리 및 spa를 위한 구조를 완성해놓은 후였다. 그 위에 내가 맡은 기능들을 작업했어야 했는데, 다른 팀원들의 코드를 읽고 해석하는 데에만 꽤나 많은 시간이 들었다.
내가 회사에 들어가면 코드를 작성하는 시간보다 다른 코드를 읽는 시간이 더 많이 들 것이다.
다른 사람의 코드 읽는 연습을 통해 내 개발 시간을 더 확보하고, 더 좋은 코드를 작성할 수 있도록 노력하자.
여담으로 다른 사람의 코드는 나보다 그 코드의 작성자가 훨씬 잘 알고 있기 때문에, 다른 코드와의 작업에서 에러가 난다면 혼자 끙끙 앓기 보다는 빠른 help를 통해 그 에러를 잡자. (작성자에게 물어보면 정말 별게 아닌 문제가 많았다.)
9. auth 인증을 위해 로컬스토리지, 쿠키, 세션 중 어떤 것을 사용할까?
로그인, 회원가입, 로그아웃 기능을 구현해야 했기 때문에 auth 를 구현하고자 했다.
짧디 짧은 나의 개발 지식으로 로컬 스토리지보다는 쿠키, 세션이 더 낫고 세션은 db에 종속적이기 때문에 쿠키를 선택하였다.
여기서부터가 재앙의 시작이었다.
자료를 찾아보고, 어느 것이 어떤 점에서 더 좋은지를 찾아보지 않고 쿠키로 결정하였고, 쿠키의 사용법을 제대로 찾아보지 않았다.
때문에 서버에서 쿠키를 전달해주면 이를 관리하는 것은 클라이언트라는 오해가 생겨버렸다.
auth를 위해 클라이언트가 요청시 header에 본인의 쿠키를 가져와서 담아 보내도록 코드를 짰고,
로그아웃시에도 클라이언트 본인이 자신의 쿠키의 만료기한을 덮어씌어서 삭제하게 하였다.
설상 가상으로 이 과정에서 예상치 못한 에러가 발생했고 (쿠키 삭제시 path가 달라 루트 페이지가 아닌 곳에서는 해당 쿠키를 가져오지 못하는 것), 프로젝트 마감 기한이 별로 안남았기 때문에 빠르게 구현할 수 있는 로컬 스토리지로 변경하였다. 변경 과정에서 들인 시간도 결코 무시할 수는 없는 시간이다.
결국에는 로컬 스토리지 보다는 쿠키를 사용하는 것이 맞는 방향이라는 것을 깨닫고, 다시 쿠키로 경로를 바꾸었다.
이때부터서야 다시 로컬 스토리지, 쿠키, 세션의 차이를 제대로 비교하게 되었고,
쿠키를 주는 것도 서버, 삭제하는 것도 서버라는 사실을 알게 되었다. (쿠키는 알아서 header로 보내진다는 것도)
이것을 알고 구현을 시작하니, 그동안 삽질의 시간이 무색할 정도로 작업이 빨리 끝났다.
개발 방향을 정할 때, 내가 선택할 수 있는 선택지가 무엇이 있고, 그들은 무슨 차이가 있으며, 어떤 이유(장점)때문에 내가 그것을 선택했는지 에 대한 고민의 시간이 없었기 때문에, 처음에 쿠키로 결정했지만 사용법도 제대로 몰랐고, 그것이 막혔을 때 해결하려하기 보다는 더 쉬운 다른 선택지를 택하는 아주 미련하고 멍청한 행동을 한 것이다.
이러한 삽질의 시간 덕분에 쿠키, 세션, 로컬스토리지의 차이는 정확히 알게 되었지만, 이런 행동을 한 점에 대해서는 꼭 짚고 반성하고 넘어가야 한다.
앞으로는 꼭 위의 과정을 통해 선택지를 정하고, 오류가 났을 때 선택지로 회피하지 않고 내가 이 선택지를 선택한 이유를 되짚으며, 정확한 원인을 파악하고 해결해 나갈 것이다.
10. 협업에 git 을 적극 활용하며 느낀점
이번 프로젝트 전까지는 협업 도구로서 git을 사용한 적이 없었다. (개인 프로젝트, 블로그 용으로만 사용)
git 이 인기가 많은 가장 큰 이유가 소스 코드를 버전으로 관리하고, 다른 사람들과 협업할 수 있다는 것이었기 때문에 git을 협업해서 사용한 경험이 없다는 아쉬움이 컸다.
다행히도 이번 프로젝트 덕분에 협업 도구로서 git을 사용할 수 있었고, merge 관리자의 역할을 맡은 덕분에, merge시 conflict를 해결하는 연습도 많이 할 수 있었다.
이전에는 git stash를 몰라서 다른 브랜치로 이동하고 싶을 때 의미없는 commit을 했었는데, 이제는 코드 임시 저장인 stash 명령어도 잘 활용하고, conflict 에러가 나면 두려워하지 않고 에러를 해결할 수 있는 자신감이 생겼다.
협업 도구로서 git을 사용해보니, git 없으면 서로의 소스코드를 어떻게 합쳐야 할지 감이 잡히질 않을 정도로 git의 중요성을 알게 되었다.
다만 merge시 conflict가 전혀 두렵지 않은 것은 아니기 때문에 최대한 pr을 작게 보내 merge를 작게 쪼개서 하는 것이 좋다고 생각한다.
또한 git project 기능인 칸반보드, issue, milestone을 활용하여 애자일 프로젝트를 수월하게 진행할 수 있었다.
초반에는 pr 작성시, 작업 내용을 최대한 구체적으로 작성했지만, 시간이 지날수록 개발 시간에 쫒겨서 pr을 제대로 작성하지 못했다는 아쉬움이 있다. 코드리뷰 또한 많은 시간을 들일 수 없었어서 매우 아쉽다.
다음부터는 개발 시간에 pr 작성시간, 코드 리뷰시간을 염두해두고 마감 기한을 설정하도록 해야겠다.
11. 최종 회고 및 아쉬운 점🤔
팀원들 중 나만 유일한게 node 프로젝트 경험이 있어서 시간상 빠르게 개발하기 위해 나 혼자서 서버를 개발했다.
3일간 서버를 개발하는 동안 다른 팀원들이 SPA, 라우팅, 상태관리를 만들어놓았고,
아무래도 이 부분이 리액트와 굉장히 밀접하기 때문에 이 부분에 참여를 하지 못한 점이 매우 아쉽다.
다음 프로젝트에서는 클라이언트의 개발 환경 구축(SPA, 라우팅, 상태관리)에 꼭 직접적으로 참여하고 싶다.
하지만 서버 api와 클라이언트의 fetch 함수, fetch한 데이터를 매핑해주는 것을 담당하며, 서버와 클라이언트의 소통과정이 어떻게 이루어지는가를 확실하게 이해하고 넘어갈 수 있는 시간이었다.
한달동안 todo list, ui component, 으랏챠 피디아 프로젝트를 하며, html/css의 퍼블리싱, dom 조작, 이벤트리스너 등록에 자신감이 많이 생겼고, 클라이언트 개발만의 매력을 느낄 수 있는 시간이었다.
앞으로도 꾸준히 지난 2달간의 공부(10to10)를 지속하며 더욱 더 성장할 수 있는 내가 되고 싶다🤩
