🌈 Chapter 1: 좋은 소프트웨어 만들기

📚 바르게 시작하는 코드 작성하기

🎈 자바스크립트 특성을 완벽히 섭렵하라

사례 연구: D3.js

전체적인 내용은 예제형식이라 생략. (rj.js와 pathFromArray.js 참고)

const rj3 = {};

rj3.svg = {};

rj3.svg.line = function () {
  let getX = function (point) {
    return point[0];
  };

  let getY = function (point) {
    return point[1];
  };

  const interpolate = function (points) {
    return points.join('L');
  };

  function line(data) {
    const segments = [];
    const points = [];
    let i = -1;
    const n = data.length;
    let d;

    function segment() {
      segments.push('M', interpolate(points));
    }

    while (++i < n) {
      d = data[i];
      points.push([+getX.call(this, d, i), +getY.call(this, d, i)]);
    }

    if (points.length) {
      segment();
    }

    return segments.length ? segments.join('') : null;
  }

  line.x = function (funcToGetX) {
    if (!arguments.length) {
      return getX;
    }

    getX = funcToGetX;
    return line;
  };

  line.y = function (funcToGetY) {
    if (!arguments.length) {
      return getY;
    }

    getY = funcToGetY;
    return line;
  };

  return line;
};

1. 자바스크립트 함수는 다른 함수 내부에 중첩될 수 있으며, 이는 스코프를 다스리는 중요한 수단이다.
2. 자바스크립트 함수는 일급 시민로서 자신만의 프로퍼티와 메서드를 가질 수 있다.
3. 자바스크립트 함수는 메서드/프로퍼티를 지닌 객체로, 다른 언어의 함수보다 훨씬 유연하고 강력하다.
4. 자바스크립트에서 객체 지향적 함수 오버로딩 개념은 함수의 arguments를 보고 여기에 뭔가 맞추는 행위다.
5. 덕 타이핑을 잘 활용하라. 적은 코드로도 객체를 폭넓게 다룰 수 있다.
6. 클로저는 자바스크립트의 정말 강력한 설계 요소다. 모든 함수는 클로저다.
7. 자바스크립트에서 this는 설계 관점에서 절호의 기회가 될 수 있다. 잘 써먹도록 하자!
   • this는 함수를 호출한 객체를 참조한다.

자바스크립트는 싱글 스레드로 움직인다

자바스크립트는 싱글 스레드로 움직인다. 자바스크립트는 다른 식으로 비동기 프로그래밍을 해야 한다는 뜻이다.

자바스크립트는 어떤 이벤트가 끝나자마자 실행할 함수를 큐에 넣는게 고작이다. 여기서 이벤트란 일정 시간 경과(setTimeout), 다른 웹 사이트에서 데이터 조회(XMLHttpRequest.send), 마우스 클릭 등이다. 자바스크립트 엔진은 이벤트 루프에서 한 번에 하나씩 함수를 꺼내 실행한다.

🎈 대규모 시스템에서 자바스크립트 함정을 피하라

스크립트는 모듈이 아니다

여러분이 작성한 스크립트는 이 스크립트가 담긴 .js 파일 안에 담겨 있으니 어떤 경우라도 완전 분리는 불가능하다. 파일 첫 부분이 이렇게 시작하면,

var myVariable = makeValue();

myVariable은 같은 애플리케이션의 다른 스크립트에서도 볼 수 있고 makeValue 함수도 마찬가지다.

스코프는 중첩 함수로 다스린다

자바스크립트는 클래스가 없지만, 함수를 중첩하여 코드를 계층화할 수 있다. 덕분에 개발자가 원하는 것을 찾는 데 도움이 될 뿐만 아니라 프로그램에서 변수/함수의 스코프를 최소화할 수 있다.

규약을 지켜 코딩한다

대규모 시스템을 잘 꾸려 나가려면 될 수 있는 한 작게 만들어야 효과적이다. 자바스크립트는 간이 고루 잘 밴 덕 타이핑의 기상천외한 유연성 덕분에 적은 코드로도 많은 일을 할 수 있다.

반면에, 자신이 짠 프로그램이 누가 무엇을 던져 넣을지 도통 알 수가 없다. 함수 인자에 특정한 조건이 있다면 그 값을 꼭 검증해야 한다.

🎈 소프트웨어 공학 원칙을 적용하라

SOLID 원칙

SOLID는 마이클 페더스가 1990년대 후반, 로버트 마틴이 확립한 다음 다섯 가지 객체 지향 설계 원칙을 잘 기억하려고 짜낸 머리글자다.

• Single Responsibility Principle (단일 책임 원칙)
• Open/Closed Principle (개방/폐쇄 원칙)
• Liskov Substitution Principle (리스코프 치환 원칙)
• Interface Segregation Principle (인터페이스 분리 원칙)
• Dependency Inversion Principle (의존성 역전 원칙)

단일 책임 원칙

다소 과장해서 말하면 모든 클래스(자바스크립트는 함수)는 반드시 한 가지 변경 사유가 있어야 한다.

예제에서 rj3.svg.line은 아는게 거의 없다. 그저 점 데이터를 배열로 받아 SVG 경로를 그려주는 함수(내부 line)를 반환할 뿐이다.

이 함수의 유일한 관심사는 배열에서 SVG 경로를 만드는 일이다. 이 관심사를 어떻게 이행할지는 철저하게 외부에서 제공한 함수에 달려 있으니 변경할 이유가 전혀 없다.

개방/폐쇄 원칙

모든 소프트웨어 개체는 확장 가능성은 열어 두되 수정 가능성은 닫아야 한다는 원칙이다.

즉, 어떤 경우라도 실행 코드를 변경하지 말고, 어떻게든 (상속 등의 방법으로) 재사용하고 확장하라는 뜻이다.

d3.svg.line 함수를 설계할 때 마이크 보스톡은 데이터에서 좌푯값을 뽑아내는 방법과 점을 연결하는 방법에 변경 사항이 있으리라 내다보고 이러한 특성을 추상화하여 함수 밖으로 빼내는 기지를 발휘했다.

그가 변경되지 않을 거라고 본 건 SVG 경로의 규격이다. 반드시 M으로 시작해서 그 뒤에 점 데이터가 이어지는 문자열 형태로 과감히 경로 문자열을 하드 코딩한 것이다. SVG 명세서가 하루아침에 바뀔 일은 없을 테니 d3.svg.line 역시 손댈 일은 거의 없을 것이다.

리스코프 치환 원칙

리스코프 치환 원칙을 자바스크립트에서 흔한 표현으로 바꾸면 다음과 같다.

어떤 타입에서 파생된 타입의 객체가 있다면 이 타입을 사용하는 코드는 변경하지 말아야 한다.

다시 말해, 한 객체를 다른 객체에서 파생하더라도 그 기본 로직이 변경되어서는 안 된다는 뜻이다. 만약 작성 중인 함수가 기반 클래스로 하는 일과 서브 클래스로 하는 일이 다르다면 이 원칙을 어긴 셈이다.

서로 파생 관계가 없는 타입 간에는 적용되지 않는다. 예컨대 자바스크립트에서는 어떤 함수의 인자가 숫자일 때, 문자열일 때, 아예 인자가 없는 undefined 타입일 때를 각각 분기 처리하는 것이 대개 좋은 습관이다. 앞서 살펴보았듯이 자바스크립트는 함수 오버로딩이라는 객체 지향 개념으로 이를 실천한다.

인터페이스 분리 원칙

이 원칙은 C++, 자바 같은 인터페이스 기반 언어 환경에서 비롯되었다. 이들 언어에서 인터페이스란 클래스에서 어떤 기능을 구현하지 않고 서술만 한 코드 조각이다.

기능이 많은 인터페이스는 더 작게 응축시킨 조각으로 나누어야 한다는 발상이다. 인터페이스 사용부는 전체가 아니라 아주 작은 인터페이스 하나만 바라보면 된다.

자바스크립트에서도 이 원칙을 실현할 수 있는데 (16장) 짧게 이야기하면, 인터페이스 분리 원칙의 정신을 실현하려면 함수가 기대하는 인자가 무엇인지 명확히 하고 그 기대치를 최소화해야 한다. 이럴 때도 덕 타이핑이 도움된다. 특정 타입의 인자를 바라보기보다는 이 타입에서 실제로 필요한 프로퍼티가 더러 있을 거라 기대하는 것이다.

의존성 역전 원칙

로버튼 마틴은 상위 수준 모듈은 하위 수준 모듈에 의존해서는 안 되며 이 둘을 추상화에 의존해야 한다라고 말했다.

인터페이스 기반 언어에서는 대개 의존성 주입이라는 연관된 개념으로 표현한다. 클래스 A가 클래스 B의 서비스가 필요할 때 A는 B를 생성하지 않는다. 대신 A 생성자에 건넨 파라미터 하나가 B를 서술하는 인터페이스 역할을 한다. 이제 A는 B에 의존하지 않고 자신의 인터페이스만 바라본다. A가 생성되면 구체화한 B를 넘겨받는다. B 역시 인터페이스에 의존한다.

리스코프 치환 원칙 덕분에 인터페이스를 만족하는, B의 파생형 버전을 제공할 수 있는 이점이 있다. 또한, 인터페이스는 B를 고쳐야 할 경우 하위 버전 호환성을 유지하려면 어떤 로직을 계속 갖고 있어야 하는지 일목요연하게 서술한다.

DRY 원칙

DRY 원칙, 즉 반복하지 마라(Don't Repeat Yourself) 라는 말 역시 좋은 소프트웨어 개발 습관의 근원이라 할 만하다. 모든 지식 조각은 딱 한 번만 나와야 한다라는 말이다.

가장 중요한 SOLID의 원칙 중 일부가 DRY 원칙의 필연적 산물이다. 단일 책임 원칙이 그렇다. 이 원칙을 어긴 코드는 결과적으로 다시 쓸 수 없다. X와 Y를 함께 하는 모듈이 있따. X를 하는 코드가 필요할 때 Y 로직을 들어내지 않는 한 모듈을 재사용할 수 없으므로 또다시 X를 코딩할 수밖에 없다. DRY 원칙과 맞지 않는다.

DRY함은 여타 언어와 비교했을 때 자바스크립트에서 특별히 중요하다. 코딩 실수는 늘 하기 마련인데, 자바스크립트는 잘못 코딩한 특정 클래스를 컴파일러가 미리 알려주지 않으니 자칫 그래도 운영 환경에 노출될 가능성이 크다.

📚 바르게 유지되는 코드 작성하기

🎈 단위 테스트는 미래에 대비한 투자다

단위 테스트(unit test)에서 단위(unit)이란 특정 조건에서 어떻게 작동해야 할지 정의한 것이다. 언제나 그런 것은 아니지만, 대개 함수로 표현한다.

단위 테스트 본체에 작성한 코드는 준비(arrange), 실행(act), 단언(assert)의 패턴을 따른다.

첫째, 테스트 준비다. 단위를 실행할 조건을 확실히 정하고, 의존성 및 함수 입력 데이터를 설정한다.
둘째, 단위를 실행하여 테스트한다. 예를 들어 단위가 함수면 준비 단계에서 미리 설정한 입력값을 함수에 넘겨 실행한다.
마지막은 테스트 단언이다. 미리 정한 조건에 따라 예상대로 단위가 작동하는지 확인한다. 단위가 함수인 테스트라면 예상한 값을 반환하는지 조사하면 된다.

전체 단위 테스트 꾸러미(test suite)를 작성하는 데 든 시간과 노력은 앞으로 프로그램이 직면할 갖가지 변화에 대처하기 위한 보험이자, 안정적인 애플리케이션 유지에 꼭 필요한 최선의 투자라고 할 수 있다. 단위 테스트가 실패한다는 것은 어떤 변화로 인해 기존 프로그램의 기능을 바뀌었으니 실패를 유발한 이 변화를 자세히 들여다보아야 한다는 사실을 일깨워주는 적색 신호등이다.

🎈 테스트 주도 개발을 실천하라

테스트 주도 개발(Test-Driven Development, TDD)은 처음부터 프로그램을 제대로 작성했는지 확실히 보장한다. TDD에서는 애플리케이션 코드를 짜기 전에 이 코드가 통과해야 할 단위 테스트를 먼저 작성한다. 마치 애플리케이션을 개발하듯 전체 단위 테스트 꾸러미를 만들어가는 TDD 방식을 따르면 단위 정의와 인터페이스 설계에 도움이 많이 된다.

TDD를 실천하는 개발자는 애플리케이션에 어떤 변화가 생길 때마다 다음 단계를 밟는다. 여기서 변화란 완전히 새로운 기능을 추가하거나 기존 시스템을 고치고 버그를 잡는 일이다.

1. 완벽히 변경하면 성공하거나 그렇기 되기 전까지는 반드시 실패하는 단위 테스트를 작성한다.
2. 테스트가 성공할 수 있을 만큼만 최소한으로 코딩한다.
3. 애플리케이션 코드를 리팩토링하며 중복을 제거한다.

이 세 단계를 흔히 red, green, refactor라고 줄여 말한다. red와 green은 각각 새 단위 테스트의 실패와 성공 상태를 가리킨다.

TDD에서 가장 중요한 건 테스트를 충족할 코드를 만들기 전에 테스트를 먼저 작성한다는 사실이다. TDD 습관이 완전히 몸에 배지 않은 개발자는 빨리 애플리케이션 코드를 뜯어고쳐 다음 개발 업무를 진행하고 싶은 충돌을 느낄 것이다. 애플리케이션을 바르게 개발하려는 의지가 있다면 테스트를 건너뛰고 싶은 욕망을 극복해야 한다.

애플리케이션 코드를 바꾸고 나서 테스트를 작성하면 되지 않나 싶을 수도 있다. 거듭 말하지만 이런 욕망에 굴하지 마라. 여러분이 바꾼 코드가 그 이후에 만든 테스트를 그냥 통과시킬지 확신할 수 없기 때문이다. 이렇게 만든 새 테스트는 단위 테스트 꾸러미에 아무 값도 추가하지 않으므로 잘못된 테스트라도 무사 통과할 가능성이 있다. 또한, 사후에 테스트를 작성하면 애플리케이션 코드가 어떻게 작동해야 한다는 것이 아니라 작성한 대로 작동할 거라는 뚱딴지같은 사실을 확인하는 꼴이다.

🎈 테스트하기 쉬운 코드로 다듬어라

테스트하기 쉬운 코드를 작성하려면 가장 중요한 단계는 관심사를 적절히 분리하는 일이다.

예를 들어, 다음 validateAndRegisterUser 함수는 관심사가 다양하다.

var Users = Users || {};

Users.registration = function () {
  return {
    validateAndRegisterUser: function validateAndDisplayUser(user) {
      if (!user || 
      user.name === '' || 
      user.password === '' || 
      user.password.length < 6) {
        throw new Error('사용자 인증이 실패했습니다.');
      }

      $.post('http://yourapplication.com/user', user);

      $('#user-message').text('가입해주셔서 감사합니다', + user.name + '님');
    }
  };
};

이 함수가 하는 일은 세 가지다.

1. user 객체가 올바르게 채워졌는지 검증한다.
2. 검증을 마친 user 객체를 서버로 전송한다.
3. UI에 메시지를 표시한다.

관심사는 세 가지로 요약된다.

1. 사용자 검증
2. 서버와 직접 통신
3. UI 직접 다루기

자, 그럼 validateAndRegisterUser 함수가 작동하는 테스트할 조건을 모두 나령해보자.

1. user가 null이면 에러를 낸다.
2. null인 user는 서버로 전송하지 않는다.
3. user가 null이면 UI를 업데이트하지 않는다.
4. user가 undefined이면 에러를 낸다.
5. undefined인 user는 서버로 전송되지 않는다.
6. user가 undefined이면 UI를 업데이트하지 않는다.
7. user의 name 프로퍼티가 빈 상태면 에러를 낸다.
8. name 프로퍼티가 빈 user는 서버로 전송하지 않는다.
9. user의 name 프로퍼티가 비어 있으면 UI를 업데이트하지 않는다.

이 밖에도 오류 조건은 더 있다.

이 코드는 테스트할 수는 있지만 까다롭다. 테스트할 조건이 엄청 다양하게 조합될 수 있고 이들을 죄다 보완하는 건 불가능에 가깝다. 애플리케이션 코드를 전부 이렇게 작성하면 단위 테스트 영역이 적합하지 않다고 확실히 말할 수 있다.

그럼, 세 관심사를 validateAndRegisterUser 함수에 다 맡기지 말고 별개의 객체로 각 관심사를 추출하여 단일 책임을 부여하면 어떨까? 이렇게 만든 독립적인 객체는 각자 완전한 테스트 꾸러미를 갖게 될 테고 validateAndRegisterUser 코드는 이런 모습을 갖추게 될 것이다.

var Users = Users || {};

Users.registration = function(userValidator, userRegister, userDisplay) {
  return {
    validateAndRegisterUser: function validateAndDisplayUser(user) {
      if (!userValidator.userIsValid(user)) {
        throw new Error('사용자 인증이 실패했습니다.');
      }

      userRegister.registerUser(user);
      userDisplay.showRegistrationThankYou(user);
    }
  };
};

새로 고친 registration 모듈은 user 검증, 등록, 화면 표시를 담당하는 개별 객체 인스턴스를 의존성 주입으로 제공한다. 그리고 validateAndRegisterUser는 다른 관심사에게 직접 영향을 미쳤던 코드 대신 주입된 객체를 사용한다.

validateAndRegisterUser는 본질적으로 어떤 일을 하는 함수에서 남이 한 일을 조정하는 함수로 탈바꿈했다. 덕분에 이 함수는 테스트하기 쉬워져서 다음 여섯 조건만 확인하면 완벽한 기능 테스트를 할 수 있다.

1. user가 잘못 넘어오면 에러가 난다.
2. 잘못된 user를 등록하지 않는다.
3. 잘못된 user는 표시하지 않는다.
4. 올바른 user를 인자로 userRegister.registerUser 함수를 실행한다.
5. userRegister.registerUser에서 에러가 나면 userDisplay.showRegistrationThankYou 함수는 실행하지 않는다.
6. user가 성공적으로 등록되면 user를 인자로 userDisplay.showRegistrationThankYou 함수를 실행한다.

서로 다른 관심사는 작고 간단한 모듈로 나누어 만들면 코드 작성과 테스트, 그리고 이해가 쉽다.

TDD가 개발 속도를 늦출 것으로 생각하는 사람도 있으리라. 관심사를 제대로 분리하지 않은 채 먼저 코딩하고 테스트를 작성하는 식으로 진행하면 정말 늦어지게 될 것이라 확신한다. 무수한 실수의 늪에 빠져 허우적거리기 전에 단위 테스트가 실수를 가능한 한 빨리 발견하는 길이라는 진리를 기억하라.

red-green-refactor 과정을 반복하며 작은 코드를 개발하다 보면 점점 속도가 붙게 된다. 첫째, 작은 코드는 대개 간단하고 실수할 가능성이 작아 디버깅 시간을 상당히 줄일 수 있다. 둘째, 테스트로 코드를 완전히 커버하니 리팩토링을 하더라도 무서울 게 없다.

따라서 코드를 DRY하게 유지하여 코드베이스에 오류 발생 여지를 줄이고 규모를 작게 가져할 수 있다. DRY는 결국 재사용을 의미하며 알다시피 재사용 가능한 코드는 시간을 절약한다.

📚 정리하기

자바스크립트의 사용 범위가 대규모 시스템으로 확대되면서 언어 자체의 거친 부분을 잘 다루는 일이 아주 중요해졌다. 개별 스크립트 파일로 코드를 나누는 것이 어떤 면에서는 좋은 생각이지만, 진정 모듈화는 아니라는 사실을 이야기했다. 검증된 소프트웨어 공학이론과 D3 사례로 예시한 설계 기회에 기반을 두라. 다섯 가지 SOLID 원칙과 DRY 원칙을 소개했다.

단위 테스트는 장기적인 관점에서 안정된 애플리케이션을 만들기 위한 최선의 투자다. 단위 테스트가 없으면 그저 애플리케이션이 잘 작동하기를 막연히 기도할 수밖에 없다.

테스트 주도 개발을 실천하면 여러 가지 혜택이 있다. 첫째, 장기적인 믿음성을 보장하는 단위 테스트 꾸러미를 구축한다. 둘째, 애플리케이션 객체에 적확한 인터페이스를 설계할 때 도움이 된다. 셋째, 놀랍게도 단위 테스트를 통해 코드를 더 빨리 개발할 수 있다.

테스트성을 높이려면 관심사를 분리하는 일에 집중하고 단일 책임 원칙이나 의존성 주입 같은 소프트웨어 공학 원칙을 잘 써먹는 게 중요하다.