[ 학습 목표 ]
UI와 도메인 영역을 분리할 수 있는 설계
를 고민해보고,목적에 맞게 객체와 함수를 활용
- 단위 테스트 기반으로 점진적인 리팩터링
2주차 미션이 마무리되었다. 개인적으로 콘솔을 벗어나 브라우저 환경에서 미션이 진행되어 재밌었다. 이제는 페어 프로그래밍이 꽤 익숙해진 것 같기도 하다. 컨벤션 맞추고, 이전에 어떻게 했는지 서로 말하고, 조율하였다. 이전에는 코드에 만족했다가 피드백을 엄청 받았었는데, 이번에는 구조가 인상깊다고 칭찬도 받고 step2까지 진행하고 나니 더 만족스럽다고 느꼈다.
추가로 면담도 진행했는데 면담에서 답을 찾으려고 했던 것 같다. 정답이 없는 세상,,,그래도 다시 한번 느낀 점은 정답은 없지만 방향은 있고, 공통된 정답은 없지만 개인화된 정답은 있다. 나 자신을 좀더 객관화해보자.
나는 과연 이번 미션에서 나온 개념들을 모두 설명할 수 있는가?
첫번째 고비는 TDD
. 작은 규모지만 말로만 듣던 TDD를 적용해보는 시간이 되었다. red-green-refactor
과정을 거쳐 완성해나갔지만 익숙하지 않아서 그런지 생각보다 진도가 느렸다. 그래서 어느정도 설계 과정을 거친 후 작업을 했더니 좀더 수월하게 진행되었다.
step1을 완료하고 느낀점 :
"TDD 개발 방법론을 써봤다”
는 중요 ❌
내가 생각하는 미션의 핵심 :도메인 로직과 UI 로직 분리 + 오버엔지니어링 방지
구현하다보면 필요할 것 같다고 생각하여 추가하는 과정에서 산으로 가기도 한다. 하지만 TDD를 활용하면 요구사항을 만족하기 위해 필요한 프로덕션 코드만 작성
하여, 오버엔지니어링을 최소화
할 수 있다. TDD로 도메인 로직을 대부분 완성하고, UI로직을 외부에서 주입한다면 도메인 로직과 UI 로직도 효과적으로 분리할 수 있다.
도메인 로직 분리를 강조하는 이유는 추후에 기획이 바뀌어도, 즉 UI가 바뀌었을 때 대응하기 쉽다. 기획이 바뀌는 일이 많냐?
고 하면 생각보다 많다고 생각한다. 그리고 아예 한 가지만 생각하고 짠 코드랑 다양한 경우를 고려한 코드는 느낌이 아예 다르다. 당연한 말 같지만 실제로 적용하기 어려운 부분이고, 한 가지만 생각하고 짠 코드를 고치는 것은 처음부터 짜는 것보다 어려울 수 있다.
기존 코드 변경을 최소화하라는 요구사항은 이를 간접 체험한 것이고, 몸으로 느낄 수 있었던 미션이였다. 우테코 일 잘하네
step1 코드에서 로직 분리가 잘 되어 있었고, HTML, CSS가 조금 익숙한 편이라서 기능 구현까지는 빠르게 끝냈다. 근데 이 아쉬움은 뭘까?
index.html이 파일 하나에 모아져 있는 것이 보기 싫었다. 새로운 기능이 추가된다고 했을 때 흩어져있는 로직을 타고 들어가야 한다.
html을 분리할 수 없을까?
분리에 대한 고민으로 검색을 하다보니 웹 컴포넌트
라는 기술이 존재한다는 것을 알게 되었다. 리액트처럼 컴포넌트화시킬 수 있겠다는 생각이 들어서 신이 났다. 근데 불현듯 다른 자아가 나왔다.
html 문서도 짧고, 반복되는 코드도 적어서 재사용성의 효과가 크지 않을 것 같은데, 컴포넌트화시키는 게 오히려 오버엔지니어링을 야기하는 것이 아닌가?
사실 안해봤으니까 해보고싶다는 생각이 가장 컸다. 이것만으로 충분했지만, 합리적인 이유를 찾아보면 로직이 흩어져있다고 생각한 불편함을 해결할 수 있다. 로직을 분리한다는 생각으로 파일과 디렉토리를 나눴지만, 오히려 파일 depth가 깊어져 복잡성이 증가한다. 이에 모듈성, 재사용성, 독립성
에 초점을 맞춰 웹 컴포넌트를 도입하였다.
회고글이라서 대략 어떤 기술이 있는지, 내가 어떻게 사용했는지만 작성하였다. 간단하게 썼지만 꽤나 검색도 많이해보고 고민하면서 도입하였다.
웹 컴포넌트의 주요 기술 : customElements
, 쉐도우 돔(Shadow DOM)
, HTML 템플릿
shadow dom
을 사용하면 스타일 코드 스코프를 제한하면서 캡슐화의 장점이 있지만, 내가 기존의 사용하려던 목적과 맞지 않았고 오히려 진입장벽이 높아졌다. 또한 스타일 태그가 innerHTML 안에 들어간다는 게 불편하여 사용하지 않았다.
customElements
로 간단하게 웹 컴포넌트를 만들 수 있다. 중복되는 메서드는 하나의 Layout처럼 만들어 상속받아 사용하는 것이 편하다.
<template>
태그를 사용하면 컴포넌트를 생성할 지점을 만들 수 있다. 나중에 사용하기 위해 담아놓는 컨테이너처럼 활용할 수 있다. 하위 컨텐츠에 존재하여 실제 DOM 트리에 붙여서 쓸 수 있다.
HTML을 파싱할 때 syntax analyzer가 <template>
요소의 콘텐츠도 읽기는 하지만, 이는 유효성을 검증하기 위함이며 렌더링 하기 위함은 아니기 때문에 성능에 큰 문제가 없다고 판단되었다.
웹 컴포넌트로 리팩토링 했는데 HTML은 분리되었지만 컴포넌트의 로직이 제대로 분리되지 않은 느낌이 들었고, 컴포넌트를 css처럼 import 하는 형식이 가독성이 안좋게 느껴졌다. 그래서 리액트 컴포넌트처럼
구현하려고 노력하였다.
개발자 황준일님 블로그를 참고하였고, 실제 리액트처럼 동작하도록 만드려면 더 많은 작업을 거쳐야 한다. 하지만 다음 레벨에 더 많이 고민할 기회가 있을거라고 생각하여, 로직을 응집성있게 묶고, 가독성을 높이는 장점만 가져왔다. 사실 너무 복잡해져서 못함
그 외에도 sementic tag, 웹 표준, 이벤트 위임 등 웹으로 넘어오니 공부할 것들이 또 쌓였다 ㅎㅎㅎㅎㅎㅎㅎ 더 열심히 살아야지 아자아자 🔥
GOOD !!!