ES6 Overview

• let, const와 블록 레벨 스코프
• let으로 블록 레벨 스코프 변수를 지정한다.
• const로 상수를 지정한다.
• 호이스팅은 되지만 일시적 사각지대에 의해 undefined가 아닌 에러가 발생한다.
• for문에서 i를 사용할 때에도 클로저를 사용하지 않아도 된다.
• 템플릿 리터럴
• ` (backtick) 문자를 사용하여 템플릿 리터럴을 표기할 수 있다.
• 템플릿 리터럴 안에 ', "를 모두 사용할 수 있다.
• 화살표 함수
• function 키워드 대신 화살표(=>)를 사용하여 함수를 선언할 수 있다.
• arguments 프로퍼티가 없다.
• rest 파라미터(...args)를 사용하여 가변인자를 함수 내부에 배열로 전달할 수 있다.
• Arrow function은 자신만의 this를 생성하지 않고 자신을 포함하고 있는 컨텍스트로 부터 this를 계승 받는다.
• 그래서 메소드 정의 시 Arrow Function을 사용하는 것은 피해야 한다.
• Arrow Function은 prototype 프로퍼티를 가지고 있지 않다.
• 기본 파라미터 초기값, Rest 파라미터, Spread 연산자
• 파라미터에 초기값을 설정하여 함수 내에서 수행하던 파라미터 체크 및 초기화를 간편화할 수 있다.
• Rest 파라미터는 Spread 연산자(…)를 사용하여 파라미터를 작성한 형태를 말한다. 
• Rest 파라미터를 사용하면 인수를 함수 내부에서 배열로 전달받을 수 있다.
• Rest 파라미터는 반드시 마지막 파라미터이어야 한다.
• Spread 연산자(...[])는 연산자의 대상 배열을 개별 요소로 분리한다.
• 객체 리터럴 프로퍼티 기능 확장
• 프로퍼티 값으로 변수를 사용하는 경우, 프로퍼티 이름을 생략(Property shorthand)할 수 있다. 이때 프로퍼티 이름은 변수의 이름으로 자동 생성된다.
• 객체 리터럴 내에서 프로퍼티 이름을 동적으로 생성(Computed property name)할 수 있다.
• 메소드를 선언에 function 키워드를 생략 가능하다.
• 객체 리터럴 내부에서 __proto__ 프로퍼티를 직접 설정할 수 있다. 이것은 객체 리터럴에 의해 생성된 객체의 __proto__ 프로퍼티에 다른 객체를 직접 바인딩하여 상속을 표현할 수 있음을 의미한다.
• 디스트럭처링
• 배열의 각 요소를 배열로부터 추출하여 변수 리스트에 할당한다.
• 객체의 각 프로퍼티를 객체로부터 추출하여 변수 리스트에 할당한다.
• 클래스
• 새로운 객체지향 모델을 제공하는 것이 아니며 사실 클래스도 함수이고 기존 프로토타입 기반 패턴의 Syntactic sugar일 뿐이다.
• new 연산자를 사용하지 않고 인스턴스를 생성하면 에러가 발생한다.
• constructor는 인스턴스를 생성하고 초기화하기 위한 특수한 메소드이다.
• 클래스 바디에는 메소드만을 포함할 수 있다.
• getter는 어떤 프로퍼티에 접근할 때마다 프로퍼티를 조작하는 행위가 필요할 때 사용한다.
• setter는 어떤 프로퍼티에 값을 할당할 때마다 프로퍼티를 조작하는 행위가 필요할 때 사용한다.
• extends 키워드는 부모 클래스(Base class)를 상속하는 자식 클래스(Sub class)의 생성을 위해 클래스 선언에 사용된다.
• super()는 부모 클래스의 constructor를 호출한다. 즉, 부모 클래스를 생성한다. 자식 클래스의 constructor에서 super()를 호출하지 않으면 ReferenceError가 발생한다.
• super()를 호출하기 이전에는 this를 참조할 수 없다.
• 모듈
• 모듈이란 애플리케이션을 구성하는 개별적 요소로서 구현된 세부 사항을 캡슐화하고 공개가 필요한 API를 외부에 노출하여 다른 코드에서 로드하고 사용할 수 있도록 작성된 재사용 가능한 코드 조각을 말한다.
• 모듈 안에 선언한 모든 것들은 기본적으로 해당 모듈 안에서만 참조 가능하다. 만약 모듈 안에 선언한 항목을 외부에 공개하여 다른 모듈들이 사용할 수 있게 하고 싶다면 export해야 한다.
• 선언된 변수, 함수, 클래스 모두 export할 수 있다.
• 프로미스
• 자바스크립트는 비동기 처리를 위한 하나의 패턴으로 콜백을 사용한다. 
• 하지만 전통적인 콜백 패턴은 비동기 처리 중 발생한 에러의 예외 처리하기 곤란하고 여러 개의 비동기 로직을 한꺼번에 처리하는 것도 한계가 있다. 
• ES6에서 비동기 처리를 위한 또 다른 패턴으로 Promise가 등장했다. 
• Promise는 전통적인 콜백 패턴이 가진 단점을 일부 보완하며 비동기 처리 시점을 명확하게 표현한다.
• 이터레이션 프로토콜(iteration protocol)과 for-of 루프
• 이터러블(iterable)과 이터레이터(iterator)를 정의한 이터레이션 프로토콜(iteration protocol)이 추가되었다.
• for-of 루프는 이터러블 객체를 순회한다. 
• for-of 루프는 이터레이터의 next() 메소드를 호출하고 next() 메소드가 반환하는 객체의 done 프로퍼티가 true가 될 때까지 루핑한다.
• 7번째 타입 심볼(Symbol)
• Symbol은 애플리케이션 전체에서 유일하며 변경 불가능한(immutable) 기본 자료형(primitive)이다.
• 주로 객체의 프로퍼티 키(property key)로 사용한다.
• Symbol은 Symbol() 함수를 통해 생성한다.
• Symbol() 함수는 String(), Number(), Boolean()과 같이 래퍼 객체를 생성하는 생성자 함수와는 달리 new 연산자를 사용하지 않는다.
• Symbol 값은 애플리케이션 전체에서 유일한 값이기 때문에 Symbol 값을 키로 갖는 프로퍼티는 다른 어떠한 프로퍼티와도 충돌하지 않는다.
• Symbol() 함수는 매번 다른 Symbol 값을 생성하는 것에 반해, Symbol.for은 단 하나의 Symbol을 생성하여 여러 모듈이 공유하게 된다.
• 제너레이터
• 함수 블록을 한번에 실행하지 않고, 실행을 일시 중지했다가 필요한 시점에 다시 시작할 수 있는 함수이다.
• 제너레이터 함수는 function* 키워드로 선언한다. 그리고 하나 이상의 yield 구문을 포함한다.
• 제너레이터 함수를 호출하면 함수 블록이 실행되는 것이 아니라, 제너레이터 객체를 반환한다.
• 제너레이터 함수의 함수 블록을 실행하기 위해서는 제너레이터 함수가 생성한 제너레이터 객체의 next() 메소드를 호출한다. 
• yield 구문은 next() 메소드을 일시 중지시킨다.

ES8 Overview

 ECMAScript2017 (es8) 주요 스펙

• String padding

String.prototype.padStart(targetLength [, padString])
String.prototype.padEnd(targetLength [, padString])

• 메소드를 호출하는 문자열의 길이를 주어진 targetLength에 도달하도록 하는 메소드
• padString으로 전달된 문자열로 길이를 채울 수 있음
• padString 값을 따로 전달하지 않는 경우 공백으로 문자열의 길이를 채움
• padStarat의 경우는 문자열의 시작 부분에 값을 추가하여 문자열의 길이를 조정
• padEnd는 문자열의 끝 부분에 값을 추가하여 문자열의 길이를 조정
• targetLength의 크기가 함수를 호출하는 문자열의 길이보다 작을 경우 문자열의 길이는 변하지 않음
• padString으로 넘겨진 문자열로 길이를 맞출 경우, 각각의 문자열에 대해서 채워지고 길이를 넘어가게 되면 버려지게됨

• Object.entries(), Object.values()

Object.entries(obj);
Object.values(obj);

• entries 함수는 파라미터로 전달된 객체의 key-value를 배열로 반환합니다.
• values 함수는 파라미터로 전달된 객체의 value만을 배열로 반환합니다.

• Object.getOwnPropertyDescriptors

const object = {"1": "one", "2":"two", "3": "three"};
Object.getOwnPropertyDescriptor(object, "1");
// {
//     value: "one",
//     writable: true,
//     enumerable: true,
//     configurable: true
// }

• 주어진 객체 자신의 속성에 대한 속성 설명자(descriptor)를 반환
• ES8에서는 .getOwnPropertyDescriptors를 제공하여 전달된 객체의 모든 프로퍼티에 대한 descriptor에 접근할 수 있음

• 함수 매개 변수 목록에서 후행 쉼표

class Person {
    constructor(
        firstName,
        lastName,
        age,
    ) {
        this.firstName = firstName;
        this.lastName = lastName;
        this.age = age;
    }
}

• 함수 매개 변수에서 후행 쉼표가 가능
• 기존에는 syntax error 발생
• 수정이 필요할 경우, 수정이 필요한 파라미터의 한 줄만 수정하면됨 
• 함수를 호출할 때도 마찬가지로 후행 comma를 사용할 수 있음

• Async functions 

/* Promise 사용 */
const fetchData = () => {
    return new Promise(resolve => {
        setTimeout(() => {
            resolve('fetch complete!');
        }, 2000);
    });
};
console.log(`before`);
fetchData().then((data) => console.log(data));
console.log(`after`);
// console>
// before
// after
// fetch complete!

/* Async function 사용 */
const sayComplete = async () => {
    const message = await fetchData();
    console.log(`status: ${message}`);
}
console.log(`before`);
sayComplete();
console.log(`after`);
// console>
// before
// after
// status: fetch complete!

• ES8부터 공식 release 되었음

타입스크립트 코리아 : 기초 세미나

Typescript를 계속 공부하려고 마음만 먹다가 드디어 인프런의 타입스크립트 코리아 : 기초 세미나 강의를 수강하게 되었다.

결과적으로 타입스크립트는 컴파일되서 자바스크립트 코드가 결과물로 나오게 되는데

es6를 babel로 es5로 번들링하는 것과 같은 개념이다.

타입스크립트는 타입이 구체화되지 않아서 생기는 문제를 해결하기 위해 자바 등과 같이 타입을 명확하게 지정하게 하는데 es6와 결합이 되어 자바와 매우 유사하게 사용을 하게 된다.

타입스크립트는 개발시 타입을 명확하게 하여 데이터 자료를 명확하게 만들어 오류를 예방하고 개발 편의성을 높이며 런타임시가 아닌 컴파일 타임에서 오류를 잡아 오류가 발생할 수 있는 케이스를 현저하게 줄일 수 있게 하였다.

Angular 기본과 간단한 To-Do 어플리케이션 만들기

인프런 - Angular 기본과 간단한 To-Do 어플리케이션 만들기 강의를 수강하였다.

무료로 진행되는 인터넷 강의이고 AngularJS의 기초적인 내용이긴 했지만 Angular 2.0이 되면서 어떻게 변화되었고 어떻게 개발되는지 알 수 있는 좋은 기회가 되었다.

AngularJS 1.5 버전을 사용했었는데 좋은 기억으로 남았었다.

DI도 있었고 양방향 데이터 바인딩이라던지 프레임워크로서 구조를 통일화 하는 등 개발하기 편한 부분이 많이 있었다.

Angular 2.0이 되면서 많은 부분이 바뀌어 1.X 버전과는 전혀 다른 것이 되었다는 말이 많은데 강의나 다른 자료들을 통해서 보니 그런 말이 나올만 했다.
(이름 자체도 AngularJS 에서 Angular로 변화)

큰 개념 자체가 component 구조로 바뀌면서 틀이 변화 되었고 그에 따라 사용법도 크게 변화하였다.
(일부 사용법이 조금 남아있었지만 이마저도 용어가 변화되는 등 차이가 있었다.)

가장 잘 나간다는 React나 Vue도 component 기반으로 되어있고 추세가 component 이기 때문에 AngularJS도 이에 맞춰 나간 것이라 생각이 된다.

Angular 2.0은 버전업이 되어 Angular 4.X까지 나와있는데 2.0과 큰 차이가 없고 호환이 된다고 하지만 너무 빠른 버전업에 따른 변화는 개발자가 따라가기에 부담이 되고 서비스 적용에도 리스크가 있기 때문에 인기가 이전만 못하고 React나 Vue 등의 다른 프레임워크가 인기가 있다고 한다.

나부터도 지금은 Vue 기반으로 개발을 하고 있는데 Angular가 안정되고 다시 써볼 수 있는 기회가 있었으면 한다.

실용주의 프로그래머

 IT 고전(?)인 「실용주의 프로그래머」 를 읽었다.

과거 선배들이 적극 추천을 해주어 사놓긴 했는데 드디어 읽게 되었다.

바로 전에 읽은 「조엘 온 소프트웨어」 같이 프로그래밍을 하는데에 있어서 프로그래머가 지향해야할 방법들에 대해서 기술을 하였지만 「조엘 온 소프트웨어」는 블로그인 만큼 가볍고 재미있는 문체를 사용했다면 「실용주의 프로그래머」는 원론적인 이야기가 많았다.

그만큼 지루했다는 말도 될 수 있을 것 같다. ㅋㅋ 그리고 번역과정에서 뭔가 어색한 부분이 종종 있어서 읽고 지나가도 다시 한번 읽게 되는 부분이 적지 않았던 것 같고 이 책 역시 오래전(2005년)에 쓰여진 만큼 호랑이 담배피던 시절 이야기로 잘 이해가 가지 않는 부분도 있었다.
(02학번이라 05년도 내용이면 웬만큼 지식이 있어야 할것도 같지만.... ㅡㅡ;)

암튼 당연히 하고 있는 것들도 많고, 당연하지만 실제로는 실행하지 못하고 있는 것들도 있는데 이 책에서 팁이라고 정한 부분만 나열해 본다.

1. 자신의 기술에 관심과 애정을 가져라.
2. 자신의 일에 대해 생각하면서 일하라!
3. 어설픈 변명을 만들지 말고 대안을 제시하라.
4. 깨진 창문을 내버려두지 말라.
5. 변화의 촉매가 되라.
6. 큰 그림을 기억하라.
7. 품질을 요구사항으로 만들어라.
8. 지식 포트폴리오에 주기적으로 투자하라.
9. 읽고 듣는 것을 비판적으로 분석하라.
10. 무엇을 말하는가와 어떻게 말하는가 모두 중요하다.
11. DRY - 반복하지 마라
12. 재사용하기 쉽게 만들라.
13. 관련 없는 것들 간에 서로 영향이 없도록 하라.
14. 최종 결정이란 없다.
15. 목표물을 찾기 위해 예광탄을 써라.
16. 프로토타입을 통해 학습하라.
17. 문제 도메인에 가깝게 프로그래밍하라.
18. 추정을 통해 놀람을 피하라.
19. 코드와 함께 일정도 반복하며 조정하라.
20. 지식을 일반 텍스트로 저장하라.
21. 명령어 셸의 힘을 사용하라.
22. 하나의 에디터를 잘 사용하라.
23. 언제나 소스코드 관리 시스템을 사용하라.
24. 비난 대신 문제를 해결하라.
25. 디버깅을 할 때 당황하지 마라.
26. 'select'는 망가지지 않았다.
27. 가정하지 마라. 증명하라.
28. 텍스트 처리 언어를 하나 익혀라.
29. 코드를 작성하는 코드를 작성하라.
30. 완벽한 소프트웨어는 만들 수 없다.
31. 계약에 따른 설계를 하라.
32. 일찍 작동을 멈추게 하라.
33. 단정문을 사용해서 불가능한 상황을 예방하라.
34. 예외는 예외적인 문제에 사용하라.
35. 시작한 것은 끝내라.
36. 모듈간의 결합도를 최소화하라.
37. 통합하지 말고 설정하라.
38. 코드에는 추상화를, 메타데이터에는 세부 내용을.
39. 작업흐름 분석을 통해 동시성을 개선하라.
40. 서비스를 사용해서 설계하라.
41. 언제나 동시성을 고려해 설계하라.
42. 모델에서 뷰를 분리하라.
43. 칠판을 사용해 작업흐름을 조율하라.
44. 우연에 맡기는 프로그래밍을 하지 말라.
45. 여러분의 알고리즘의 차수를 추정하라.
46. 여러분의 추정을 테스트하라.
47. 일찍 리팩터링하고, 자주 리팩터링하라.
48. 테스트를 염주에 두고 설계하라.
49. 소프트웨어를 테스트하라. 그렇지 않으면 사용자가 테스트하게 될 것이다.
50. 자신이 이해하지 못하는, 마법사가 만들어준 코드는 사용하지 말라.
51. 요구사항을 수집하지 말고 채굴하라.
52. 사용자처럼 생각하기 위해 사용자와 함께 일하라.
53. 구체적인 것보다 추상적인 것이 더 오래간다.
54. 프로젝트 용어사전을 사용하라.
55. 생각의 틀을 벗어나지 말고, 틀을 찾아라.
56. 준비가 되었을 때 시작하라.
57. 어떤 일들은 설명하기보다 실제로 하는 것이 더 쉽다.
58. 형식적 방법의 노예가 되지 마라.
59. 비싼 도구가 더 좋은 설계를 낳지는 않는다.
60. 팀을 기능 중심으로 조직하라.
61. 수작업 절차를 사용하지 말라.
62. 일찍 테스트하고, 자주 테스트하라. 자동으로 테스트하라.
63. 모든 테스트가 통과하기 전엔 코딩이 다 된게 아니다.
64. 파괴자를 써서 테스트를 테스트하라.
65. 코드 커버리지보다 상태 커버리지를 테스트하라.
66. 버그는 한 번만 잡아라.
67. 환국어도 하나의 프로그래밍 언어인 것처럼 다루라.
68. 문서가 애초부터 전체의 일부가 되게하고, 나중에 집어넣으려고 하지 말라.
69. 사용자의 기대를 부드럽게 넘어서라.
70. 자신의 작품에 서명하라.