🛼 우아한 테크캠프 2주차 회고(0711~0715)

🎯 2주차 미션

1. 칸반보드 형태의 Todo 리스트 구현

2. todoList 백엔드 구현(ExpressJS, mySQL 이용)

3. AWS 이용 배포

---

예쁜 쓰레기를 만들어 버렸습니다. 😟

설계

... 

ToDoAddRow 취소

- ToDoAddRow 삭제

## ToDo

제목, 내용, author by web

ToDo X hover

- toDo 배경색, 테두리색 변경
- X 버튼 색 변경

ToDo 삭제 alert

- 삭제 버튼 클릭 시 toDo 제거

ToDo 클릭

- 해당 toDo 객체 확인

ToDo 드래그

- 현재 target todo 복사
- 원본 target 유령화
- Target toDo 마우스 부착(따라다님)

ToDO 드랍

- 드랍 위치의 column 파악
- Column 비었냐?

ToDo 더블클릭

- ToDoAddRow 형태로 변화
- 등록 텍스트 => 수정
- 제목, 내용 하나라도 비었을 때 수정 비활성화

기본적인 설계는 1주차와 비슷하게 진행되었습니다. 요구사항에서 기능들을 모두 뽑아내고 그것을 기반으로 개발을 진행합니다.

이번 미션은 개인이 아닌 팀으로 진행했는데, 팀 플레이 경험이 많이 부족해 혹시 같이 하시는 분에게 폐가 될까 최대한 신중하게 진행한 것 같습니다.

백엔드 설계는 우선순위를 뒤로 미뤄뒀고, 최대한 프론트엔드 부분의 구현에 집중했습니다. 프론트엔드는 core Component 클래스를 만들고, 그것을 상속받아 다른 컴포넌트들이 사용하는 형태로 계획했습니다.

🍎 미션 진행 중 고려한 사항

프론트엔드

개인적으로 아쉬움이 많이 남았던 미션이었습니다. 초반에 팀원 분과 함께 설계를 진행하고 페어 프로그래밍 방식을 통해 구현을 시작한 건 정말 좋았지만, 후반부에는 남은 기능의 구현에만 급급해 마구잡이로 구현을 진행했습니다.

그렇기 때문인지 후반부에 들어서서는 코드를 알아볼 수 없을 정도로 어지럽게 작성한 경향이 있습니다.

• 자바스크립트를 이용한 렌더링

이번 미션에서는 HTML을 정적으로 마크업하는 방식이 아닌 코어 컴포넌트 클래스를 작성해 상속받은 하위 컴포넌트들이 렌더링되는 방식을 택했습니다.

import Header from './components/Header';
import TodoContainer from './components/TodoContainer/TodoContainer';
import TodoLogContainer from './components/TodoLog/TodoLogContainer';

class App {
	constructor($target) {
		this.$target = $target;
		this.$todoLogContainer = null;

		this.setup();
	}

	setup() {
		new Header('header', this.$target, {
			class: ['header', 'hi'],
			onClick: () => {
				this.$todoLogContainer.$target.classList.add('visible');
			},
		});

		new TodoContainer('div', this.$target, {
			class: ['todo-container'],
		});

		this.$todoLogContainer = new TodoLogContainer('aside', this.$target, {
			class: ['todo-log-container'],
		});
	}
}

export default App;

기본적으로 app div박스가 있고 그 안을 각각의 컴포넌트들이 채우는 형식입니다. 현재는 app에 헤더와 todo container 그리고 log container가 있습니다.

• 이벤트 위임 방식 이용

클릭이나 드래그 등은 각각의 html 요소에 이벤트를 넣을 수도 있지만, 그것은 너무 비효율적이라고 판단하고 상위 컴포넌트에서 다양한 이벤트들을 위임하도록 했습니다.

이벤트가 발생하면 그것이 발생한 타겟 등을 확인해 필요한 이벤트를 실행시킵니다. 조건 분기가 많이 발생하지만 모든 요소에 eventListener를 등록하는 것보다는 좋다고 판단했습니다.

• 문제점

이번 미션은 state를 기반으로 컴포넌트들이 렌더링됩니다. 이 말은 컴포넌트 간의 데이터 교환이 발생할 경우, 해당 데이터를 부모 컴포넌트 또는 store에서 관리하고 그것을 각각의 자식 컴포넌트에게 반영시켜줘야 한다는 뜻입니다.

부모 컴포넌트에서 데이터를 관리한 결과 다음과 같은 일이 벌어졌습니다.

원인?

todoCard들을 관리하는 todoContainer가 무려 300줄을 차지하게 됩니다. TodoContainer가 TodoCard들이 필요한 모든 데이터를 관리하고, 그것을 추가, 수정, 삭제, 이동하는 것들을 모두 컨트롤해야 하기 때문입니다.

필요한 로직들을 모두 TodoContainer 클래스가 가지고 있어야 하기 때문에 지금처럼 무거운 컴포넌트가 탄생했습니다.

지금 리팩토링을 생각한다면 DOM 조작 메소드들을 따로 utils처럼 관리하고, 그것에 대한 추상화를 제공하는 것으로도 코드의 양을 충분히 줄일 수 있을 것 같습니다.

드래그 앤 드랍, 추가, 삭제 등은 공통되는 DOM 접근이 많기 때문입니다.

백엔드

이번 미션에서는 백엔드 구조 설계만 팀원 분과 함께하고 시간이 촉박해 남은 프론트엔드 부분을 제가 구현하고 백엔드 api 등은 팀원 분께서 진행했습니다.

구조 상으로 고려했던 점은 다음과 같이 api의 라우터와 컨트롤러들을 분리했다는 점입니다.

또한 네트워크 요청에 대해서도 고려한 점이 있습니다. todoCard를 api 호출을 통해 조정할 경우 그에 해당하는 log를 생성해야합니다.

이때 프론트엔드에서 log 추가 요청과, todoCard의 api 요청을 각각 요청하는 게 아닌 todoCard에 대한 요청만 하고 log는 백엔드에서 자동적으로 추가해주도록 설계했습니다.

node js의 미들웨어 패턴을 이용하면 이 부분을 우아하게 처리할 수 있는데, todoCard 요청에 대한 처리를 하기 전 logMiddleware를 거쳐 log 데이터를 미리 생성합니다.

그리고 todoAPI로 해당 log를 보내면 API 처리가 성공할 시 자동적으로 logData 또한 업데이트해주는 방식으로 네트워크 비용을 줄일 수 있습니다.

비록 완벽하게 구현하지는 못했지만 추후 다시 도전할 미션에서 이런 방식들을 고려할 것 같습니다.

✨ 개선방향

function removeElement(DOMElement) {
  DOMElement.parentNode.removeChild(DOMElement);
}

function appendElement(DOMElement, parentElement) {
  parentElement.appendChild(DOMElement);
}

해당 미션에서는 다음과 같은 코드 구조가 많이 나옵니다. todoCard를 add, remove하는 과정 등에서 다음과 같은 형태로 많이 이루어지기 때문입니다.

하지만 미션이 끝나고 이런 생각도 들었습니다. DOM에 접근해서 해당 엘리먼트를 지우거나 수정하는 것과 아예 state만 수정하고 새롭게 render를 호출하는 방식 어떤 게 더 효율적인지에 관한 것입니다.

백지 상태에서 새롭게 DOM을 구성하는 작업은 비용이 많이 들겠지만, 기존에 있던 DOM을 접근 메소드 등을 통해 수정하는 것도 큰 비용이라는 생각이 듭니다.

수치적으로 어떤 것이 더 효율적인지는 확실하지 않지만, state를 기반으로 새롭게 렌더링을 진행할 경우 한 가지 확실한 장점이 있습니다.

기존의 초기 렌더 함수를 호출하는 것으로 모든 업데이트를 처리할 수 있다는 점입니다. 그렇다면 addCard나 deleteCard 등의 메소드들의 길이도 짧아지고, 발생할 버그의 양도 많이 줄어들 것 같습니다.

물론 구체적으로 들어간다면 querySelector가 더 빠르고 그것보다도 getElementById가 더 빠르겠지만, 성능만을 고려한다면 jQuery나 angular, react 등의 프레임워크/라이브러리는 애초에 사용을 자제해야할 것입니다.

개발을 진행하는데 있어 편리함도 도구를 사용하는 이유 중 하나일 테니 말입니다.

나중에 이런 생각들을 기반으로 다시 만들어보고 후기를 작성해봐야겠습니다.

🧠 고민과 생각

이번에도 마찬가지로 크롱과 호눅스의 피드백을 듣고 많은 생각을 했습니다. 평소에 갖고 있던 생각과 그에 대한 방향, 그리고 특정 도구나 패턴을 도입하는 것에 대해 어떤 방향으로 생각이 나아가야 하는 가에 대해서도 생각해보게 되었습니다.

1. 개발의 순서

개발에서 백엔드가 먼저 개발되고 그것을 기반으로 프론트엔드가 개발되는 게 최고겠지만 사실 순서는 없습니다. 지금처럼 대형 프로젝트가 아닌 미션이라면 정말 편한 방식대로 개발해도 괜찮습니다. 하지만 그만큼 초기 설계나 규칙 등은 철저히 정해놓는 게 좋습니다!

2. 코드는 최대한 분리하자

복잡한 로직은 가능한 숨겨야합니다. 나만 보는 코드라면 그냥 마음대로 작성해도 상관없겠지만, 개발에서 협업은 필수적입니다. 그렇기 때문에 조건문 안의 조건 등이 복잡해진다면 최대한 추상화 계층을 제공하는 게 좋습니다.

3. 사용 이유를 생각하자

이번 미션에서는 class형 컴포넌트를 기반으로 개발을 진행했습니다. 이유는 딱히 없습니다. 정말 말 그대로 그냥 사용한 것 같습니다. 우테캠 2차 과제의 진행방식을 토대로 미션을 진행했지만 단순히 경험에 의거한 판단일 뿐 타당한 논리는 없었습니다.

미션을 함께 수행하신 팀원 분도 금요일 마무리 시간에 저와 같은 의견이었습니다. 서로의 스타일이 잘 맞아서 좋았지만, 그렇기 때문에 이런 부분을 생각할 기회가 없었던 것 같습니다.

기획의 요구사항을 보고, 굳이 클래스형이 필요한지, 데이터를 state로 관리해야하는 이유가 있는지 등 다양한 방면에서 기획을 접근해야겠다는 생각을 했습니다.

강제적인 업무가 아닌 교육용 미션인 만큼 다양한 접근방법을 시도하는 게 좋을 것 같습니다.

4. 😡 디버깅

최고의 디버깅 방법은 console.log입니다.

라는 생각은 이제 버려야하겠습니다. 호눅스가 저번 미션부터 누누이 말했지만 이번에 역시 console.log를 거침없이 사용했습니다. 크롬 개발자 도구에서 디버깅 툴을 이용했다면 더 빠르게 오류의 원인을 발견했을 텐데 아쉽습니다. ㅠㅠ

너무 기존의 방식에만 익숙해져 새로운 시도를 하지 않으려 했던 것 같습니다. 다음 미션의 목표에 console.log로 디버깅하지 않기를 정하고 시작해야겠습니다.

👍 후기

이번 미션을 수행하고 느낀 점들을 한 문장으로 표현하면 다음과 같습니다.

일관된 룰을 정하고 그것에 맞춰 개발을 진행하자.

목요일 15시 경까지는 분명 개발이 일관적인 룰대로 진행됐는데 그 이후는 기능의 완성에만 급급해 망해버린 느낌이 많이 들었습니다. 완성을 못하더라도 일관된 룰을 지키는 게 옳다고 생각됩니다.

그 룰이 어떤 부분에서 잘못되어서 기한 내에 완성시키지 못했는지도 피드백해야 할 부분 중 하나이니 말입니다.

이번 미션은 좋은 점도 많았지만, 아쉬운 점이 상대적으로 더 커 보입니다. 가장 큰 이유는 시간관리, 그리고 협업경험 부족 때문이라고 생각합니다.

어떤 부분의 개발을 진행해야하고 어떤 작업을 하고 있는지, 항상 팀원과 의논하며 서로를 지속적으로 리뷰하는 습관을 이번 캠프에서 배워가야겠습니다.