fffo

[업무 일지] todo list부터 시작하는 디자인 패턴 본문

카테고리 없음

[업무 일지] todo list부터 시작하는 디자인 패턴

gggs 2022. 8. 11. 18:28

요근래 디자인 패턴에 대해 많이 고민을 하고있다. 계기는 다음과 같다.

이해하기 어려운 코드

  5월부터 티 플랫폼 사이트 제작에서 프론트를 맡았다. 작은 스타트업이라 프론트가 나 뿐이었다. 그래도 작년에 계셨던 프론트 개발자분이 짜신 코드가 그대로 있어서 다행이라 생각했다. 코드를 보니 다행이 아니었다.

  내가 받은 코드는 페이지 단위로 비즈니스 로직과 뷰가 한데 뭉쳐있었다. 그러다보니 페이지 하나에 코드가 몇 백줄이 넘어가고, 컴포넌트 단위로 나뉜 것도 아니라서 각각의 페이지 파일이 몇 백줄이 넘어갔다. 파일의 네이밍도 무슨 파일인지 감이 잘 안잡혔다.

 

어떤 파일일까?

이해하기 쉬운 코드

  결국 리팩토링보다 처음부터 다시 만드는 것이 나을 것 같아서 새로운 레포를 팠다. 이해하기 어려운 코드를 받았던 내 심정과 다른 곳에 취업을 하면 언제든지 이 팀에서 나갈 수 있는 상황 때문에, 누구나 이해하기 쉽고 간결한 코드를 짜봐야겠다고 다짐했다.

  코드의 틀을 잡기 위해 여러가지 디자인 패턴을 써봤다. 그 중 container-presenter 패턴과 custom hook 패턴을 섞어서 나름대로의 틀을 잡고 코드를 짰다.

  container-presenter 패턴은 container에 비즈니스 로직을, presenter에 뷰를 넣는다고 이해했고 나는 거기서 비즈니스 로직을 한 번 더 나누어 상태가 들어간 로직은 hook으로 따로 나누어 관리했다. 즉 contaner - presenter - hook 이렇게 크게 세 단위로 나눴다. 

  container는 컴포넌트단위로 나누고 실제 뷰는 pages폴더에서 각각의 페이지가 필요한 컴포넌트를 조합해 사용했다. 정리하자면 실제 폴더는 components - hooks - pages로 컴포넌트 안에 비즈니스 로직이 들어가고, 상태를 관리하는 로직은 hooks에서 받아와서 사용한다. pages에서 component를 가져와서 사용자의 화면에 뿌려준다. 그런데 만들다 보니 문제가 생겼다.

주객 전도

  컴포넌트는 재사용 가능한 코드 단위로 쪼개야 했지만 나는 container의 로직 단위로 나누었다. 예를 들어 메인 페이지에 들어가야할 것들이 이벤트 배너, 인기 차트, 추천 차트라고 하면 각각의 로직이 모두 다르고 디자인도 달랐기 때문에 다 다른 컴포넌트를 만들었다. 이를 재사용하는 경우는 전혀 없었고 container를 컴포넌트로 쪼갠 이유가 코드 쪼개기밖에 의미가 없었다. 

todo list부터 다시 시작하는 디자인 패턴

  원티드에서 프리온보딩이라는 코스를 개설했다. 거기에서 todo list를 만드는 과제가 있는데 같은 과제를 다른 사람들이 짠 코드를 모두 볼 수 있어서 좋았다. 시니어 분이 리팩토링도 함께 해주는 피드백 강의도 제공해줘서 이 코스를 통해 이해하기 쉬운 코드를 공부해보고자 한다.

Comments