First project 마지막

Vorhandenheit ·2022년 4월 13일

목록 보기

39/63

First project 마지막

첫 번째 프로젝트 'TILog'가 끝났습니다. 다같이 모여서 각자 만들걸 발표하는데, 완성되지 못한 걸 꺼내는 느낌이란.. 다시는 이런 일이 벌어지지않게 해야겠다. 다짐한 순간이었습니다.
프로젝트 중간에 잘하면 완성하지못하겠다라는 생각이 들어서.. 잠을 더 줄여가면서 했는데도 역부족이였습니다.

1. 이유

프로젝트 중간에 펼쳐진 일들로 인해, 어떻게 해야되나 갈팡질팡했던 이유가 컸습니다.

(1) 갈팡질팡

팀원 중 한명이 클론코딩을 해왔고 리덕스를 안쓰는게 좋겠다 라고 말했는데, 다른 팀원이 클론코딩을 해오셨고 리덕스 마저 들고왔을 때(쓰는 이유에 대해서 알고있었고 다른 코드를 가지고 오다보니 그 안에 기술마저 같이 들고와야했기에), 의욕이 한번 꺾였습니다.
그래도 어쨌든 프로젝트 진행이 있었고 리덕스 상태관리를 맡아서 해주신다고 하셨기 때문에, 다시 마음을 다 잡고했는데 여기서 깃 허브 에러가 발생했습니다. 단순한 에러가 3일이나 잡아먹게되어 1주일이나 되는 시간이 허망하게 날아가게되었습니다. 그동안 다른 팀 한명이 분전했으나 만들어가면 갈수록 부족한 부분이 이제 드러나기 시작했습니다.
이때부터 이미 만화처럼 암울한 기운이 돌기시작했습니다. 이때 알게된 사실이 팀원 한 분이 거의 도움이 안된다는 사실이었습니다. 하지만! 해야죠! 그래서 구성되어있는 틀에서, 필요없는 부분을 제거하고 틀을 다시 재구성하고, 이름을 수정하고, 필요한 기능을 찾아서 넣고.. 제가 상태관리를 맡기로했었지만 프론트엔드로 역할이 암묵적으로 전환될 시점입니다. 다른 한분이 백엔드를 맡아서 데이터를 확인해주고 하다보니 프로젝트 마감기한이 다가오고있었습니다.

(2) UI에 대한 방심

처음 들어갈때만 하더라도 router작성하고 데이터가 어떻게 넘어오는지 확인만된다면 만드는 건 끝이지! 라고 생각했지만, 일이 이렇게 되고나니 그리고 프론트엔드를 직접 맡아서 해보고 나서야 이게 아니란 걸 알게됬습니다.
프론트엔드에도 router처럼 틀이 있고 그걸 먼저 만들어야 원활하게 백엔드와 연결할 수 있다는 점을요.

2. 다음 프로젝트

그래서 다음 프로젝트 때는 이렇게 해야겠다라는 생각이 들었습니다.

(1) 기획 단계

먼저 저번 기획단계에서는 프로토타입만 만들어서, 흐름만을 보이는데 초점을 맞췄습니다. (와이어프레임이라고 만든게 프로토타입이 되었지만) 하지만 와이어 프레임이 없으니 UI 틀을 만들 수가 없었습니다. 아마도 다들 그런 생각이 없었던 거겠지요. 그래서 다음번에는 와이어프레임을 다같이 만들어야겠다 생각했습니다.

두 번째는 와이어프레임을 작성했다면 팀장은 이제 스켈레톤 파일을 제작해야된다는 겁니다. 틀을 만드는게 늦어지면 모든 프로젝트가 딜레이됩니다. 틀이 완성되어있다면 한 페이지에서 에러가 해결중이라면 다른 페이지에서 프로젝트를 진행하여 비동기작업처럼 일을 해결할 수 있다는 겁니다.

세 번째, 프로토타입을 만들 때 흐름에만 초점을 맞췄는데, 다음번에는 API와 거기 넘어가는 데이터도 다 넣어서, sequelize-cli를 만들 때 어떤 데이터 타입을 넣을지 공유하는게 필요하다는 것이었습니다. 백엔드에 맞겨만 놓았는데, 막상 코드 칠 때는 데이터를 바꿔야하는 경우가 계속 발생하였고 한명에서 그 모든 경우의 수를 생각못하고 다같이 해야 정확히 집고 넘어갈 수 있다는 겁니다.

네 번째, 프로토타입을 제작할 때, 어떤 기능을 넣을지 애기를 합니다. 처음에 그 기능에 대해서 애기를 하고 다음에 만날 때는 그 기능은 어떤 tool을 사용해서 라이브러리를 사용해서 사용할 수 있는지 조사를 해오고 사용할 수 있는지 테스트 하는 게 필요했습니다.
코드를 작성할 때, 그 기능에 대해서 공부하고 있으니 일정히 뒤로 미뤄졌습니다. 코드를 작성할 때는 작성하고나서 에러를 잡는거만 하도록 합시다!

다섯 번째, 기획 단계에서 팀장이 할일이 회의할 껄 생각하고, 위키 작성하고 마일카드 작성하고..다른거 확인하고 할께 이리저리 너무 많았습니다. 그러다보니 다른 디테일한 부분까지 신경쓰지 못했습니다. 그래서 다음 번에는 마일스톤 작성과 로고 깃허브 세부적인 기능 기록을 맡겨야겠다 싶었습니다. 이렇게 해야 전체적인 일정과 이부분에서 시간을 썻을 때, 어느정도 시간이 남겠다라는게 전체적인 공유가 되겠구나 싶었습니다

여섯 번째, 팀 규칙 찾아보고, 우리에게 맞는 규칙이 무엇일까 찾아보기

(2) 코드 작성

기획이 끝났다면 이제 코드작성에 들어가야합니다. 만약 계획대로 되었다면, 스켈레톤 파일이 나오고 프론트엔드는 이제 css로 페이지를 꾸미기 시작하고 백엔드는 sequelize-cli를 작성하고 저는 리덕스 상태관리를 시작할 것입니다.

그럼에도 불구하고 에러가 발생합니다. 데이터 타입이 맞지않습니다. 그러기 위해서 생각한게, 간단한 데이터와 기능정도는 틀에 대해 공유하는게 좋다고 생각했습니다. 갑자기 리덕스를 쓰게 되었을때, 저는 리덕스가 뭔지는 알고있었지만 리덕스 툴킷이 뭔지, 어떻게 작동하는지 몰랐습니다. (리덕스를 사용할려다 이틀을 잡아먹었지요) 그러다보니 일일히 데이터를 가지고오는 새로운 객체를 부탁할 떄 다른 사람에게 부탁해야했었습니다.
백엔드는 지금 당장 처리해있는 일만 해야됬는데, 일이 추가되는 경우였습니다. 이런일이 발생하지않기 위해서 리덕스를 쓴다고 한다면 안에 어떠한 부분에서 오류가 생겼는지 알기 위해, 수정할 부분이 생겼을 떄 수정하기 위해서 해당 데티어가 어떻게 넘어오는지 이해가 필요했씁니다. 그러기 위해서는 '좋아요'처럼 간단한 걸 하나 직접 cli부터 reducer까지 작업해본다면 어떻게 돌아가는지 다 공유할 수 있고 , 처음에야 다루기위해서 고생하겠지만 이해하고나면 다같이 더 빨리 작업할 수 있겠다는 생각이 들었습니다. 그리고 나중을 생각했을 때, 프로젝트 중 다른 한명의 팀원이 부득이하게 빠지게된다면? 그 사람 일이니까 알아서 되겠지라는 생각은 통하지않겠지요..

그럼에도 불구하고 빵꾸가 생겼다! 이번에도 이것 때문에 시간을 잡아먹었습니다.( 못하겠으면 못하겠다고 빨리 말해주면되는데....) 세부적으로 나눠놓은 뒤에, 해당 부분이 완성되지않았다면 왜 완성되지않았는지 언제까지 완성할 수 있는지 조정하는게 필수적이었습니다. 마냥 기다리고 있으니 계속 다음 일이 뒤로 미뤄지니 꼭 물어보고 팀원이 하는 일으르 체크해야한다는 사실을 깨달았습니다.