규제 혹은 팀을 위한 코드

이 글은 뷰티풀 자바스크립트 4장을 요약한 것입니다.

뷰티풀 자바스크립트의 저자 안톤 코발요프는 팀에서 코드를 작성한다는 것에 대한 의미를 묻는다. 과연 같은 코드에 대해서 작업하는 5명, 10명, 100명을 어떻게 온전히 관리하는가? 신규 멤버가 빠르게 팀에 맞출 수 있는지 어떻게 예측하는가? 잘못된 추상화 강요 없이 반복하는 것을 막을 수 있는가?

그리고 이러한 질문들에 대한 일종의 대답으로, 일종의 룰을 제시하고 있다.

레슨1 : 다른 사람을 위해 코드를 작성하라.

코드를 작성할 때, 단순하지만 이러한 사고방식은 코드의 품질에 많은 영향을 끼치게 된다. 자신의 팀이나 다른 사람들을 위한 코드를 작성하지 않게 된다면, 일관성 없고 제멋대로인 코드 베이스가 만들어지기 쉽다. 전역 함수, 변수등이 남발되거나 템플릿 대신 희소한 코드가 작성되기 쉽게된다.

레슨2 : 코드를 간단하게 유지하자. 단, 간결!==간단

디버깅은 소스코드 작성보다 어렵다는 말이 있다. 따라서 아무리 똑똑하게 코드를 작성하더라도, 디버깅하기에 충분할 정도로 똑똑하지는 못하다는 말도 될 것이다. 따라서, 우리는 유지보수 측면에서 이득을 얻기 위해서는 (누구라도 새벽 2시에 알아보기 힘든 마법 코드를 해석하고 싶지 않을 테니까) 코드를 간단하고 이해하기 쉽게 유지하는 것이 매우 중요한 것이다. (레슨1과도 이어지는 이야기이다.)
다음 코드를 보자

// case 1
var el = document.querySelector('.profile');
el.classList[['add','remove'][+el.classList.contains('on')]]('on');

// case 2
var el = document.querySelector('.profile');
if(el.classList.contains('on')) el.classList.remove('on');
else el.classList.add('on');

위의 두 코드는 완벽하게 동일한 코드이다. 첫번째 케이스의 코드는 더 조밀해 보인다. 글자수도 더 적고, 간결해 보이기도 한다. 하지만 너무 많은 기호들을 포함하고 있고, 이를 해석할 때, 메소드들이 첨자를 사용해서 호출될 수 있는지, 꺾쇠괄호가 배열과 메서드 검색에 사용되는지 등에 대해 알고 있어야 한다.

하지만 두번째 코드는 조금은 더 길지만, 소스코드를 읽는 사람들에게 직관적으로 보이게 된다. 뿐만 아니라 일종의 영어처럼 읽히기도 한다. 이러한 코드는 훗날(몇개월, 혹은 몇년이 지난 후)에 누군가가 코드를 다시보더라도 이해하는데 무리가 없을 것이다.

레슨3 : 할 수 있다는 것이 해야만 한다는 것을 의미하지 않는다.

레슨4 : 익숙한 패러다임과 패턴을 사용하자.

두 레슨은 한 마디로 표현될 수 있다. '세련되게 유지하자'.
초기 자바스크립트에서는, 클래스를 지원하지 않았다. 거기에 es6가 나올 때 까지 어떤 표준 모듈 시스템, 표준 패키지 매커니즘도 없었고, 많은 클래스 라이브러리들이 난립하여 사람들을 혼란에 빠지게 한 프로토타입 상송 모델을 가졌다. 아래 예시 코드를 확인하자.

var log = console.log.bind(console);
var a = {
 money : 100,
 toString: function(){ return this.money }
};
var b = Object.create(a);

log('a:'+a, 'b:'+b); // a:100 b:100
a.money = 150;
log('a:'+a, 'b:'+b); // a:150 b:100
b.money = 50;
log('a:'+a, 'b:'+b); // a:150 b:50
delete b.money;
log('a:'+a, 'b:'+b); // a:150 b:150

b는 a를 상속한다. 이것이 실제로 의미하는 것은 b.prototype = a 이고, b와 일치하지 않는 속성은 a에서 위임된다는 이야기 이다. 다시말해 b의 100은 a의 100이지만, b는 a의 복제는 아니다. b가 자신의 돈을 가질 때, 기본적으로는 a에서 상속된 속성을 덮어쓰게 되는 것이다. 그리고 delete b.money로 돈을 제거하는 행위는, 이를 미정의 속성으로 만드는 것이 아니라 a의 돈을 다시 b의 돈으로 만들게 되는 것이다.

이는 처음 접하는 사람에게는 다소 혼란스러운 것으로, 사실 개발자는 프로토타입이 정확히 동작하는 방식을 모르더라도 개발을 할 수 있다. 이러한 방식을 사용하지 않는 대신 대중적으로 널리 알려진 기존의 상속 모델을 사용하면 다른 사람들이 빠르게 이해할 수 있고, 언어에 대한 깊은 이해 없이도 생산적으로 코드를 관리할 수 있게 되는 것이다.

레슨5 : 일관성이 최고다.

스타일 가이드는 사람마다 다른 취향을 가지고 있을 수 있다. 들여쓰기, 공백, 대문자 사용, 명명, 주석 등 여러가지 법칙에 대해 다른 기호들을 가질 수 있고, 각각에 대한 이유들도 각양각색이 될 수 있다. 하지만 팀 내부적으로 해당 스타일 가이드들에 대한 기준을 제시해야 하며, 기준은 반드시 이유를 동반해야 한다. 또한 이러한 스타일 가이드들도 단순히 따르는 것은 피해야하며, 꾸준히 재평가 되어야 한다.

최근 개발업계에서는, prettier 같은 코드 포맷터를 이용하여 팀 내부의 코드 스타일을 통일하는 것을 당연시 여기고 있다. 이는 아주 바람직한 것으로, 우리가 서비스를 개발할 때 가지고 있는 여러가지 목적중 하나를 쉽게 달성할 수 있게 해준다. 서비스의 장기적인 유지보수 측면에서, 코드는 궁극적으로 한 사람이 작성한 것처럼 보이게 되어야 한다.

레슨 6: 좋은 기반을 만들고 점차 복잡해질 것을 염두에 두자.

작은 계기가 마련되면, 빈 캔버스 위에서라면 아무도 디자인하지 않았을 시스템으로 진화한다.

점차 복잡해지는 것은 거의 모든 소프트웨어의 개발 본성이라고 할 수 있다. 이는 자바스크립트에서도 통하는 법칙으로, 처음에는 간단한 HTML와 CSS로 시작한 단순한 웹사이트가 jQuery를 사용하기 시작하고, XHR을 추가하고, pushState를 사용하는 등 점점 복잡해진다. 이윽고 처음 설계시 의도하지 않았던 웹사이트가 되어버린다. 성능이 문제가 되고, 이상한 조건들이 존재하고, 코드는 산만해지며 추적하기 힘든 메모리 누수등이 발생하게 된다.

이는 너무나 당연한 것으로, 이러한 일들이 발생하게 될 것이라는 것을 염두에 두어야만 하는 것이다.