1차 다락방 프로젝트 구현 완료 및 피드백 사항

 

2달 간의 프로젝트 1차 구현이 마무리 되었다.

 

프로젝트 github 주소 : https://github.com/stophyeon/Darakbang.git

GitHub - stophyeon/Darakbang: 오픈 마켓 서비스

 

처음 재대로 시작한 프로젝트였고, 공부 기간 약 2달 만에 시작한 프로젝트였다.

막상 1차 완성을 하고 다시 돌아보니 아쉬움이 되게 많은 프로젝트였다.

 

혼자 독학하며 강의영상을 보면서 공부하던 때와는 정말 완전히 다르고 새로운 경험이었다.

협업이라는 자체에 처음이었기에 많고 많은 실수들도 거듭했다. 사실 어떻게 보면 쉬운 에러들을 접했는데 내가 늦어진다면 다른 협업자들의 시간을 뺏는 일이라고 생각했기에 급한 마음으로 진행하려다가 나온 에러가 너무 많았었다.

 

 

우선 프로젝트가 마무리 되고 코드 리뷰를 하면서 내가 받았던 피드백들이다.

 

1. 쓰지 않는 라이브러리가 너무 많아서 용량과 성능 저하

많은 로직과 코드들을 서칭하는게 우선이었고 내 프로젝트에 관한 것들을 잘 살펴보지 않은 내 패착이 가장 컸다.

그 중에서 이 라이브러리들이 가장 문제였는데, 테스트를 하기 전 코드들을 쓰면서 "이 부분에서 이 라이브러리를 쓰면 좋지 않을까?" 라는 생각에 너무 몰두한 나머지 내 package.json에 쌓인 의존성들은 너무 많은 용량을 차지했다.

특히 쓰지 않는 의존성 정리하는 부분을 케어하지 못 했던게 가장 컸다. 이 글을 쓰기전에 많은 라이브러리들을 지웠는데

내가 언제 설치했던 라이브러리인지 모를 정도의 라이브러리들이 많은 용량을 실제로 잡아먹고 있었다.

 

어떻게 보면 가장 쉽게 해결 할 수 있던 문제였지만 그만큼 내가 인지하지 못했던 점에서 더 아쉬운 부분이었다.

 

2. component에 SSR을 활용하지 않음

내가 생각하기에 가장 중요한 피드백이었다. 사실 Next.js를 공부하기 시작했을때로 돌아가 다시 보면 이런 실수를 하게 될까 싶을 정도로 정말 강조했던 부분이었는데, 이 서버 사이드 렌더링에 대한 개념을 달달 외우기만 하고 이걸 왜 쓰고 어디서 이걸 써야하는지에 대한 부분을 생각하지 못했던 것 같다. 

 

이 부분은 직접 적인 코드 리뷰에서 자세히 다뤄 보도록 하겠다.

 

3.  component간의 결합성이 너무 높음
- 기본적으로 하나의 component에는 하나의 함수를 정의하지만 현재 많은 함수가 하나의 component안에 있어서 하나의 component의 오류가 전체 오류로 번짐
- 폴더 구조화가 안되어 있어서 나오는 문제 api 호출 하는 코드를 분리 하자

- 기본적으로 개발을 할 때 각 요소간의 결합성을 낮추는 것이 정석

 

실제로 내 어떤 컴포넌트 안에는 api 호출 함수가 최대 4개까지 접해 있는 경우가 있었다.

컴포넌트 하나에 함수가 여러 개가 있을 때 에러가 나버리면 

하나의 함수 에러에도 컴포넌트 자체의 실행에 문제가 발생해버리기 때문에 세분화 시켜서 독립적으로 함수를 실행시켜야

오류 해결에 더 쉬울 것이기도 할 것이다.

 

그리고 내 프로젝트 폴더를 다시 봤을 때 직접적으로 내가 그때마다 개발했던 컴포넌트들을 잘 알아봤기에 괜찮다고 생각 했지만 다시 1차 프로젝트 마무리를 하고 나서 점검 했을 때 문제점들이 있었다.

 

1. 크게 크게 정리했지만 그 안에 또 다른 세분화된 컴포넌트들을 구분하기 힘들다.

2. 기본적인 폴더 구조를 지키지 않고 나만 알아 볼 수 있는 폴더 구조였기에 나중에 다른 프론트엔드 개발자와 협업시에

큰 개발속도 저하를 초래 할 수 있다.

 

 

그리고 이번 프로젝트에서 가장 큰 문제점이자 피드백인 부분은

 

코드를 볼 때 왜 이렇게 썼는지 알 수가 없다.

 

-> 왜 이렇게 썼는지 이유가 없어서
-> ★기능을 구현하는 것에 목적★이고 왜 이렇게 썼는지를 잘 모르겠다.
다른 방법들도 찾아보고 여기서 이걸 썼을때 더 장점이 무엇인가?
-> 이렇게 써야만 하는 줄 알고 그냥 쓴 것 같다. ★고민이 전혀 없다.★

 

사실 어떻게 보면 프론트엔드 개발 공부를 재대로 시작한지 12월 부터 2월까지 2~3달 정도의 기간으로 시작한 프로젝트였다는 변명이 살짝 있었다. 공부할 때 당시엔 내가 프로젝트에 재대로 된 코드의 성능을 고민 할 수 있을 거라고 생각했다. 막상 실제로 시작하고 나서는 개발 속도가 현저히 느리다는 느낌이 나 자신에게도 많이 받았고 그 개발 속도를 높히기 위해 선택했던건 

 

로직을 생각하기 -> 인터넷 서칭과 AI툴을 이용해서 코드 구현 및 리뷰

이 방법을 이용해서 개발을 하니 속도는 내가 하던 것과 다르게 몇 배 이상이나 빨라졌던건 사실이다. 하지만 중요한건 이 프로젝트는 다른 사람과의 "협업" 이었고 졸업 전시를 위한 프로젝트 였기에 프로그램의 개발 속도의 빠름도 물론 중요하지만 완성도를 올리는 것이 더 중요했다. 하지만 위 방법으로 개발을 했을 때의 문제점들은 이런 것 들이 있었다.

 

1. 구글링과 AI툴을 이용해 내가 생각한 로직을 구현한 것은 좋았지만 백엔드와의 소통 방식에서 문제가 나타나 위의 방법의 장점인 개발 속도는 빨랐지만 테스트 과정에서 너무 많은 시간을 잡아버렸다.

2. 구글링과 AI툴을 이용했을때 왜 이렇게 사람들이 쓰고 이런 방식을 택했는지, 지금 내가 하는 프로젝트에 맞는 방식인지, 다른 방식이 우리 프로젝트의 성능을 높혀 줄 수 있을지에 대한 고민을 전혀 하지 않았다는 점이다.

 

 

 

 

끝으로...

 

사실 이번 프로젝트는 프론트엔드가 혼자 였던 나를 위해 백엔드에서 많은 부분을 배려해준 프로젝트였다.

실제로 내가 기능을 만들어서 협업 하는 과정은 없었다고 봐도 무방할 정도로 내가 한 것은 Data Fetching 부분과 요청을 받아서 화면에 출력하는 정도와 디자인 구현 작업 뿐이었다.

 

많은 생각을 하게 된 피드백, 코드 리뷰였다. 개발자로서 나아가야할 방향성을 명확하게 다시 한 번 짚은 느낌이었고 많은 실수가 있었지만, 이 경험들이 버려질 경험들이 아니란걸 알려주셨고 나도 알기에 정말 좋은 프로젝트 였다.

 

개발자로 나아가기 위한 재대로 된 첫 프로젝트였기에 앞으로 두 번째, 세 번째 더 나아갈 프로젝트에 좋은 영향을 줄 프로젝트였다.

 

이제 앞으로 리팩토링을 위한 글 들을 쭉 써내려 갈 예정입니다.