프로젝트 실패 회고

오래간만의 포스팅이다! 새로운 도메인의 프로젝트를 처음 시작하면서 굉장히 바쁘게 보냈다.

이 프로젝트의 첫 업무는 거의 실패라고 할 수 있다. 아니 실패다. 3주 안에 끝났어야 하는 일을 한 달이 넘도록 해왔으며

아직 배포도 못한 상황이다.

 

레포를 클론받아서 한 달간 진행해 본 시점에 왜 이번 프로젝트가 오래 걸렸고 개발자로서 실패였는지 회고를 남긴다.

프런트엔드 개발자로서 오직 내가 스스로 개선할 수 있는 프런트엔드의 문제점만 뽑았다.

 

1. 2년 전 코드 그대로 개발, 기능추가시 useEffect 하나씩 추가하면서 새 기능 구현

22년 3월에 리액트 18버전이 릴리즈 되었는데, 프로젝트의 리액트 버전은 17.0.2 버전이다.

21년 3월에 릴리즈 된 버전을 마지막으로 사용하고 있었고 react-router-dom은 5 버전이다.

한 컴포넌트에 useEffect가 7~10개 정도씩 있었다. 내가 본 가장 심한 곳은 처음 들어가자마자 리랜더링이 91번 발생했다.

대부분의 코드는 2년 전에 마지막으로 작성이 되었고 그 뒤에 새로운 기능이 추가되거나

이슈가 생겨서 버그가 수정될 때마다 useEffect를 하나씩 넣어서 구현했다. 아마도 다른 개발자들도

시간이 없으니 과거의 코드를 파악하기보다는 useEffect를 추가해서 눈이 보이는 현상만 수정하려고 했던 것 같아서 아쉬웠다.

의존성 배열이 얽혀있어서 코드의 가독성이 매우 안 좋고 불필요한 리랜더링을 발생시켰고 기존 기능을 파악하기 어려웠다.

2. 5000줄짜리 common CSS, 스타일드컴포넌트, 인라인스타일,! important 남발

css는 첫 개발 시 기본 css로 작성이 되었다. 총 5000줄로 작성이 되어있었다.

당연히 다른 개발자들은 기존 css를 파악하기 힘들었을 것이다. 마찬가지로 일단 내가 수정하는 기능을 반영하기 위해

css 적용 우선순위를 고려해 inline스타일로 작성을 했을 것이다. 그리고 또 다른 개발자는 styled-components를 사용했는데

inline스타일도 많고 기존 css는 파악이 안되니 !important를 남발했다. 

결과적으로 내가 보는 css는 대체 어디서 padding이 생기는지조차 파악하기 어려운 상태가 되어있었다.

3. 리덕스, 컨텍스트api, 리액트쿼리 등 다수의 전역상태 관리 라이브러리 혼재

전역상태 라이브러리도 다양하게 사용되었다. 처음 개발 시에는 contextAPI를 사용해서 개발이 되었고

두 번째는 리덕스, 세 번째는 리덕스툴킷, 네 번째는 리액트쿼리를 도입하려고 아주 조금 사용해 본 흔적이 있었다.

모든 서버상태를 수많은 useEffect와 섞어서 전역상태로 관리하고 있었기 때문에 과한 리랜더링의 원인이 되었고

수많은 보일러플레이트 코드 파악이 안 되어서 별거 아닌 기능 하나만 추가하기도 굉장히 어려웠다.

그리고 기존의 보일러플레이트를 파악해서 사용한다고 해도, 전혀 전역상태일 필요가 없는 데이터까지 전역상태로 사용해야 했다.

4. 과거의 요구사항 기록된 문서, 테스트 코드 부재

위의 이유로 리덕스, contextAPI를 걷어내고 react-query를 사용해서 필요 없는 전역상태를 줄이려고 했다.

하지만 과거의 요구사항을 기록한 문서나 api 문서조차 없어서 코드를 보고 "이런 요구사항 때문에 이렇게 작성했겠구나" 

라고 '유추'하면서 작업할 수밖에 없었다. 이렇게 작업하면 아무리 꼼꼼하게 해도 문제가 있는데

개발자가 자신의 코드가 이전의 요구사항을 완벽하게 반영하면서 개선했다고 '확신'할 수 없기 때문이다.

 

 

결론

개리 마커스라는 사람이 쓴 클루지라는 책에서 저자는 클루지를 이렇게 정의한다.

'어떤 문제에 대한 서툴거나 세련되지 않은 그러나 놀라울 만큼 효과적인 해결책',

'잘 어울리지 않는 부분들이 조화롭지 않게 모여 비참한 전체를 이룬 것'

 

지금 우리 프로젝트의 코드가 딱 클루지 그 자체이다. 사실 자바스크립트의 탄생도 클루지고 사람도 클루지 그 자체이다.

직립보행을 할 거면 척추가 x자로 두 개여야 효율적일 텐데 직립보행을 못하던 시절 만들어놓은 하나의 척추로

나중에 직립보행이라는 요구사항을 수행하려니 단단한 코어(세련되지 않은 해결책)를 갖추지 못한 사람은 평생 디스크에 시달려야 한다.

하지만 우리의 코드까지 클루지가 되어선 안된다. 이렇게 임기응변식 코드를 작성하다가는 곧 무너질 것이다.

자바스크립트는 클루지 덩어리임에도 멋진 모습을 갖췄지만 

우리 프로젝트는 임기응변식 코드작성으로 괴물이 되어있었다.

 

개발자로서 우리는 기존 요구사항과 기능을 파악하고 다른 개발자도 쉽게 파악하고 수정할 수 있는 문서를 작성하고

프로젝트를 같이하는 팀원과 아키텍처, 디자인패턴을 결정하고 일관된 프레임워크, 라이브러리를 사용해야 한다.

최악의 리랜더링 91번 페이지는 현재 4번까지 줄어들었다.  함수 부분 코드라인은 500여 줄에서 80줄로 줄였다.

희망을 가지고 해 보자

 

 

 

https://pungwa.tistory.com/184

처음 고민해본 프론트엔드 아키텍처와 디자인패턴