Bleeding edge

뒤 늦은 프로젝트 회고 본문

Side Project

뒤 늦은 프로젝트 회고

codevil 2023. 8. 20. 15:34

벌써 메셔에 들어온지 5달이 지났다. 첫 프로젝트를 마쳤을 때는 굳이 프로젝트에 대한 후기나 회고를 쓸 필요가 없는 것 같아서 노션에만 간단히 메모를 남겼었다. 하지만 두 번째 프로젝트가 끝났을 때 첫 번째  프로젝트가 끝났을 때 내가 부족했던 것과, 어떤 것을 더 개선할지를 메모하고 이전 프로젝트와는 다르게 잘한 것에 대해 메모할 필요가 있다고 생각했다.

첫 번째 프로젝트 Swalo

1. 개인적으로는 Nextjs가 익숙하지 않아서, Nextjs에서 지원하는 메서드들을 제대로 사용하지 못했었다고 생각한다.  

2. 피그마대로 컴포넌트를 설계하다가 폴더관리에 실패했다.

3. DTO 변경이 생겼을 때 수정하는데 시간이 너무 오래 걸렸다.

 

2번은 리팩토링을 통하여 개선을 하였고 1번 같은 경우에는 처음는 부족했었지만 사용하면서 익숙해졌고 필요할 때마다 검색을 통하여 해결하였다.

 

두 번째 프로젝트 Skipper

1. Api Mocking의 필요성을 느꼈다.

2. 프로젝트의 시나리오를 작성해서 어떤 interaction이 일어날지 설계하고 만드는 것이 필요하다고 생각했다.

3. Typescript를 더 공부할 필요성을 느꼈다.

 

첫 번째 프로젝트에서 부족했었던 부분은 많이 개선되었다. 특히 서버의 알고리즘의 변경으로 인해서 중간의 DTO가 바뀌는 것에 대한 것을 고려하고 작성하여 서버와의 합이 많이 좋아졌다. 하지만 처음에 값이 없는 경우에 이를 기다리는 과정이 중간에 발생해서 시간 loss가 있었다. 그래서 이를 개선하기 위해서 API mocking의 필요성을 느꼈다.

API mocking

처음에는 Swalo의 레포에 설정되었든 msw를 사용할 까 생각했었지만, 이를 그대로 사용하는 것은 많이 불편하다고 생각해서, Axios에 내장되어있는 메서드를 사용하여 해결하기로 하였다.

프로젝트 설계

프로젝트의 시나리오를 작성해서 Interaction을  생각하고 설계하는건 같이 일을 하던 PM님의 피드백 덕분에 알게된 사실이다. Skipper같은 경우 버전업을 세번 진행했었는데 세 번째 버전업에서 이를 적용하였더니,  프로젝트에서 state를 수정할일이 줄어들었고 상태관리가 많이 편리해진 것 같다.

TypeScript

개인적으로 너무 급하다보니 Type을 너무 간과하고 코드를 작성해서 불필요하게 여러번 중복되는 타입을 만들었던 것 같다.

 

 

후기

프로젝트에 대한 후기 이후 곧.. 수행 프로젝트에 대한 글을 작성할 예정이니.. 생략...