추석의 달콤함과 피곤함에서 헤어나오지 못하고 WEEK3의 회고를 작성하지 못했다. 추석의 덕도 있었겠지만, WEEK4의 미션이 그 전과는 다른 차원의 어려움이 있었기 때문이기도 하다. (핑계가 좋다)

WEEK3는 간략하게만 알고 있던 네트워크 부분에 대한 구현이 필요해서 힘든 주였다. 백엔드를 잠깐 해봤을 때는 그렇게 어려운게 아니라고 생각했는데, 막상 요구사항에 맞게 구현하려니 여간 쉬운 일이 아니었다. 현업에서는 이렇게 아무 라이브러리도 못쓰는 low한 상황이 일어나진 않겠지만, 라이브러리를 사용하지 못하는 이런 상황만큼 그 개념에 대해 배우기 좋은 미션은 없는 것 같기도 했다.

어찌저찌 해서 기능은 잘 동작하는 웹 페이지를 만들어내긴 했지만 아쉬운 점이 많이 남는다. 보안을 전공했음에도 불구하고 기능 구현에 급급해 보안을 전혀 신경쓰지 못했다는 점, 클린 코드를 만들었다고 생각했더라도 남과 함께 보니 클린하지 않았다는 점. 그리고 추석에 이 아쉬운 점을 고쳐보려고 했으나 명절 준비와 휴식에 모든 시간을 쏟아버렸다는 점이 아쉽다.

WEEK4에도 생각만큼 고치는 일을 해내지 못했는데, 아무래도 체력이 부족한 것 같다. 평일에 소진한 체력을 주말에 비축해두지 않으면 평일에 살아날 수가 없었다.. 매일 앉아만 있어서 그런 것 같은데, 이대로 가다간 안되겠다 싶어서 틈틈히 운동을 해야겠다는 생각이 점점 들고 있다.

WEEK4의 미션도 만만치 않았다. 게다가 이번주부터는 미션에 주말이 포함되지 않아서 시간적/정신적 여유가 부족했고, 다크서클이 짙어지기 시작했다.. 아무렇지 않게 쓰던 웹 페이지의 애니메이션 동작을 직접 구현해보니 이를 구현한 프론트 개발자는 엄청난 인물이다.. 라는 생각이 들었고, 애니메이션만 보면 이거 어떻게 구현했을까!!!! 라고 보게되기 시작했다. SAD

WEEK3

커밋 로그에도 신경쓰기!

그동안 커밋을 남길 때 따로 어떤 규칙을 두진 않고, 그냥 뭔가 알아볼 수 있을 것 같게(?) 영어로 로그를 남겼다. 그런데 마스터 클래스에서 코드리뷰를 통해 커밋에도 한눈에 알아보기 쉬운 로그가 좋다는 것을 알았다. 이를테면 기능은 feat, 자잘한 일은 chore과 같이 앞에 큰 카테고리를 두고 그에 대한 설명을 붙이는 규칙들도 있다.

그래서 나도 한번 그와 비슷하게 해보기로 했다. 내가 채택했던 방법은 TOAST_Meetup!의 글을 참고했는데, 앞자리는 대문자로 쓰고 명령조로 커밋을 남기는 규칙이었다. 내가 쓰던 방식에서 대문자 말고는 크게 바뀌지 않는 방법이라 채택해봤다. :D

그런데 문제는…

문제는 커밋의 단위가 좀 더 작아지면서 발생했다. 기능을 개발하면 그 기능에 대한 커밋을, 어떤 구문을 삭제하면 그 구문에 대한 삭제를 왜 하게 됐는지를 적으려고 하다보니 영어 실력이 발목을 잡았다. 개발 영어로 사용되는 단어들이 있는데, 그냥 한국어로 의미만 상통하는 단어를 사용하다보니 뜻이 이상하게 남아서 바로 해석할 수가 없거나 누군가는 잘못 해석할 수도 있었다.

그래서 나만의 규칙을 만들어서 사용하기로 했고, 그것을 최대한 따르면서 커밋을 남기려고 노력했다.

image

이렇게 앞에는 알아보기 쉽도록 어떤 것과 관련된 일인지 큰 카테고리를 영어로 적고, 뒤에는 어떤 일을 했는지를 적었다. 그리고 ...으로 표시된 부분은 본문인데, 왜 이러한 작업을 하게 되었는지와 같은 세부 설명이 필요한 경우에는 커밋에 추가적으로 본문을 적어서 다른 사람이 보기에 좀 더 편하게 해보려고 했다.

커밋을 바꾸니 나에게도 좋았다. 이전에 어떤 것을 했는지 알아보기도 편하고, 특정 부분만 보고 싶을 때 커밋을 클릭해서 보면 전체 코드를 보는 일보다 편하기도 했다.

README도 중요해

프로젝트 repository를 만들면서 초기화를 하면, README.md 파일이 항상 생성되고 제목으로 프로젝트 이름이 기본으로 작성되어있는 것을 볼 수 있다.

이 파일은 프로젝트에 대한 설명을 적는 부분인데 오픈 소스를 보면 이 프로젝트를 어떻게 실행할 수 있는지, 어떤 라이브러리를 사용했는지, 버전은 몇인지 등의 정보를 확인할 수 있다.

프로젝트이긴 하지만 미션이라는 생각이 더 강해서 제출한 프로젝트의 폴더 구조와 같은 설명만 담았는데, 어떤 부스트캠퍼의 README 파일을 보니 소스 파일을 받았을 때 필요한 패키지를 다운로드 하는 명령어, 실행 명령어와 같이 코드를 실행해볼 수 있는 방법도 담겨있었다. 생각해보니 내 코드는 default와는 실행방법도 달랐는데, 이런 정보는 꼭 담아야겠다는 생각이 들었다.

이 코드를 실행해볼 수도 있는 어느 누군가, 그리고 미래의 나를 위해서!

WEEK4

컴포넌트화?

이번에는 구현한 기능을 다른 프로젝트에서도 쓸 수 있도록 컴포넌트화도 해보는 요구사항이 있었다. 다 짜고 보니 컴포넌트라는 의미가 어디까지가 컴포넌트인가, 라는 생각이 들었다. new Object()로 객체를 실행하면 UI부터 이벤트 등록까지 다 해주는 것? 기초적인 기능만 구현하고 등록은 사용자에게 맡기는 것? UI와 스타일만 구성해주는 것? 아직도 좀 헷갈리고 어렵다.

컴포넌트는 UI의 상황에 의존하지 않도록 해야하는 것이라고 하는데, 이렇게 만들기 위해서는 처음부터 해보는 것은 어렵고 만든 컴포넌트를 한번 다른 프로젝트에 재사용해보면서 고쳐보는 것도 좋은 방법이라고 한다.

그러나 재사용이 가치는 있지만, 정말 자주 사용될 컴포넌트가 아니라면 처음부터 재사용성을 고려하고 개발하는 것은 오히려 배보다 배꼽이 더 클 수 있다. 재사용을 고려하고 다양한 기능을 포함했다가, 다른 프로젝트에서 그 컴포넌트를 사용하려고 할 땐 오히려 너무 과할 수 있고, 오픈 소스를 사용할 경우에는 원치 않는 방향으로 바뀔 수도 있기 때문이다.

이 글을 읽어보면서 생각해보고, 이번엔 public 상태로 프로젝트를 바꿨으니 제대로 리팩토링을 해 볼 생각!

추상화

요즘은 vanilla를 지향하고, jQuery는 지양하는 추세라고 한다. vanilla가 지원하는 범위도 커졌고 사양도 좋아졌기 때문이라고 한다. jQuery에 보면 querySelector를 $와 같은 표시로 사용하는 것을 볼 수 있다. 그래서 이 방식으로 표현하는 건 좋지 않을 거라고 생각했고, 이 과정들을 명시하는 것이 더 좋다고 생각했는데 아니었다!

명시해야할 것은 이 동작이 어떤 로직인지를 담는 것이고, 그 외의 것들은 최대한 추상화해서 읽기 편하게 만드는 것이 좋다. 이러한 추상화의 예를 들어보면 아래와 같은 경우다.

document.querySelector('asdf');

//abstract
const _$ = (selector, base=document) => base.querySelector(selector);

//use like this
_$('body'); //same with document.querySelector('body')'

실제 동작은 querySelector이긴 하지만, 어쨌든 이렇게 추상화를 통해 로직이 아닌 부분은 간략화 했기 때문에 실제로 어떤 동작을 하는지를 더 한눈에 볼 수 있게 된다.
또 이런 식으로 다른 프로젝트에서도 사용하는 부분은 utils로 따로 빼둬서, 이후 프로젝트에서도 도움을 줄 수 있다.

이 외에도 다양한 것들을 배울 수 있었는데, 가장 인상깊은 부분이었다. 기록했던 문서들을 안봤는데도 기억에 남는 부분들이라서 아직도 생생한 기분이다.

다음 주차 백엔드 미션이 미리 나와서 확인했는데.. 다음 주는 이번 주에 고생한 것보다 100배는 더 힘들 것 같은 느낌… 공부해야할 것들이 너무 많다. 버스에서 자는 시간도 아까운 정도..? 하지만 피곤해서 안잘 수는 없다.

이번에는 nCloud에 프로젝트를 배포해보는 것까지가 최종 요구사항인데, 성공적으로 배포를 마친 모습이 기대가 된다. 이번에도 우여곡절 끝에 요구사항을 만족하는 프로젝트 기대 중!

(그 이상을 바라지만 아마 큰 꿈일거야..)