자바스크립트 프로그램은 함수에서 모든 것을 처리.

함수는 비트를 옮기고 연산을 수행하기 위해 변수와 연산자를 사용.

코드의 가독성을 높이고 복잡도를 낮추려면 기본 포맷을 정한 후 변수, 함수, 연산자 사용법을 정해야 함.


4.1 변수 선언

  - 변수는 var 문을 이용하여 선언.

  - 자바스크립트에서 var는 스크립트 어느 곳에나 올 수 있고 또 여러 번 사용 가능.

  - 모든 변수 선언은 변수가 선언된 위치와 상관없이 함수의 최상단으로 끌어올려진다.

    -> 이것을 호이스트(hoist)라고 한다.

    -> 이로 인해 개발자들이 코드를 잘못 이해하는 일이 종종 발생.

  - for문에서도 변수 선언은 호이스팅(hoisting) 된다는 사실을 잘 인지하지 못하는 경우 발생.

  - 변수 선언을 하면 함수 최상단으로 변수가 끌어올려 지므로 어디에 선언하는지에 관계 없이 최상단에 변수를 선언하는 것과 같다.

  - 이러한 이유로 자바스크립트에서는 변수를 함수 이곳 저곳에 선언하지 않고 최상단에 한꺼번에 선언하는 스타일을 가장 많이 사용.


4.2 함수 선언

  - 함수 선언도 변수 선언처럼 자바스크립트 엔진에 의해 끌어올려진다

    -> 따라서 함수가 선언되기 전에 먼저 사용가능.

  - 자바스크립트 엔진이 해석하는 방법대로 코드를 작성해야 하므로 함수를 사용하기 전에 반드시 먼저 선언할 것을 권장.


4.3 함수 호출문에 공백 넣기

  - 일반적으로 함수 호출문은 복합문과 쉽게 구분할 수 있도록 함수명과 괄호 사이에 아무런 공백도 입력하지 않는 스타일을 권장

ex)

//좋은 예

doSomethind(item);


//나쁜 예: 복합문 처럼 보임.

doSomething (item); 


//복합문.

while (item) {

    //실행할 코드

}


4.4 함수 선언하고 바로 호출하기

  - 자바스크립트에서는 함수 이름이 없는 익명 함수를 선언할 수 있다.

  - 선언한 익명함수를 변수나 프로퍼티에 대입할 수 도 있다.

 var doSomething = function() {

    //함수 본문

};

  - 익명 함수는 선언과 동시에 호출할 수 있고 또 그 반환값을 변수에 할당하는 것도 가능.

  - 익명 함수 선언문 끝에 괄호를 열고 닫으면 바로 호출 가능.

 var value = functnio() {

    // 함수 본문


    return {

      message: "Hi"

    }

}();

  - 함수가 선언과 동시에 호출되었기 떄문에 변수 value에는 함수가 아닌 객체가 할당됨.

  - 이 패턴은 변수에 익명 함수를 할당하는 것과 상당히 유사해 보이는 문제점 발생.

  - 명확하게 하려면 함수 앞뒤에 괄호를 추가.


4.4.1 strict 모드

  - ECMAScript5부터 자바스크립트 문장을 해석하고 실행할 때 실수를 줄이기 위해 strict 모드가 도입.

  - strict 모드를 적용하려면 프라그마(자바스크립트 전처리기에 내리는 명령)를 추가

    -> "use strict"

  - 단순 문자열로 보이지만 ECMAScript5 자바스크립트 엔진은 이 코드를 만나면 strict 모드를 위한 전환 명령어로 인식.

  - 이 프라그마는 전역으로 사용 가능하며 함수 내부에서만 유효하도록 지역적으로도 사용 가능.

  - 일반적으로 전역으로 사용하는 것은 지양.


4.5 동등 연산자

  - 자바스크립트에서 사용할 때 타입 강제 변환이 일어나 다루기 까다롭다.

  - 주로 ==와 != 연산자를 사용할 떄 타입 강제 변환이 일어남.

    -> 서로 다른 데이터 타입을 비교할 때 타입을 강제 변환. 같은 데이터 타입을 비교할 떄는 변환하지 않는다.

  - null과 undefinded는 ECMAScript 표준에 따르면 같은 값으로 판단

  - 타입이 강제 변환되는 ==와 != 사용대진 === 와 !==를 사용하는 것이 좋음.

  - =-==와 !== 연산자는 타입 강제 변환없이 비교 연산을 수행.


4.6 eval()

  - eval()은 문자열로 된 자바스크립트 코드를 실행하는 함수.

 eval("alert('Hi!')");


var count = 10;

var number = eval("5 + count");

  - eval() 함수 외에도 문자열로 된 자바스크립트 코드를 실행하는 방법이 존재.

  - function 생성자, setTimeout(), setInterval()을 통해 자바스크립트 문자열을 실행 가능.

var myFunc = new Functino("alert('Hi!')");


setTimeout("document.body.style.background='red'", 50);


setInterval("document.title = 'It is now '" + (new Data()), 1000); 

  - 특별한 case가 아니면 eval(), setTimeout, setInterval 사용을 금하자.


4.7 기본 래퍼 타입

  - 기본 래퍼 타입은 String, Boolean, Number 세가지가 존재.

  - 각 타입은 전역 범위를 갖는 생성자가 존재하고 기본 데이터 타입에 해당하는 객체가 존재.

  - 기본 래퍼 타입은 다음 예제처럼 기본 데ㅣ터 타입을 객체처럼 사용할 수 있다.

var name = "Nicholas"

console.log(name.toUpperCase());

  - 변수 name은 객체가 아니고 기본 데이터 타입인 문자열 이지만 마치 객체인 것 처럼 toUpperCase() 메서드 사용 가능.

  - 자바스크립트 엔진에서 String타입으로 새로운 인스턴스를 우리도 모르게 생성하기 떄문이다. 

  - 구글 자바스크립트 스타일 가이드에서는 기본 래퍼 타입을 직접 사용하는 것을 금지.




















자바스크립트에서 if나 for와 같이 "문장"을 사용하는 방법은 두가지

여러 줄을 중괄호로 감싸는 방법과 중괄호를 사용하지 않는 방법

// 나쁜 예. 문법 상 문제는 없지만 권장하지 않음.

if (condition)

    doSomething(); 


// 나쁜 예, 문법 상 문제는 없지만 권장하지 않음.

if (condition) doSomething();


// 좋은 예

if (condition) {

    doSomething();

}


// 나쁜 예, 문법 상 문제는 없지만 권장하지 않음.

if (condition) { doSomething(); }

복합문은 반드시 중괄호를 사용.

한줄에 입력하지 말고 여러 중에 걸쳐 입력. 중괄호가 없으면 오해의 소지 발생.

if (condition)

    doSomething();

    doSomethingElse();


이 코드는 작성자의 의도를 알기 어렵다. 이렇게 작성할 일은 없겠지만, if문 안에 처리를 하려 하였으나 중괄호를 넣지 않은 것인지 doSomething()만 실행할 목적이였는지 분간하기 어렵다. 


다음 모든 복합문에서는 중괄호를 반드시 사용한다.

  if

  for

  while

  do... while

  try... catch.... finally 


3.1 중괄호 넣기

  - 중괄호 위치는 주로 두 가지 스타일로 많이 사용.

  - 첫 번째 스타일은 자바에서 사용하는 스타일

  - 자바 프로그래밍 언어 코드 컨벤션, 크락포드 코드 컨벤션, jQuery 코어 스타일 가이드, SproutCore 스타일 가이드, 구글 자바스크립트 스타일 가이드, Dojo 스타일 가이드에서도 해당 스타일 권장.

  if (condition) {

      doSomethind();

  } else {

      doSomethingElse();

  } 


  - 두 번째 스타일은 복합문이 시작하는 다음 줄에 중괄호를 입력하는 방식

  - 해당 스타일은 비주얼 스튜디오에서 이 방식을 강제화하고 있어 C#에서 주로 사용.

  - 자바스크립트에서는 권장하지 않으며, 구글 자바스크립트 스타일 가이드는 세미콜론 자동 입력(ASI) 에러가 발생할 수 있다는 이유로 사용을 금지하고 있음.

  if (condition)

  {

      doSomethind();

  }

  else

  {

      doSomethingElse();

  }


3.2. 복합문에서의 공백

  - 복합문을 시작할 때 공백을 입력하는 방식은 선호에 따라 결정할 문제.

  - 일반적으로 세 가지 스타일로 복합문에 공백을 입력.

  - 문장 이름, 괄호, 중괄호 사이에 아무 공백 없음.

  - Dojo 스타일 가이드에서 해당 스타일 권장.

  if(condition){

      doSomething();

  } 


  - 괄호를 열기 전과 닫은 후에 공백 하나씩 입력,

  - 크락포드 코드 컨벤션, 구글 자바스크립트 스타일 가이드에서 해당 스타일 권장

  if (condition) {

      doSomething();

  }


  - 시작하는 괄호와 닫는 괄호 앞 뒤에 공백 입력.

  - jQuery 코어 스타일 가이드에서 해당 스타일 권장.

  if ( condition ) {

      doSomething();

  }


3.3 switch 문

  - 초기 switch문은 C에서 시작되어 자바에 영향을 미치고 자바스크립트에 적용되는 과정을 거쳐 포맷이 너무 다양하고 다루기 까다롭다.

  - 문법은 비슷하지만, 자바스크립트의 switch문은 다른 언어와 동작이 다름.

  - 자바스크립트의 switch문은 어떤 타입이든 사용가능, 어떠한 표현식도 case문제 들어갈 수 있음. (다른 언어에서는 기본 데이터 타입과 상수만 사용가능)


3.3.1 들여쓰기

  - 아래와 같은 자바 스타일의 switch문을 대부분 사용.

  switch (condition) {

      case "first":

          // code

          break;


      case "second":

          // code

          break;


      case "third":

          // code

          break;


      default:

          // code

  }

해당 포맷의 특징은 다음과 같다.

  - 각 case 문은 switch문을 기준으로 한 단계 들여쓰기. 

  - 두 번째 case 문 부터 case 문 이전과 이후에 빈 줄을 삽입.

대부분의 에디터가 이 포맷의 switch문을 자동완성으로 지원.

  - 코딩 스타일에 대한 관점이 서로 다르므로 어떤 switch문을 사용하느냐는 모두 선호에 따라 결정할 문제.


3.3.2 다음 case 문까지 실행하는 switch문

  - 또 다른 논쟁거리는 "다음 case문 까지 실행하는 switch문(fall-through)를 허용할 것인가".

  - case 문에서 실수로 break문을 빠뜨려 버그가 발생하는 일은 흔히 발생.

  - 더글라스 크락포드는 이런 실수를 방지하고자 모든 case 문제 예외 없이 break, return, throw문으로 마쳐야한다고 주장.

  - 다음 case 문까지 실행하는 swith문도 다음 예제 처럼 명확하게 사용한다면 좋은 방법.

  switch (condition) {
      // 어떤 로직도 수행하지 않고 다음 case 문으로 넘어간다.

      case "first":

      case "second":

          // code

          break;


      case "third":

          // code

          

          /*falls through*/

      default:

          // code

  }

  - 작성자가 주석을 통해 의도적으로 사용했음을 명확하게 한다면 허용해도 된다고 판단.


3.3.3 default 절

  - 논쟁이 될만한 또 다른 요소는 "switch문제 default 절을 꼭 넣어야 하는가?"

  - default 절에 딱히 수행해야 할 로직이 없을 경우 // no default 주석을 통해 작성자의 의도를 명확하게 표현하면 문제 없다고 판단.

  - 추가로 필요없는 문법을 사용하지 않아 용량 절약.


3.4 with문

  - with문은 실행할 로직의 문맥을 변경

  - with문은 객체 식별자를 명시하지 않아도 특정 객체의 프로퍼티와 메서드를 마치 변수인 것처럼 사용하게 해줌.

  - with문의 목적은 객체 내 프로퍼티나 메서드에 접근 할 때, 개발자가 입력해야할 문자를 줄이는데 있다.

  var book = {

      title: "Maintainable JavaScript",

      author: "Nicholas C. Zakas"

  };


  var message = "The book is ";


  with(book) {

      message += title;

      message += " by " + author;

  } 

  - 위 코드에서 with문은 중괄호 안에서 book 변수의 프로퍼티를 마치 변수인 것처럼 사용.

  - 이때 title과 author의 주인이 어떤 객체인지 알기 어렵다는 문제.

  - 또 어떤 변수가 book의 프로퍼티인지, message는 지역 변수인지도 불명확.

  - 다른 개발자가 이해하기 어려울 수도 있다.

  - with문은 문법 에러가 발생할 확률이 높다 strict 모드에서는 사용할 수 없는데 이는 ECMAScript 위원회도 with문을 더는 사용하지 말아야 하는 구문이라 생각한다는 걸 의미.

  - 크락포드 코드 컨벤션, 구글 자바스크립트 스타일 가이드는 with문 사용을 금지.


3.5 for 반복문

  - for 반목문에는 2가지 타입 존재.

  - 전통적인 for 반복문과 객체의 프로퍼티를 순환하는 for...in 반복문이 존재.

  - 전통적인 반복문 제어하는 데는 return이나 throw문을 사용을 제외한 2가지 방법 존재.

  - 첫 번째는 break문 사용. break문을 사용하면 배열 끝에 도달하기 전에 반복문 종료

  - 두 번째는 continue 문 사용. continue는 반복문 내 로직 수행을 즉시 종료하지만, 다음 요소로 넘어가 순환을 계속 진행.

  - 크락포드의 코드 컨벤션에서는 continue 사용을 금지하고 있음.

  - 크락포드는 continue 보다 조건문을 사용하는 편이 낫다고 말한다.

  - 이유는 더 이해하기 쉽고 실수를 줄일 수 있기 떄문.


3.6 for...in 반복문

  - 객체의 프로퍼티를 순환할 떄 사용.

  - 조건문을 따로 정의하지 않고 프로퍼티를 순환하며 프로퍼티명을 반환.

  var prop;


  for (prop in object) {

      console.log("Property name is " + prop);

      console.log("Property value is " + object[prop]);

  } 


  - for...in 반복문의 문제점은 객체가 소유한 인스턴스의 프로퍼티만 반환하는 것이 아니고 상속 받은 프로토타입의 프로퍼티도 반환한다는 점.

  - 이러한 이유로 for...in 반복문 사용시 hasOwnProperty() 메서드를 사용해 현재 인스턴스의 프로퍼티만 걸러서 사용하는 방법이 좋다.

 var prop;


  for (prop in object) {

      if (object.hasOwnProperty(prop)) {

          console.log("Property name is " + prop);

          console.log("Property value is " + object[prop]);

      }

  }


  - 크락포드 코드 컨벤셔에서는 for...in반복문에는 hasOwnProperty() 메서드를 반드시 사용하도록 명시.

'JavaScript > Maintainable JavaScript' 카테고리의 다른 글

Chapter4. 변수, 함수, 연산자  (0) 2016.09.23
Chapter2. Javascript 주석  (0) 2016.09.06
Chapter1. JavaScript 기본 포맷  (0) 2016.09.03
Part1. 스타일 가이드 라인  (0) 2016.09.03
Maintainable JavaScript 시작.  (0) 2016.09.03

주석 작성은 개발보다는 문서 작성에 가까운 일.

고로, 개발자에게 가장 인기 없고 최대한 미루고 싶어하는 일 중에 하나.

하지만, 전체적인 코드의 유지보수를 위해 주석은 매우 중요.


2.1 한 줄 주석

  - 한 줄 주석은 두개의 슬래시를 이용하여 작성. 그 줄에서 끝남.

  - 보통 두 개의 슬래시를 입력하고 주석을 입력하기 전에 한칸 띄움.

  - 한줄 주석은 3가지 방법으로 사용.

  - 주석을 입력하기 전, 한 줄을 비우고 시작하며 주석은 설명할 코드 바로 윗줄에 작성.

    들여쓰기 단계는 설명할 코드에 맞춤.

  - 한 줄 주석은 꼬리 주석을 입력할 떄 사용. 줄 끝에 입력하는 꼬리 주석은 적어도 한 단계 들여쓰기를 한 후에 입력.

    이 때 꼬리 주석도 최대 줄 길이를 넘으면 안됨. 주석을 입력하기에 공간이 부족하면 코듸 윗줄에 주석 입력

  - 한 줄 주석은 코드를 주석처리 할 떄 사용. 

  - 코드를 주석 처리할 떄를 제외하고, 연속적으로 한 줄 주석 사용은 지양.

  - 주석이 길어지면 여러 줄 주석을 사용.


2.2. 여러 줄 주석

  - 여러 줄 주석은 말 그대로 여러 줄에 걸친 주석을 파일에 입력할 떄 사용.

  - /*로 시작하여 */로 끝남.

  - 여러 줄 주석을 이용해 한 줄만 입력해도 되고, 여러 줄로 입력해도 무방.

  - 여러 줄 주석도 한 줄 주석과 마찬가지로 주석 바로 윗 줄은 한 줄을 비우고 설명할 코드 바로 윗줄에 주석 입력.


2.3 주석 쓰기

  - 주석은 개발자 사이에서 항상 많은 논란을 야기.

  - 일반적으로는 명확하기 않은 것에 대해 주석을 쓰고, 코드 자체로 충분히 설명 가능한 부분에는 주석을 사용하지 않는다.

ex) 나쁜 예

// count 초기화

var count = 10;


//좋은 예


// 이 값을 수정하면, 큰 비가 내립니다.

var count = 10;


  - count 변수의 값을 변경하면 큰 비가 내린다는 말은 황당하지만, 주석이 없었다면 아무도 몰랐을 부분이니 이 주석은 적절하다고 볼수 있음. 

  - 일반적으로 주석은 코드를 명확하게 해야 할 곳에 추가해야 한다.


2.3.1 이해하기 어려운 코드

  - 이해하기 어려운 코드에는 반드시 주석을 추가해야 한다.

  - 코드의 역할에 따라 여러 줄 주석 또는 한 줄 주석을 여러 개 사용하거나 잘 혼용해서 사용.

ex) var mode = 1;  // 1, 2, 3, 4 블라블라

1, 2, 3, 4 중 하나의 값을 가지지만 1, 2, 3, 4가 무엇을 의마하는지 어렵다.

이럴때는 주석이 필수.


2.3.2 오해하기 쉬운 코드

  - 다른 개발자로 하여금 오해를 불어일으킬 수 있는 코드에는 주석 작성.

  - 일반적인 로직에서 벗어난 코드라던지, 특별한 이벤트를 위해 어쩔 수 없이 작성된 코드라던지 부가 설명이 없으면 이해할 수 없는 코드에 작성하면 좋다.


2.3.3 특정 브라우저 핵

  - 특정 브라우저를 지원하기 위해 작성한 코드인 경우 주석 작성.

  - 오래된 브라우저의 경우 크로스 브라우징이 안된다거나 브라우저 간 호환이 되지 않아 이를 처리 하기 위해 작성된 코드에는 주석을 작성하도록 한다.


2.4 문서화 주석

  - 문서화 주석은 기술적으로는 자바스크립트에서 지원하는 영역은 아님. 굉장히 많이 사용됨.

  - 문서화 주석에는 다양한 포맷이 있지만 JavaDoc 문서 포맷을 가장 많이 사용.

  - 여러 줄 주석과 유사하지만, 별표가 하나 더 붙어 /** 로 주석을 시작하고 다음줄 부터 항목 마다 @를 앞에 붙힌다.

  - 주석을 문서화하는 툴킷으로 JSDoc도 존재.

  - JSDoc은 특정 라이브러리에 구애받지 않고 사용가능.

  - 오픈소스 프로젝트에서 많이 사용되고 있으며 구글에서도 사용함.

  - 문서화 주석을 사용할 때는 아래 항목을 모두 만족해야 한다.

모든 메서드

  - 모든 메서드에 대한 설명이 추가. 인자 값이나 반환 값에 대한 설명도 있어야 함.


모든 생성자

  - 생성자에 대한 주석에는 사용자 정의 타입의 목적이 포함. 인자 값에 대한 설명 포함.


주석을 추가한 메서드를 가진 모든 객체

  - 객체의 메서드에 문서화 주석이 추가되었다면, 적절한 문서 생성을 위해 객체에도 주석 추가. 


"프로그램은 우선 사람이 이해할 수 있어야 한다. 컴퓨터에서 실행되는가는 부차적인 문제다."

  - 도널드 커누스


  - 각자 다른 일을 하던 사람들이 모여 처음 한 팀을 이룰 떄는, 코드 작성 방법도 통일되지 않고 제각각이기 마련.

  - 서로 다른 환경에서 일을 해왔기 때문에 코드 작성 방법에 대한 생각이 다를 수 있다.

  - 그러기에 작성 방법을 통일할 필요가 있다.


Note. "스타일 가이드라인" 과 "코딩 규칙"을 자주 혼동하여 사용.

스타일 가이드라인 : 소스 코드의 레이아웃에 초점을 맞춘 규칙.

코딩 규칙 : 프로그래밍 관례와 디렉터리 구조, 주석에 대한 것도 포함. 


스타일 가이드라인은 왜 필요한가?

  - 코드에 일관성이 있어야 더 이상 코딩 스타일 같은 사소한 일로 시간을 허비 하지 않고 깊은 논의가 가능.

  - 코드에 일관성이 생기면 팀에서 다음과 같은 장점을 얻을 수 있다.

  - 작성자와 상관없이 어떠한 파일이든 다른 개발자가 작업 가능.

또한 모든 파일에 일관싱이 있으니 포맷을 다시 맞추거나 꼬여있는 로직을 이해하는 데 시간 낭비할 필요가 없음.

  - 에러가 훨씬 잘 보임. 코드를 일관되게 작성하면 잘못된 부분은 일관적인 흐름에서 벗어나기 때문. 

  - 이러한 이유로 전 세계의 많은 기업이 내/외부적으로 스타일 가이드라인을 공개함.


유용한 툴

  - 코딩 가이드라인은 세우기도 어렵지만, 지키는 것도 굉장히 어렵다.

  - JSLint는 자바스크립트에 대한 일반적인 코드 품질 검증 툴로 더글라스 크락포드가 만듦.

  - 초기 JSLint는 자주 틀리는 자바스크립트 패턴을 찾는 간단한 유틸로 시작. 이후 코드에서 잠재적인 에러를 찾는 것 뿐만 아니라 스타일에 대한 이슈도 경고하도록 발전.

크락포드는 자바스크립트 스타일을 다음 세가지로 나누어 정리.

  - 자바스크립트 스타일 요소 1(http://javascript.crockford.com/style1.html)

    기본적인 패턴과 문법에 대해 다룬다.

  - 자바스크립트 스타일 요소 2(http://javascript.crockford.com/style2.html)

    일반적으로 사용하는 관용구를 다룬다.

  - 자바스크립트를 위한 코딩 규칙(http://javascript.crokford.com/code.html)

    스타일 요소1, 2,를 강조하고 스타일 가이드라인 코드를 추가 


  - JSHint는 JSLint에서 파생. 안톤 코발료프가 관리.

  - JSHint의 목적은 사용자 취향에 맞게 변경할 수 있는 자바스크립트 코드 품질과 스타일 가이드라인에 대한 툴을 제공.

  - 문법 에러를 제외하고 JSHint에서는 거의 모든 경고를 끌 수 있다.

  - 안톤 코발료프는 GitHub의 소스 코드 저장소를 통해 JSHint에 참여하고 기여하길 권장.


= 이러한 툴들은 빌드 프로세스에 포함시키면 코드에 숨어있는 잠재적인 에러도 잡을 수 있고, 코딩 규칙이 자리잡는데 좋은 시작점이 될 수 있다.

Maintainable JavaScript 책 정리 시작.

(읽기 좋은 자바스크립트 코딩 기법)


자바스크립트를 사용할 줄은 알았다.

정말 제대로 된 자바스크립트 코딩이였을까? 라는 질문에

"No. 그냥 대충 기능만 구현되도록 구글링 해서 어거지로 구현했어" 라는 답이 도출 됐다.


현재 앱 서비스의 서버파트 개발을 하고 있지만

Native App의 단점을 보완하고 서버 주도적인 서비스를 구축하고자 Hybrid 방식을 채택하기 시작했다.

(Native App의 단점이라면 한번 배포되면 회수가 불가능하다는 점과 웹 처럼 빠른 수정 및 대응이 불가능하다는 점 등등..)


결국 웹 페이지 작업은 진행해야 했고 깔끔하고 군더더기 없는 소스를 짜고 싶었기 떄문에

해당 책을 추천 받아 읽었고, 그 내용을 블로그에 정리하기로 했다.


지은이 말.

  - 웹 개발의 전문화는 어렵고 복잡한 과정으로 이루어져 왔다.

  - 대기업에서도 웹을 전문화시키는 과정에서 많은 시행착오를 겪어왔다,

  - 소유모의 기업에서 모든 웹 서비스를 혼자 담당하는 사람이면 무엇이든 원하는 대로 가능하겠지만 대부분의 프로그래머가 기업이라는 환경에서 일하게 되면서 혼자 하는 것이 아니라 팀 단위로 작업하는 방법을 알아가야 함.

  - 6년차 이직 이후 팀원들과 다른 방식으로 코드를 짜게 되는 것을 알게 되었고 그것이 문제가 있다고 판단.

  - 팀에 더 도움이 되도록 동료들과 같은 방식으로 작업 시작.

  - 생소한 부분은 그 부분을 잘 아는 동료의 작성 코드를 참고

  - HTML, CSS, 자바스크립트 코딩의 경우 동료에세 패턴을 적용해볼 것을 권하고 이를 표준으로 규정하기 위해 빌드 프로세스에 린트 추가.

  - 결과, 팀은 윤활유가 잘 칠해진 기계처럼 유기적인 업무 가능

  - 이미 익숙해진 프로세스 중에도 항상 옳지만은 않다.

  - 통일된 방법이 없으면 많은 개발자들은 각자의 방법대로 처리하고 그 결과 버그로 이어지기도 함.

  - 이 책은 '개인이 아닌, 팀의 일원으로 자바스크립트 코드를 작성하는 방법'에 관한 책이다.

  - 우리는 코드를 유지보수하는 데 대부분의 시간을 보내고 있다.

  - 동료에게 "우리는 자신을 위해 코드를 작성하는 것이 아니라 다음에 이 코드를 보게 될 사라믈 위해 작성하는 것" 이라는 말을 자주 했음.

  - 이 책은 자바스크립트 코딩 컨벤션과 이에 대한 논의로 구성.

  - 가장 유명한 코딩 컨벤션 문서인 '자바 프로그래밍 언어 코드 컨벤션' 에서는 다음과 같은 이유로 코딩 컨벤션의 중요성을 언급


  * 소프트웨어를 사용하면서 드는 비용의 80%는 유지보수에 사용된다.

  * 소프트웨어 생명주기 동안 최초 개발자가 끝까지 유지보수하는 경우는 거의 없다.

  * 코딩 컨벤션은 소프트웨어의 가독성을 향상시켜, 개발자가 새로운 코드를 더 빠르고, 더 완전하게 이해할 수 있게 한다.

  * 소스 코드를 제품화 시키려면, 다른 제품들처럼 깔끔하고 잘 패키지화되는 것을 보장할 수 있어야 한다.


앞으로도 코더가 아니라 개발자가 되고 싶다.

좋은 개발자가 되기 위해서 이 책은 좋은 안내서가 될 수 있다고 생각한다.

이 책은 결국 좋은 결과물을 만들기 위한 책 이기 떄문이다.

+ Recent posts