JavaScript의 프로퍼티는 키와 값으로 구성된 추상적인 개념으로 객체의 member입니다.

const obj = {
  a: 1,
  b() {},
};

obj라는 객체가 있다면, "a"-1, "b"-function 조합이 obj 객체의 프로퍼티입니다.

프로퍼티 어트리뷰트

JavaScript 엔진은 프로퍼티를 생성할 때 프로퍼티의 상태를 나타내는 프로퍼티 어트리뷰트를 기본값으로 자동 정의합니다. 프로퍼티 어트리뷰트는 자바스크립트 엔진의 내부로직이므로 직접 접근할 수는 없고 Object.getOwnPropertyDescriptor 메서드를 사용하여 반환하는프로퍼티 디스크립터 객체를 통해 간접적으로 접근할 수 있습니다.

프로퍼티 종류

프로퍼티는 데이터 프로퍼티와 접근자 프로퍼티로 구분할 수 있습니다.

1. 데이터 프로퍼티 (data property) 키와 값으로 구성된 일반적인 프로퍼티입니다.
2. 접근자 프로퍼티 (accessor property) 자체적으로는 값을 갖지 않고 다른 데이터 프로퍼티의 값을 읽거나 저장할 때 호출하는 접근자 함수로 구성된 프로퍼티입니다.

데이터 프로퍼티

키와 값으로 구성된 일반적인 프로퍼티입니다.

const person = {
  name: 'Lee',
};

console.log(Object.getOwnPropertyDescriptor(person, 'name');
// { value: "Lee", writable: true, enumerable: true, configurable: true }

위 예제처럼 프로퍼티가 생성될 때 [[Value]]의 값은 프로퍼티 값으로 초기화되며 [[Writable]], [[Enumerable]], [[Configurable]]의 값은 true로 초기화됩니다.

접근자 프로퍼티

다른 데이터 프로퍼티의 값을 읽거나 저장할 때 호출하는 접근자 함수로 구성된 프로퍼티입니다.

const person = {
  // 데이터 프로퍼티
  firstName: 'Ungmo',
  lastName: 'Lee',

  // fullName은 접근자 함수로 구성된 접근자 프로퍼티다.
  // getter 함수
  get fullName() {
    return `${this.firstName} ${this.lastName}`;
  },
  // setter 함수
  set fullName() {
    [this.firstName, this.lastName] = name.split(' ');
  }
};

// 데이터 프로퍼티
let descriptor = Object.getOwnPropertyDescriptor(person, 'firstName');
console.log(descriptor);
// {value: 'Ungmo', writable: true, enumerable: true, configurable: true}

// 접근자 프로퍼티
descriptor = Object.getOwnPropertyDescriptor(person,'fullName');
console.log(descriptor);
// {get: f, set: f, enumerable: true, configurable: true}

접근자 프로퍼티 내부동작원리

접근자 프로퍼티 fullName으로 프로퍼티 값에 접근하면 내부적으로 [[Get]] 내부 메서드가 호출되어 다음과 같이 동작합니다.

1. 프로퍼티가 유효한지 확인(문자열 || 심벌)
2. 프로토타입 체인에서 프로퍼티 검색
3. 데이터 프로퍼티인지 접근자 프로퍼티인지 확인
4. 접근자 프로퍼티의 프로퍼티 어트리뷰트 [[Get]]의 값, 즉 getter함수를 호출하여 그 결과를 반환

프로토타입은 어떤 객체의 상위(부모) 객체의 역할을 하는 객체입니다. 프로토타입은 하위(자식) 객체에게 자신의 프로퍼티와 메서드를 상속합니다.

프로퍼티 정의

1. 프로퍼티 어트리뷰트 정의(새로운 프로퍼티 추가)
2. 프로퍼티 어트리뷰트 재정의

Object.defineProperty 메서드를 사용하면 하나의 어트리뷰트를 정의할 수 있으며 Object.defineProperties 메서드를 사용하면 여러 개의 프로퍼티를 한 번에 정의할 수 있습니다.

const person = {};

// 데이터 프로퍼티 정의
Object.defineProperty(person, 'firstName', {
  value: 'Ungmo',
  writable: true,
  enumerable: true,
  configurable: true,
});
let descriptor = Object.getOwnPropertyDescriptor(person, 'firstName');
console.log('firstName' , descriptor);
// firstName {value: "Ungmo", writable: true, enumerable: true, configurable: true}

Object.defineProperty(person, 'lastName', {
  value: 'Lee',
});
// 디스크립터 객체의 프로퍼티를 누락시키면 undefined, false가 기본 값이다.
descriptor = Object.getOwnPropertyDescriptor(person, 'lastName');
console.log('lastName' , descriptor);
// lastName {value: "Lee", writable: false, enumerable: false, configurable: false)

// 접근자 프로퍼티 정의
Object.defineProperty(person, 'fullName', {
  //getter 함수
  get() {
    return `${this.firstName} ${this.lastName}`;
  },
  set(name) {
    [this.firstName, this.lastName] = name.split(' ');
  },
  enumerable: true,
  configurable: true
});

descriptor = Object.getOwnPropertyDescriptor(person, 'fullName');
console.log('fullName ', descriptor);
// fullName {get: f, set: f, enumerable: true, configurable: true}

person.fullName = 'Heegun Lee';
console.log(person); // {firstName: "Heegun", lastName: "Lee"}

객체 변경 방지

객체는 변경 가능 값이므로 재할당없이 직접 변경할 수 잇다. 이에 JavaScript는 객체 변경을 방지하는 다양한 메서드를 제공합니다.

불변 객체

위 변경 변경 방지 메서드들은 얕은 변경 방지로 직속 프로퍼티만 변경이 방지되고 중첩객체까지는 영향주지 못합니다. 중첩객체까지 동결하기 위해선 모든 프로퍼티에 대해 재귀적으로 Object.freeze 메서드를 호출해야 합니다.

결론

JavaScript는 프로토타입 기반 객체지향 언어이므로 객체의 member인 프로퍼티 구성원리를 아는 것은 중요합니다. 이 장을 읽기 전에는 동적 추가방식으로만 프로퍼티를 정의 및 재정의했었는데 프로퍼티 어트리뷰트를 기반으로 데이터의 구조를 명확하게 보이며 접근할 수 있을 듯 합니다.

참고자료

• 모던자바스크립트 딥다이브, 이웅모
• https://developer.mozilla.org/en-US/docs/Glossary/Property/JavaScript

변수는 자신이 선언된 위치(렉시컬 스코프)에서 생성되고 소멸합니다.

전역 변수의 생명주기는 전역객체의 생명주기와 같고 지역 변수의 생명주기는 함수의 생명주기와 일치합니다.

스코프를 참조하고 있는 경우에는 소멸하지않고 생존하겠지만 그렇지 않다면 위와 같습니다.

비교

스코프

var 키워드로 선언한 변수는 오로지 함수의 코드 블록만을 지역 스코프로 인정해서 함수 외부에서 var 키워드로 선언한 변수는 모두 전역변수가 됩니다.

함수레벨 스코프는 전역 변수가 많아질 수 있는데, 전역 변수는 의도치않은 중복 선언등의 변화가 많으므로 지양해야 합니다.

중복선언

var 키워드로 선언한 변수는 중복선언해도 에러가 발생하지 않습니다. 의도치않은 중복선언은 변수 값이 재할당되는 부수효과가 발생되므로 지양해야합니다.

let과 const는 중복 선언 시 문법 에러가 발생합니다.

재할당

const로 선언한 변수에 원시값을 할당한 경우 변수 값을 변경할 수 없습니다. 이 값은 상수로 대문자&&스네이크케이스로 표기합니다. 만약 const로 선언한 변수에 객체 값을 할당한 경우에는 값을 변경할 수 있습니다. 즉, const 키워드는 재할당을 금지할 뿐 불변을 의미하지 않습니다.

var와 let으로 선언한 변수에는 재할당이 가능합니다. 재할당이 가능하다는 것은 데이터 신뢰도를 약화시키는 부작용이 있습니다.

변수 호이스팅

자바스크립트의 모든 선언은 스코프 단위로 호이스팅이 발생합니다. 그러나 let, const로 선언한 변수는 선언단계와 초기화 단계가 분리되어 변수 호이스팅이 동작하지 않는 것처럼 보입니다.(undefined Reference Error).

스코프의 시작 시점부터 초기화 시작 시점까지 변수를 참조할 수 없는 구간을 일시적 사각지대(Temporal Dead Zone:TDZ)라고 부릅니다.

결론

Always const Sometimes let, Naver var

변수의 스코프를 최대한 좁게 만들기 위해 var보다는 let, const를 사용해야 합니다.

재할당은 추가 옵션의 느낌이므로 기본적으로 재할당이 불가한 const로 변수를 선언합시다.

느낀점

일시적 사각지대, 참조에러, 중복선언 금지, 재할당 금지 등 필요한 순간에만 활용될 코드를 짜기 위한 여러 장치들이 마련되어 있다는 느낌을 받았습니다. 저 역시 불필요한 코드는 작성되어서는 안된다는 주의기에 이러한 장치를 잘 활용해보겠습니다.

모든 식별자(변수 이름, 함수 이름, 클래스 이름 등)는 자신이 선언된 위치에 의해서 다른 코드가 식별자 자신을 참조할 수 있는 유효범위인 스코프가 결정됩니다.

자바스크립트 엔진은 스코프를 통해 어떤 식별자를 참조해야 할 것인지 결정합니다.

스코프의 종류

스코프 체인

자바스크립트 엔진은 스코프 체인을 통해 참조할 변수를 검색합니다. 스코프는 함수의 중첩에 의해 계층적 구조를 갖습니다. 모든 스코프는 하나의 계층적 구조로 연결되며 모든 지역 스코프의 최상위 스코프는 전역 스코프다. 이처럼 스코프가 계층적으로 연결된 것이 스코프 체인입니다.

자바스크립트 엔진은 스코프 체인을 따라 식별자를 참조하는 코드의 스코프에서 시작해서 상위 스코프 방향으로 이동하며 선언된 식별자를 검색합니다.

렉시컬 스코프

프로그래밍 언어는 일반적으로 함수를 어디서 호출했는지와 함수를 어디서 정의(선언)했는지에 따라 함수의 상위 스코프를 결정합니다.

함수 정의가 평가되는 시점에 상위 스코프가 정적으로 결정되는 방식을 렉시컬 스코프(lexical scope) 또는 정적 스코프라고 합니다. 렉시컬(lexical)은 어휘의라는 사전적 의미를 갖는데, 정의라는 개념과 연관지어서 기억하면 좋을 듯 합니다.

자바스크립트는 렉시컬 스코프를 따르므로 함수를 어디서 정의했는지에 따라 상위 스코프를 결정합니다. 즉, 함수의 상위 스코프는 언제나 자신이 정의된 스코프입니다.

배운점

동일한 식별자가 코드 내에 여러번 작성되어있으면 무엇을 가리키는지 명확하게 알지 못했습니다. 이번 기회에 자바스크립트 엔진이 식별자를 검색하는 원리에 대해서 알게되었고 확실하게 식별자가 가리키는 것을 식별해낼 수 있을 듯 합니다.

자바스크립트 엔진은 웹 개발자와 브라우저 간의 전달자 역할을 한다고 생각됩니다. 전달자가 어떤 방식으로 전달하는 지를 명확히 알아야 내가 원하는 바를 정확하게 전달할 수 있으므로 자바스크립트 엔진의 작동방식에 대해 주의깊게 살펴봐야겠습니다.

1. 함수 선언문
2. 함수 표현식
3. Function 생성자 함수
4. 화살표 함수(ES6~)

위 4가지의 미묘하지만 중요한 차이에 대해 알아보겠습니다.

함수 선언문

function add(x, y) {
    return x + y;
}

함수 선언문은 함수 표기방식인 함수 리터럴과 형태는 동일하지만 함수 이름을 생략할 수 없다는 점이 다릅니다.

함수 선언문은 표현식이 아닌 문입니다. 표현식인 문이라면 그 자체로 평가되어 값이 출력되겠지만 함수 선언문은 undefined를 출력합니다. 그리고 표현식이 아니기에 변수에 할당할 수 없습니다.

자바스크립트 엔진은 함수 선언문을 해석해 함수 객체를 생성합니다. 이때 함수 이름은 함수 몸체 내부에서만 유효한 식별자이므로 함수 이름과는 별도로 생성된 함수 객체를 가리키는 식별자가 필요합니다. 그래서 자바스크립트 엔진은 생성된 함수를 호출하기 위해 함수 이름과 동일한 이름의 식별자를 암묵적으로 생성하고 거기에 함수 객체를 할당합니다.

여기서 중요한 것은 함수는 함수 이름으로 호출하는 것이 아니라 함수 객체를 가리키는 식별자로 호출한다는 점입니다.

함수 표현식

자바스크립트의 함수는 일급 객체입니다. 값처럼 변수에 할당 할수도 있고 프로터피 값이 될 수도 배열의 요소가 될 수 도 있습니다. 함수를 변수에 할당하는 방식으로 정의된 것이 함수 표현식입니다.

const add = function (x, y) {
    return x + y; 
}

함수 표현식은 함수 이름을 생략하는 익명함수인 경우가 일반적입니다.

표현식이 아닌 문이었던 함수 선언문과 달리 함수 표현식은 표현식인 문입니다. 이는 중요한 차이를 만듭니다.

함수 선언문 vs. 함수 표현식

자바스크립트 엔진은 런타임 이전에 컴파일 과정을 거칩니다. 이때 모든 식별자들이 선언되는데, 함수 선언문 역시 이때 함수 객체를 생성하고 식별자에 함수객체를 할당하게 됩니다. 이로 인해 함수 선언문이 코드의 선두로 끌어 올려진 것처럼 동작하는 함수 호이스팅이 발생하는 것입니다.

함수 호이스팅 vs. 변수 호이스팅

호이스팅은 런타임 이전에 자바스크립트 엔진에 의해 식별자를 생성한다는 것입니다. 이때 변수는 undefined를 출력하고 함수는 생성된 함수 객체를 출력한다는 점이 다릅니다.

함수 표현식은 변수에 할당되는 값이 함수 리터럴인 문입니다. 따라서 함수 표현식은 런타임 이전에 변수 선언이 실행되어 undefined로 초기화되고 런타임에 할당되어 함수객체가 됩니다. 따로 표현하자면 함수 표현식은 변수 호이스팅이 발생합니다. 이것이 함수 표현식과 함수 선언문의 중요한 차이입니다.

그래서 뭘 써야하는데?

일반적으로 함수를 호출하기 전에 반드시 함수를 선언해야한다는 규칙이 있습니다. 함수 호이스팅은 이에 반하는 방식이기에 함수 선언문이 아닌 함수 표현식을 사용하는 것이 권장됩니다.

화살표 함수

ES6에 도입된 화살표 함수는 간략한 표현방식은 물론 내부 동작 또한 간략화되어있어 함수 표현식을 완전히 대체하지 않습니다.

const add = (x, y) => x + y;

1. 화살표 함수는 생성자 함수로 사용할 수 없습니다.
2. 화살표 함수는 기존 함수와 this 바인딩 방식이 다릅니다.
3. 화살표 함수는 prototype 프로퍼티가 없습니다.
4. 화살표 함수는 arguments 객체를 생성하지 않습니다.

위 4가지는 추후에 더 공부해보고 화살표 함수가 왜 나왔고, 함수 표현식 사용이 권장되는 이유에 대해 다시한번 고민해보겠습니다.

느낀점

자바스크립트는 자유도가 높은 언어인만큼 필요에 의해 발전하는 부분도 많습니다. 발전되는 부분은 다 개발자의 필요에 의해서 변화되는 것이기에 왜 이런 방식이 사용되는가에 대해 항상 고민하면서 사용하겠습니다.

자바스크립트가 제공하는 데이터타입은 7가지이고, 이는 원시 타입(Primitive type)과 객체 타입(Object/Reference typr)으로 구분할 수 있습니다. 원시타입인 숫자 / 문자열 / null / undefined / boolean / symbol 외에는 모두 객체 타입입니다.

원시타입과 객체타입을 구분하는 3가지 이유

원시값

한번 갱성된 원시 값은 읽기 전용(read only) 값으로서 변경할 수 없다.

값이란?

변수에 저장된 데이터로서 표현식이 평가되어 생성된 결과를 의미 변수에 저장된 값 자체를 변경할 수 없다는 것이지, 변수는 재할당을 통해 변수값을 교체할 수 있다. 교체하려면 원시 값을 재할당하여 새로운 메모리 공간을 확보하고 재할당한 값을 저장한 후, 변수가 참조하던 메모리 공간의 주소를 변경해야 한다. 값의 이러한 특성을 불변성(immutability)이라 한다.

값에 의한 전달

변수에 원시 값을 갖는 또 다른 변수를 할당하면 할당받는 변수에는 할당되는 변수의 원시값이 복사되어 전달된다. 이를 값에의한 전달이라 한다. 복사되어 전달 되지만 두 값은 다른 메모리 공간에 저장된 별개의 값으로, 서로 어떠한 영향도 주지 않는다.

객체

객체(참조) 타입의 값, 즉 객체는 변경 가능한 값(mutable value)이다.

변경 가능하다는 의미는?

원시값을 갖는 변수의 값을 변경하려면 재할당외에는 방법이 없지만, 객체는 재할당 없이 프로퍼티를 동적으로 추가할 수도 있고 프로퍼티 값을 갱신할 수도 있으며 프로퍼티 자체를 삭제할 수 있다. 왜냐하면 객체를 갖는 변수가 갖는 값은 참조값으로 메모리 공간의 주소 그 자체다. 그 참조 값으로 실제 객체에 접근하는 것이다.

얕은 복사 vs. 깊은 복사

스프레드 문법(...)으로 참조값만을 복사하는 것을 얕은 복사라고 하며 얕은 복사를 한 변수는 복사한 그 객체와 참조값(메모리 주소)만 같을 뿐 다른 값이다. 이와 다르게 깊은 복사는 중첩되어 있는 객체까지 모두 복사하는 것으로 둘은 같은 값을 가리킨다.

참조에 의한 전달

값에 의한 전달과 참조에 의한 전달은 식별자가 기억하는 메모리 공간에 저장되어 있는 값을 복사해서 전달한다는 면에서 동일하다. 값에 의한 전달은 원시값 그 자체를 전달하고, 참조에 의한 전달은 참조값(메모리 주소)을 전달하는 것이 다른 것이다.

=== 일치 비교 연산자

=== 일치 비교 연산자는 변수에 저장되어 있는 값을 타입 변환하지 않고 비교한다. 객체를 할당한 변수는 참조 값을 가지고 있고, 원시값을 할당한 변수는 원시 값 자체를 가지고 있으므로 === 일치 비교 연산자를 통해 객체에 할당한 변수를 비교하면 참조 값(메모리 주소)을 비교하고 원시 값을 할당한 변수를 비교하면 원시 값을 비교하는 것이다.

느낀점

같은 형태의 객체를 === 일치비교 연산자로 비교했을때 false가 나오는 것을 이해하지 못했는데 그 원리를 이해할 수 있어서 좋았다. 단순히 코드를 짜는 것에 그치지않고 그 안에 작동되는 원리를 이해하려고 노력해야겠다.

trouble

깃허브에 있는 50projects50days의 시계어플 코드를 공부하던 중 scale(seconds, 0, 60, 0, 360)이라는 함수가 나왔다.

function setTime() {
    const time = new Date();
    const month = time.getMonth()
    const day = time.getDay()
    const date = time.getDate()
    const hours = time.getHours()
    const hoursForClock = hours >= 13 ? hours % 12 : hours;
    const minutes = time.getMinutes()
    const seconds = time.getSeconds()
    const ampm = hours >= 12 ? 'PM' : 'AM'

    hourEl.style.transform = `translate(-50%, -100%) rotate(${scale(hoursForClock, 0, 12, 0, 360)}deg)`
    minuteEl.style.transform = `translate(-50%, -100%) rotate(${scale(minutes, 0, 60, 0, 360)}deg)`
    secondEl.style.transform = `translate(-50%, -100%) rotate(${scale(seconds, 0, 60, 0, 360)}deg)`

    timeEl.innerHTML = `${hoursForClock}:${minutes < 10 ? `0${minutes}` : minutes} ${ampm}`
    dateEl.innerHTML = `${days[day]}, ${months[month]} <span class="circle">${date}</span>`
}

1st try - 공식문서

CSS에서 scale()는 자주 사용했어서 그걸 활용한 진화버전이라고 생각하고 공식문서를 찾아보았는데 5개의 인수가 활용된 것은 없었다.

2nd try - 구글링

구글링해보았으나 작성된 코드만 나와있고 그것을 분석한 글은 없었다. 어려운 코드였다면 설명하거나 분석한 글이 있었을텐데 없었다. 이때 다시 코드를 확인했었어야했다...

3rd try - 동료

같이 공부하는 코딩동료들에게 DM을 보내 어떤 코드인 줄 아느냐고 여쭤보았다. 답을 기다리는 동안 다시 코드를 읽어봤는데...

shooting

사용되는 컨텍스트 바깥에 전역 컨텍스트로 scale이 정의되어있었다. 사용자 정의함수였던 것이었다.

function setTime() {
    const time = new Date();
    const month = time.getMonth()
    const day = time.getDay()
    const date = time.getDate()
    const hours = time.getHours()
    const hoursForClock = hours >= 13 ? hours % 12 : hours;
    const minutes = time.getMinutes()
    const seconds = time.getSeconds()
    const ampm = hours >= 12 ? 'PM' : 'AM'

    hourEl.style.transform = `translate(-50%, -100%) rotate(${scale(hoursForClock, 0, 12, 0, 360)}deg)`
    minuteEl.style.transform = `translate(-50%, -100%) rotate(${scale(minutes, 0, 60, 0, 360)}deg)`
    secondEl.style.transform = `translate(-50%, -100%) rotate(${scale(seconds, 0, 60, 0, 360)}deg)`

    timeEl.innerHTML = `${hoursForClock}:${minutes < 10 ? `0${minutes}` : minutes} ${ampm}`
    dateEl.innerHTML = `${days[day]}, ${months[month]} <span class="circle">${date}</span>`
}

// StackOverflow https://stackoverflow.com/questions/10756313/javascript-jquery-map-a-range-of-numbers-to-another-range-of-numbers
const scale = (num, in_min, in_max, out_min, out_max) => {
    return (num - in_min) * (out_max - out_min) / (in_max - in_min) + out_min;
}

동료에게 모르겠다고 물었던 나 자신이 너무 창피했다. 그리고 너무 미안했다.

느낀점

1. 모르는 코드가 나온다면 일단 검색하여 관련 코드를 읽자.

-> 이것만 했어도 문제가 해결되었다...(멍청이...)

2. 함수명을 상세히 작성하자. 그리고 일반적으로 사용되는 함수명과 겹치게 작성하지 말자.

3. 실행컨텍스트를 잘 활용하자. 컨텍스트 안에서만 활용되는 함수는 전역으로 빼지말자.

4. 무작정 묻지 말자 제발... 민폐다

인용 글은 별도의 표기방식을 사용하였습니다.

02장 자바스크립트란?

2.1 자바스크립트의 탄생

1995년, ... 넷스케이프 커뮤니케이션즈는 웹 페이지의 보조적인 기능을 수행하기 위해 브라우저에서 동작하는 경량 프로그래밍 언어를 도입하기로 결정한다. 그래서 탄생한 것이 바로 브렌던 아이크 가 개발한 자바스크립트다.

자바스크립트가 등장하기 전 웹페이지는문서를 공유하기 위해 존재했습니다. 자바스크립트는 정적인 웹페이지를 동적으로 만들기 위해 등장했습니다.

2.2 자바스크립트의 표준화

이번 장은 자바스크립트의 표준화를 위한 ECMAScript 버전들이 등장하게 된 배경을 연도순으로 소개합니다.

1996년 8월, 마이크로소프트 는 자바슼크립트의 파생 버전인 JScript를 인터넷 익스플로러 3.0에 탑재했다. 그런데 문제는 JScript와 자바스크립트가 표준화되지 못하고 적당히 호환 되었다는 것이다. ... 이로 인해 브라우저에 따라 웹페이지가 정상적으로 동작하지 않는 크로스 브라우징 이슈가 발생하기 시작했고 ... 1996년 11월 넷스케이프 커뮤니케이션즈는 컴퓨터 시스템의 표준을 관리하는 비영리 표준화 기구인 ECMA 인터내셔널에 자바스크립트의 표준화를 요청한다. 1997년 7월, ECMA-262라 불리는 표준화된 자바스크립트 초판(ECMAScript 1) 사양이 완성되었고 상표권 문제로 자바스크립트는 ECMAScript로 명명되었다. ... 2015년 에 공개된 ECMAScript 6(ECMAScript 2015, ES6)는 ... 범용 프로그래밍 언어로서 갖춰야 할 기능들을 대거 도입하는 큰 변화가 있었다.

2.3 자바스크립트 성장의 역사

여기서 자바스크립트의 성장은 초창기 HTML과 CSS를 단순 렌더링한 수준에서 현재 크로스플랫폼을 위한 언어로서 각광받는 수준까지 활용성의 확장을 의미한다고 생각합니다.

2.3.1 Ajax

1999년 자바스크립트를 이용해 서버와 브라우저가 비동기 방식으로 데이터를 교환할 수 있는 통신 기능인 Ajax가 XMLHttpRequest라는 이름으로 등장했다.

Ajax는 그 자체로서 기능이 있는 것이 아니라, 기존에 존재하는 기술들(HTML or XHTML, CSS, JavaScript, DOM, XML, XSLT, 그리고 중요한 XMLHttpRequest 객체)을 함께 사용하는 접근방법입니다.

Ajax 등장 전 웹페이지는 HTML 전체 코드를 서버로부터 받아와 전체를 처음부터 렌더링하는 방식을 사용했습니다. 이로인해 불필요한 데이터통신 이 발생하고 서버로 코드를 받아오기에 화면 전환시 순간적으로 깜빡이는 현상 이 발생했습니다.

위 그림은 Ajax의 등장 전후 통신방식의 차이를 보여줍니다. 'Ajax engine'이 추가되었을때에는 javascript call에 따라 원하는 부분만 서버로 통신받아오기에 불필요한 데이터 통신이 줄어듭니다.

그리고 Ajax는 비동기적이라는 특징을 갖고있기에 끊김없이 소통하게 되고 이로인해 이전의 순간적으로 깜빡이는 현상도 사라지게됩니다.

이로써 웹 브라우저에서도 데스크톱 애플리케이션과 유사한 빠른 성능과 부드러운 화면 전환이 가능해졌다.

이는 2005년 Ajax를 기반으로 작동하는 구글 맵스로 입증되었습니다.

2.3.2 jQuery

2006년, jQuery의 등장으로 다소 번거롭고 논란이 있던 DOM을 더욱 쉽게 제어할 수 있게 되었고 크로스 브라우징 이슈도 어느정도 해결되었다.

jQuery의 등장으로 javascript는 웹 개발의 편의성 측면에서 성장했습니다. javascript의 표준화가 실현되지 못했던 시대에 jQuery는 많은 문제를 해결해주었기에 개발자들에게 한 줄기 빛과 같았을 것입니다.

이런 말 하는게 슬프지만 jQuery가 javascript를 대체하지는 않는다. jQuery가 성공한 것은 DOM이 문제가 많다는 증거일 뿐이다.

jQuery 창시자인 존 레식이 말한 것처럼 jQuery는 javascript의 대체품이 아닌 도구일 뿐이었습니다. 현 시대에는 jQuery가 활용될 문제들이 해결되었으며 React, View등 개발 편의성을 돕는 다른 도구들이 많기에 jQuery는 사장되어가고 있습니다.

2.3.3 V8 자바스크립트 엔진

V8 is the JavaScript engine i.e. it parses and executes JavaScript code.

From a technical standpoint, most modern JavaScript interpreters actually use a technique called just-in-time compiling to improve performance; the JavaScript source code gets compiled into a faster, binary format while the script is being used, so that it can be run as quickly as possible.

V8 자바스크립트 엔진은 자바스크립트 코드를 파싱하고 실행하는 자바스크립트 엔진 중 하나로서 JIT 컴파일 방식을 활용하여 성능을 향상시켰습니다.

JIT 컴파일 방식

JIT 컴파일(just-in-time compilation) 또는 동적 번역(dynamic translation)은 프로그램을 실제 실행하는 시점에 기계어로 번역하는 컴파일 기법이다.

실제 실행하는 시점에서 작동한다는 점에서는 인터프리터 방식을 기계어로 번역한다는 점에서는 컴파일 방식의 장점을 혼합한 방식입니다. 단순 인터프리터 방식이었던 JavaScript에 컴파일 방식을 결합하여 성능이 향상된 것입니다.

2.3.4 Node.js

2009년 라이언 달이 발표한 Node.js는 구글 V8 자바스크립트 엔진으로 빌드된 자바스크립트 런타임 환경이다. ... Node.js는 ... 서버사이드 애플리케이션 개발에 주로 사용되며, ... 프론트엔드와 백엔드 영역에서 자바스크립트를 사용할 수 있다는 동형성은 별도의 언어를 학습하기 위한 시간을 덜 수 있다는 장점이 있다.

Node.js는 비동기 I/O를 지원하며 단일 스레드 이벤트 루프기반으로 동작함으로써 요청 처리 성능에 좋다. 따라서 Node.js는 데이터를 실시간으로 처리하기 위해 I/O가 빈번하게 발생하는 SPA에 적합하다.

비동기 I/O

When Node.js performs an I/O operation, like reading from the network, accessing a database or the filesystem, instead of blocking the thread and wasting CPU cycles waiting, Node.js will resume the operations when the response comes back

I/O란 Input/Output으로 데이터가 입출력되는 것을 의미합니다. 비동기 I/O는 요청(input)한 데이터가 응답으로 도착(output)하였을 때 작동이 재개되는 방식을 의미합니다.

단일 스레드 이벤트 루프

단일 스레드

Thread in computer science is the execution of running multiple tasks or programs at the same time. Each unit capable of executing code is called thread

스레드는 코드 연산을 수행하는 각각의 유닛을 의미합니다. 단일 스레드라는 의미는 연산하는 유닛이 하나 뿐이라는 것입니다.

A Node.js app runs in a single process, without creating a new thread for every request.

Node.js는 하나의 프로세스로 운영되며 단일 스레드로 작동합니다. 연산가능한 유닛이 하나이기에 효율적인 작업을 위해서 이벤트루프를 이용하여 비동기 I/O를 지원하는 것입니다.

This allows Node.js to handle thousands of concurrent connections with a single server without introducing the burden of managing thread concurrency, which could be a significant source of bugs.

2.3.5 SPA 프레임워크

모던 웹 애플리케이션은 ... 개발 규모와 복잡도도 상승했다. ... CBD(Component Based Development) 방법론을 기반으로 하는 SPA(Single-Page Application)가 대중화되면서 Angular, React, Vue.js, Svelte 등 다양한 SPA 프레임워크/라이브러리 또한 많은 사용층을 확보하고 있다.

SPA 프레임워크는 개발편의성 측면에서 JavaScript 성장에 기여하고 있습니다.

다만 SPA 프레임워크라 JavaScript의 정답이 아니기에 상황에 맞는 사용이 필요합니다. 모든 정적 리소스를 최초 접근 시 단 한번 다운로드하기에 규모가 큰 웹페이지는 적합하지 않습니다. 그리고 SEO(검색엔진 최적화)측면에서 하나의 페이지 URL로만 작동하기에 불리합니다.

2.4 자바스크립트와 ECMAScript

ECMAScript는 자바스크립트의 표준사양인 ECMA-262를 말하며, ... 핵심 문법을 규정한다.

JavaScript는 ... 프로그래밍 언어로서 기본 뼈대를 이루는 ECMAScript와 브라우저가 별도 지원하는 클라이언트 사이드 Web API ... 등을 아우르는 개념이다.

시작은 JavaScript입니다. 마이크로소프트의 JScript로 인해 크로스브라우징 문제가 발생했고 웹 개발언어의 표준화가 필요해서 만들어진 것이 ECMAScript입니다. JavaScript는 브라우저에서 제공하는 Web API까지 포함하는 개념입니다.

2.5 자바스크립트의 특징

자바스크립트는 명령형(imperative), 함수형(functional), 프로토타입 기반(prototype-based) 객체지향 프로그래밍을 지원하는 멀티 패러다임 프로그래밍 언어이다.

자바스크립트는 욕심쟁이입니다. 하나의 패러다임에 갇혀있지않고 다양한 패러다임의 특징을 결합하여 ECMAScript로 표준화하고 있습니다. 그래서 JavaScript는 평생 공부해야하나봅니다.

다양한 패러다임은 따로 공부하고 블로그를 작성하겠습니다.

2.6 ES6 브라우저 지원 현황

브라우저에서 아직 지원하지 않는 최신 기능을 사용하거나 인터넷 익스플로러나 구형 브라우저를 고려해야 하는 상황이라면 바벨(Babel)과 같은 트랜스파일러를 사용해 ES6 이상의 사양으로 구현한 소스코드를 ES5 이하의 사양으로 다운그레이드할 필요가 있다.

JavaScript의 기술이 발달하더라도 그 환경인 브라우저가 지원하지 않는다면 의미가 없습니다. 그러므로 최신기술을 사용할 때에는 지원현황을 살펴보고 다운그레이드가 필요하다면 트랜스파일러를 사용해야 할 것입니다.

느낀점

스터디원들과 책의 내용을 깊게 파보자면서 시작한 북스터디... 수동적인 정보수용에서 능동적인 정보수집을 거치니 머리에 남는 것이 많았습니다. 현재 자바스크립트의 모습이 어떻게 형성되어왔는지를 공부할 수 있어서 좋았으며 앞으로 변화하는 모습에 유의하고 공부해야겠습니다.

참고자료

• 모던 자바스크립트 Deep Dive 2장(https://poiemaweb.com/js-introduction)
• https://ko.wikipedia.org/wiki/%EC%9E%90%EB%B0%94%EC%8A%A4%ED%81%AC%EB%A6%BD%ED%8A%B8
• https://courses.cs.washington.edu/courses/cse490h/07sp/readings/ajax_adaptive_path.pdf
• https://developer.mozilla.org/en-US/docs/Web/Guide/AJAX
• https://www.tokyobranch.net/archives/6598
• https://medium.com/javascript-in-plain-english/why-i-decided-to-break-up-with-jquery-d597d4b8c84f
• https://twitter.com/jeresig/status/590206003309891584
• https://nodejs.dev/en/learn/the-v8-javascript-engine/
• https://developer.mozilla.org/ko/docs/Learn/JavaScript/First_steps/What_is_JavaScript
• https://ko.wikipedia.org/wiki/JIT_%EC%BB%B4%ED%8C%8C%EC%9D%BC
• https://nodejs.dev/en/learn/introduction-to-nodejs/
• 널널한개발자TV_프로세스와 스레드의 차이(https://youtu.be/x-Lp-h_pf9Q)
• JSConf_어쨌든 이벤트 루프는 무엇입니까?(https://youtu.be/8aGhZQkoFbQ)
• https://developer.mozilla.org/en-US/docs/Glossary/SPA
• https://poiemaweb.com/js-spa
• https://en.wikipedia.org/wiki/Imperative_programming
• 드림코딩_함수형프로그래밍이 대세다?!(https://youtu.be/4ezXhCuT2mw)
• 얄팍한 코딩사전_함수형 프로그래밍이 뭔가요?(https://youtu.be/jVG5jvOzu9Y)

사용자와 소통하는 에러 메시지 쓰기

[Q1] 에러메시지란 무엇인가? = 사용자가 컴퓨터에 요청한 작업을 컴퓨터가 수행하지 못하였을 때 보내는 대답이라고 생각합니다.

그러므로 요청을 수행하지 못한 대답을 고민하기 이전에 요청을 어떻게 수행할 지를 고민하고 해결해야합니다.

01 에러 메시지를 쓰기 전에 에러부터 없애자

친절한 404, 불친절한 404

[Q2] 404란 무엇인가? = 404는 HTTP 응답코드 중 하나로 서버(컴퓨터)가 사용자의 요청을 찾기 못하였을 때 사용됩니다.

저자가 정의한 '친절한 404, 불친절한 404'의 차이는 사용자의 요청을 수행하지 못했음을 알림에 그치느냐, 후속조치를 안내하고 사과까지 하느냐의 차이입니다. 사용자의 요청을 수행하지 못했으면 사과해야하지 않을까요?

404 에러가 죄송할 일인가?

사용자가 404 에러 페이지를 만나는 경우는 다음과 같이 두 가지밖에 없다.

• 사용자가 URL을 잘못 입력한 경우
• 사용자가 링크를 클릭했으나 해당 페이지가 없는 경우

사용자가 URL을 잘못 입력한 경우는 개발자의 책임이 없기에 사과할 이유가 없습니다. 그러나 2 번째 경우는 개발자의 문제입니다.

링크가 있어서 클릭했는데 해당 페이지가 없는 경우, 이것을 깨진 링크, 죽은 링크, 나쁜 링크라고 한다.

깨진 링크는 개발자 책임이다

사용자가 깨진 링크를 접했다는 것은 개발자가 미리 깨진 링크를 수정하지 못했다는 의미입니다. 물론 문제가 발생하였다면 사과해야하지만, 문제를 사전에 방지해야 합니다. 저자는 깨진 링크를 확인하는 2가지 방법을 제시하고 있으니 읽어보시고 활용해보시길 바랍니다.

개발자용 에러 메시지와 사용자용 에러 메시지를 분리하자

저자는 개발자용 메시지가 사용자에게 노출되는 것을 방지하기 위해 개발자용 에러 메시지와 사용자용 에러 메시지를 분리해 작성하는 것을 추천합니다. 개발자용 에러 메시지에 [개발자]와 같은 prefix를 작성하고 컴파일 전에 검색 후 삭제하는 식으로 진행하면 어떨까 합니다.

02 사용자가 에러 메시지를 제대로 쓰는 법

에러 메시지를 제대로 쓴다는 의미는 에러 메시지의 목적에 부합하게 작성한다는 것입니다. 그렇다면 에러메시지의 목적은 무엇일까요?

에러 메시지의 목적은 사용자에게 에러가 났음을 알려주는 것이 아니라 사용자 스스로 에러를 해결하게 하는 것이다.

사용자 에러에 대처하는 메시지

사용자 스스로 에러를 해결하게 하기위한 에러 메시지에는 에러의 내용, 에러의 원인, 에러의 해결 방법이 포함돼야 합니다.

• 에러 내용: 오류로 인한 문제와 종류

• 에러의 원인: 오류를 발생시킨 직접적이고 근본적인 원인
• 에러 해결 방법: 사용자가 오류를 해결할 가장 쉽고 빠른 방법

에러 메시지를 보여주는 순서

에러 메시지에는 에러의 내용, 에러의 원인, 에러의 해결 방법이 포함돼야 한다고 했습니다. 여기서 우리는 에러 메시지의 목적에 대해 다시 생각해봐야 합니다. 사용자가 에러를 스스로 해결하기에 충분하다면, 모든 내용을 작성할 이유는 없습니다.

오락가락 메시지와 버튼 메시지

에러 메시지 알림창에는 버튼이 함께 제시됩니다. 이 버튼은 주로 true, false의 의미로 제시되는데 이는 버튼의 본래 역할에 부합되지 않기에 사용자가 헷갈릴 수 있습니다. 그렇다면 버튼의 본래 역할은 무엇일까요?

버튼의 역할은 단순히 옳고 그름의 의견을 제시하거나 '예, 아니오'로 대답하는 것이 아니다. 버튼의 본래 역할은 특정한 행동을 유도하는 것이다.

예를 들어 페이지에서 나가는 것을 묻는 알림창이라면 페이지에서 나가는 것을 예, 아니오로 답하게 하는 것이 아니라 페이지에서 머물기, 페이지에서 나가기로 답하게 하는 것입니다.

가능하다면 '취소'라는 말보다 더 구체적인 행동을 말로 전하는 것이 좋다. 짧고 애매한 것보다는 길더라도 부명한 것이 더 낫다.

03 사용자의 에러를 줄이는 메시지 구조화

버튼의 순서

윈도우에서 '확인-취소'로 나오는 반면, 맥 OS에서는 '취소-확인' 순으로 제시됩니다. 현재 표준으로 정해진 바가 없기에, 서비스 내에서 일관성을 가지는 것이 중요합니다. 그리고 OS에 종속되지 않게끔 '확인-취소'가 아닌 행동을 유도하는 유니크한 버튼을 만드는 것도 좋은 방법일 것입니다. 물론 이 방법은 협업하는 개발자, UI/UX 담장자와 논의해 결정해야 합니다.

사용자의 반복 에러를 막는 법

반복되는 에러에 같은 에러 메시지를 노출하면 사용자는 주의하지 않습니다. 그리고 갑자기 자동입력 방지 문자같은 상황을 제시하면 사용자는 당황하게 됩니다. 이를 방지하기 위해 제한횟수를 갱신하면서 보여주게되면 사용자는 자기 행동에 주의하게 될 것입니다.

04 에러 메시지 대신 예방 메시지를 쓰자

에러를 줄이려면 개발자도 사용자의 사용 방식을 이해해야 한다. 사용자가 어떻게 사용할 지를 충분히 이해하고 조사하고 분석해야 에러를 줄일 방법을 찾을 수 있다.

서비스를 이해하면 에러를 예방할 수 있다

서비스를 개발한 이후에 사용자가 서비스를 이용하는 방식을 테스트해봐야 합니다. 그리고 개발자가 원하지 않는 방식으로 사용자가 이용하지 않도록 방지해야 합니다.

사용자를 이해하면 에러를 예방할 수 있다

사용자의 실수가 나오는 상황을 개발자가 예방 메시지를 띄움으로써 사용자가 스스로 결정하게 만들어줘야 합니다.

처음부터 에러 메시지를 예방 메시지라고 생각하면 에러를 없애는 단순 개발자가 아니라 사용성을 높이고 서비스를 활성화하는 비즈니스 감각이 있는 개발자가 될 것이다.

닭이 먼저? 알이 먼저?

저자는 에러 메시지에 대한 관점의 차이에 대해 이야기합니다. 사용자의 실수가 있고 이를 고치기 위한 에러메시지를 보여줄 것인가? 아니면 사용자의 실수를 예방하기 위한 메시지를 고안할 것인가? 이는 개발자의 철학의 문제라고 저자는 말합니다.

에러 메시지에 대한 김민성의 철학

이용에 멈춤이 없게 돕는 윤활유

에러 메시지는 사용자가 서비스를 원활하게 이용할 수 있도록 돕는 또 하나의 서비스라고 생각합니다. 사용자가 불편함을 느끼지 않게끔 최대한의 경우를 방지 하고 예방 메시지 를 제안하여 이용에 멈춤이 없게끔 도와야한다고 생각합니다.

느낀점

개발의 모든 경우에서 사용자의 경험을 중시해야 한다는 것을 느꼈습니다. 에러란 개발자가 생각하지 못한 방식으로 이용되는 경우입니다. 생각하지 못했다는 것은 개발자의 직무를 다하지 못했다는 변명이기에 계속해서 사용자의 사용방식을 고민하고 개선해나가야 합니다. 물론 생각치못한 부분에 대해서는 솔직하게 말하고, 알려주신다면 개선하겠다는 식의 에러메시지를 표현하는 게 좋지 않을까 생각합니다.

참고자료

• 개발자의 글쓰기 3장
• HTTP 상태 코드_MDN(https://developer.mozilla.org/ko/docs/Web/HTTP/Status)

이 글은 김철수님이 작성하신 "개발자의 글쓰기"의 2장, '개발 시간을 줄여주는 이름 짓기와 주석 쓰기'을 읽고 정리한 글입니다. 저자님께서 정리해주신 목차대로 저 나름의 정리를 해보겠습니다.

01 네이밍 컨벤션, 이유를 알고 쓰자

네이밍 컨벤션을 직역하면 '이름 짓는 관습'입니다.

[1 Q] 무엇의 이름을 짓는 것일까요? = 개인적으로 코딩이란 개발자가 컴퓨터에게 전달하는 작업 메뉴얼이라고 생각합니다. 그 메뉴얼은 여러 단어로 이루어져 있을 것이기에 그런 '단어'의 이름을 지어주어야 하는 것입니다.

[2 Q] 그럼 이름 짓는 관습은 왜 필요한 것일까요? = 코딩은 컴퓨터 뿐만 아니라 다른 개발자들과도 소통해야합니다. 이런 소통방식들이 모여서 관습이 형성된 것이고, 개발 사회에 합류하기 위해서 이름 짓는 관습을 지켜야하는 것이라 생각합니다.

개발자의 가장 큰 고민은 이름 짓기

글을 쓰면서 이름을 짓는 것을 고민하지 않는 이유는 한글에는 정해진 단어들이 있고 그 단어를 사용하면 되기 때문입니다. 그러나 개발어 사전은 따로 없기에 개발하면서 이름을 지어야하는 게 고민인 것입니다. 고민하여서 이름을 짓더라도 다른 개발자가 그 이름을 이해하지 못하면 말짱꽝 이기에 더더욱 고민하게 되는 것입니다.

이름 짓기는 창조가 아니라 조합

개발어 사전이 없다면 존재하는 '영어 사전'을 활용하면 됩니다.

말하자면 이름 짓기는 창조 과정이 아니라 정해진 원칙으로 적절한 단어를 선택해 조합하는 과정일 뿐이다.

조합으로는 주로 명사, 형용사, 동사가 사용됩니다.

• 명사 + 명사 + 명사
• 동사 + 명사 + 명사
• 형용사 + 명사 + 명사

이 조합으로 이름을 구성하여 무슨 기능인지 간결하게 알리면 됩니다.

코드의 네이밍 컨벤션은 영어 표기법을 상속받았다

위에 언급하였듯이 코드 네이밍은 영어를 조합하여 만들어지기에 영어 표기법을 준수합니다.

예를 들어 파스칼 표기법과 카멜 표기법은 영어의 대문자 표기 원칙의 특성을 따릅니다.

1. 중요하거나 크거나 특정한 것을 가리키거나 제목에 해당하는 명사는 모두 첫 글자를 대문자로 쓴다.
2. 그런 명사들이 이어질 때는 첫 글자를 모두 대문자로 쓴다.
3. 명사나 관사가 아닌 동사, 형용사 등은 소문자를 쓴다.

파스칼 표기법으로 클래스 이름 짓기

파스칼 표기법은 단어의 첫 글자를 대문자로 쓰는 방식으로 주로 클래스, 인터페이스 등에 사용됩니다. 클래스와 인터페이스는 프로그래밍에 있어 고유명사처럼 사용되기에 영어에서 명사 표기법과 동일한 것입니다.

카멜 표기법으로 함수, 변수의 이름 짓기

카멜 표기법은 첫 단어를 빼고 나머지 단어의 첫 번째 글자만 대문자로 쓰는 방식으로 주로 함수나 변수에 사용합니다. 함수는 동작을 시키는 명령어 개념으로 동사가 먼저 사용되고, 변수는 동사나 형용사로 시작하기에 첫 글자를 소문자로 시작하는 것입니다.

위에 언급했던 영어 표기 조합을 파스칼, 카멜 표기법에 대입하면 아래와 같습니다.

• 클래스, 인터페이스 = 명사+명사+명사 = 파스칼 케이스
• 변수, 함수 = 동사/형용사+명사+명사 = 카멜 케이스

상수는 모두 대문자로 쓴다

상수를 모두 대문자로 쓰고 언더스코어(_)로 단어를 연결하는 방식은 상수라는 것을 주의시키기 위한 방법이었습니다. 그러나 현재는 사라지고 있는 관습으로 사용여부는 협업하는 개발자끼리 정하면 됩니다.

패키지와 모듈은 모두 소문자로 쓴다

패키지와 모듈은 클래스나 함수 등을 모은 보관함이라고 보면 됩니다. 이 역시 명사이므로 대문자를 사용해야할 것이지만 컨벤션으로 소문자로 사용되어오기에, 이해가 되지 않더라고 관습을 따라야 합니다.

[3 Q] 관습이 영어표기법 근거에 맞지 않다면 바꿔야하지 않나요? = 중요한 것은 개발자들간의 소통입니다. 원리원칙을 중시하여 '대문자로 쓰는 게 맞으니까 대문자로 쓸래'라고 해봤자 패키지는 사용되지 않습니다. 로마에서는 로마의 법을 따라야 하듯, 개발 사회에서 정해진 관습은 따릅시다.

BEM 표기법

CSS에서 사용되는 BEM 표기법은 대상__요소--상태를 의미한다.

이는 블로그에서 이미 정리한 바가 있으니 그 글의 링크만 남기고 넘어가겠습니다.

https://velog.io/@msg_0217/CSS-%EB%B0%A9%EB%B2%95%EB%A1%A0OOCSS-BEM-SMACSS

가독성과 소통이 먼저다

네이밍 컨벤션이 존재하는 이유가 가장 중요합니다!

그동안 수많은 개발자가 이렇게 컨벤션을 만든 이유는 가독성과 소통때문이다.

가독성을 위해서는 다양한 방법이 있겠지만 소통이 잘되려면 서로가 같은 컨벤션을 지켜야합니다. 그러므로 협업을 할 개발자끼리는 코딩하기 전에 기본적인 컨벤션 규칙을 정하는 것이 우선입니다.

02 변수 이름을 잘 짓는 법

표기하는 방법은 위에서 배웠습니다. 그럼 이제 어떤 식으로 구성해야하는 지를 알아봅시다.

i는 변수 이름이지만 d는 아니다

i와 d, 같은 소문자 하나인데 무엇이 다를까요? i는 integer와 index의 첫글자로 개발 사회에서 관습으로 정해져 있습니다. 즉, 관습으로 개발 사회에서 합의가 되어있다면 사용하면 됩니다. 다른 개발자들이 이해할 수 있기 때문입니다.

긴 이름? 짧은 이름? 검색 잘 되는 이름!

이름이 왜 검색이 잘 되어야 할까요? 여기서 검색은 개발자들이 작업할 때 ctrl + F로 찾는 것을 의미한다고 생각합니다. 관습적으로 많이 사용되는 단어여야 개발자들이 검색할 때 바로 떠올릴 수 있을 것이고 이는 길이와는 상관이 없는 것입니다. 물론 간결성을 더할 수 있다면 좋겠지요.

복수형을 나타내는 s를 붙일까 말까?

영어에서 복수형을 나타낼 때 -s나 -es를 사용하기에 당연히 붙여야 영어 표기법을 준수하는 것이 아닐까요? 다시 한번 말하지만 네이밍 컨벤션에서 중요한 것은 개발자간의 소통입니다.

checkUserNamesUnder2Characters()
checkUserNamesExistsInDB()

복수형을 나타내는 -s가 잘 보이시나요? 가독성을 위해서 저자는 변수명은 그대로 두더라도 함수명에서는 -s대신 array나 list of를 사용하는 것을 추천합니다.

checkUserNameArrayUnder2Characters()
checkListOfUserNameExistsInDB()

여기서 역시 중요한 것은 협업하는 개발자들간 정한 규칙이 통일되어야한다는 점입니다.

약어를 쓰는 것이 좋을까? 안 쓰는 것이 좋을까?

약어 사용에 대한 찬반이 갈리지만, 역시 중요한 것은 개발자끼리 소통이 가능하냐는 것입니다. 관습적으로 사용되는 약어라면 사용하여도 무방할 듯 하지만, 서로 정하는 것이 가장 좋겠습니다.

중요한 단어를 앞에 쓴다

이름이란 무엇일까요?

다른 것과 구별하기 위하여 사물, 단체, 현상 따위에 붙여서 부르는 말

이름의 정의에서 알 수 있듯이 이름에서 핵심은 다른 것과 구별되는 것입니다. 그러므로 여러 단어를 조합해서 만드는 변수 이름에 첫 단어는 수식어보다는 핵심 명사가 되어야 합니다.

함수 이름 짓는 순서

제가 이 책을 읽은 이유입니다. 어떤 식으로 이름을 작성하는 지에 대해 책의 저자가 친절히 소개해주기에 그 과정을 그대로 보여드리겠습니다.

1. 기능을 한글문장으로 표현한다.

처음에는 한글 문장에서 시작해서 몇 개의 영어 단어 조합으로 끝내는 경우가 많다.

사용자가 이름을 입력하고 등록 버튼을 클릭하면, 시스템이 사용자 이름을 input 태그에서 가져와 이름 입력 여부와 글자 수를 확인 한 후 입력이 안 되었으면 스크립트를 중단하고 input 태그를 활성화해 사용자가 쓸 수 있게 하고, 글자 수가 한글 두 글자 이하면 확인을 요청해 사용자가 확인할 수 있게 한다.

한글로 기이이이이일게 소개한 글에서 이름으로 불필요한 부분을 제거해보겠습니다.

2. 사용자가 하는 일은 삭제한다.

함수는 시스템이 할 일을 나타내는 것이지 사용자가 할 일을 나타내는 것이 아니다. ... 논리적으로 합쳐야 하거나 떼야 할 것을 확인해서 다시 정리한다.

사용자가 이름을 입력하고 등록 버튼을 클릭하면 시스템이 사용자 이름을 input 태그에서 가져와 입력 여부와 글자수를 확인한 뒤 입력이 안 되었으면 스크립트를 중단하고 input 태그를 활성화해 사용자가 쓸 수 있게 하고, 글자 수가 한글 두 글자 이하면 확인을 요청해 사용자가 확인할 수 있게 한다. ~

3. 남은 문장을 조각낸다.

1. 사용자 이름을 input 태그에서 가져온다.
2. 사용자 이름의 글자 수를 확인한다.
3. 입력이 안되었으면 input 태그를 활성화한다.
4. 글자 수가 한글 두 글자 이하면 확인을 요청한다.

4. 함수 갯수를 결정한다.(1함수 1업무)

1. (함수1) 사용자 이름을 input 태그에서 가져온다.
2. (함수2) 사용자 이름의 글자 수가 2글자 이하면 다음과 같이 처리한다.
   • 만약 글자 수가 0(=null)이면 input 태그를 활성화한다.
   • 만약 글자 수가 1 또는 2이면 사용자에게 확인을 요청한다.

5. 함수 문장을 영어로 바꾸자

1. get user's name from the text input field
2. do something if user's name contains under 2 characters

6. 불필요한 단어를 없애자(정관사, 소유격 등)

1. get user name from input field
2. check if user name contains under 2 characters

7. 띄어쓰기를 없애고 함수이기에 카멜케이스를 사용하자

1. getUserNameFromInputField()
2. checkIfUserNameContainsUnder2Characters()

8. 함수를 사용할 때 의미상 없어도 되는 단어는 없애자

1. getUserNameFromField() <- input에 사용되기에
2. checkUserNameUnder2Characters() <- 조건문으로 확인할 것이기에

기능을 보고 한번에 함수명이 나오면 가장 좋겠지만, 익숙해질때까지는 1~8 과정을 천천히 밟으면서 네이밍해보자!

03 좋은 이름의 기준, SMART

한 번에 좋은 이름을 지을 수는 없다

위에서 언급했듯이 한번에 좋은 이름을 짓기는 어렵습니다. 그렇기에 좋은 이름의 기준을 갖고 그 기준에 맞추려는 노력이 필요합니다.

좋은 이름이 가진 5가지 특징

그렇다면 좋은 이름이란 무엇일까요? 이는 이름을 짓는 이유와 직결됩니다. 개발에서 이름은 개발자간의 소통을 위해 필수적입니다. 그러므로 개발자들이 많이 사용하는 이름이 좋은 이름일 것입니다.

누구나 이름을 지을 수 있다. 하지만 그 이름이 널리 퍼져 많은 사람이 사용하게 하려면 좋은 이름이어야 한다.

이에 저자는 좋은 이름인지 확인하는 5가지 기준으로 SMART를 제시하였습니다.

easy to Search: 검색하기 쉽게 이름 짓는 법

작업의 크기가 커지게되면 이름을 일일이 기억하지 못할 것이고 필요할때마다 이름을 검색해 사용할 것입니다. 그러므로 검색하기 쉽게 이름을 지어야 합니다. 어떻게 검색하기 쉽게 이름을 지을 수 있을까요? 저자는 고전적 범주화를 이용해 한 단계 상위 범주의 이름을 태그처럼 덧 붙이는 것을 추천했습니다.

예를 들어 에러 메시지와 관련된 이름들 앞에 접두어로 ERROR_를 붙이거나 사용자와 관련된 이름에는 user를 붙이는 것입니다.

같은 접두어를 사용하는 이름이 많아지게 되면 그 접두어 속에서 체계를 형성하여 나누어야합니다. 예를 들면 SERVER_ERROR, INTERFACE_ERROR처럼요.

이 역시 하나의 방법이기에 협업하는 개발자들끼리의 합의가 우선되어야 합니다.

easy to Mix: 조합하기 쉽게 이름 짓는 법

저자가 말하는 조합은 개발 언어의 문법과의 조합입니다. 예를들어 html 태그인 경우 title이라는 이름을 활용한다면 h1, h2, p 등 다양한 태그와 함께 조합하여 각각을 구별하기 쉽습니다.

easy to Agree: 수긍하기 쉽게 이름 짓는 법

이름은 결국 개발자간의 소통 수단입니다. 배(=소통)보다 배꼽(=이름 짓기)이 커지면 안 되듯, 효율적인 이름 짓기가 필요합니다. 여기서 효율이란, 대상을 구별한다는 이름의 목적에 맞는 상황에서만 이름을 지으면 된다는 의미입니다.

easy to Remember: 기억하기 쉽게 이름 짓는 법

여기서 중요한 것은 몇 개를 기억하느냐가 아니다. 어떤 이름을 기억해내느냐가 중요하다.

이를 위한 방법으로 저자는 몇가지를 소개합니다.

• 시청각적으로 완결된 단어 (TRQWRE vs. QWERTY, BIE vs. BIOE)
• 이미 널리 알려진 용어

easy to Type: 입력하기 쉽게 이름 짓는 법

자주 사용되거나 중요한 이름이라면 입력하기 쉬운지, 오타를 낼 가능성이 작은지, 다른 사람에게 말로 전달하기 쉬운지 검토해 보는 것이 좋다.

이와 반대로 다음은 입력할 때 틀리기 쉬운 단어로 사용할 때 유의해야 합니다.

• 연속된 철자 : successes, classes, committee, parallel
• 묵음 : lambda, thumbnail, debt
• ie/ei : chief, receive, retrieve, friends, achieve
• sion/tion : position, commission
• uous/ous/us : continuous, fabulous, genius

04 좋은 코드에는 주석이 없다?

코드에서 주석은 다른 개발자에게 코드 관련한 내용을 전달할 때 사용됩니다. 예를 들면 함수에 대한 설명을 주석으로 전달할 수 있을 것입니다.

이름을 잘 지으면 주석을 줄일 수 있다

만약 이름으로 함수에 대한 설명을 전달할 수 있다면 관련 주석은 불필요할 것입니다.

처음부터 주석 없이 코딩하는 연습을 하자

이 부분은 예시로 충분히 설명될 듯 합니다.

[안 좋은 예]

"success": [ // 구독자 추가 성공
],
"update": [ // 이미 있는 구독자, 나머지 필드를 업데이트해야함.
],
"failDeny": [ // 수신 거부 상태의 구독자, 추가하지 않음.
],
"failWrongEmail": [ // 잘못된 이메일 주소 형식, 추가하지 않음.
],
"failUnknown": [ // 알 수 없는 오류로 추가하지 않음.
]

[좋은 예]

"created": [
],
"updatedInformationExceptEmail": [
],
"noCreatedBecauseUnsubscriber": [
],
"noCreatedBecauseWrongEmail": [
],
"noCreatedBecauseUnknownError": [
],

이름의 존재이유에 대해 계속 생각해야합니다. 이름은 개발자와의 소통을 위해 존재합니다. 간결하기만 할 뿐 소통을 위해 주석이 필요하다면 잘못된 이름짓기입니다. 이름만으로 소통이 가능한 선에서 간결성을 더해야합니다.

주석이 필요한 때도 많다

개발자마다의 영어 수준은 다를 것입니다. 오역할 수 있는 이름이라면 주석을 추가하여 코드의 정확성을 높여야합니다.

주석이 제 역할에만 충실하다면 많고 적고는 상관없다.

합리적인 이유가 있다면 사용해야합니다.

05 다른 개발자를 배려하는 주석 쓰기

코드는 의미를, 주석은 의도를

글은 의미를 전달하는 수단이다. 코드도 마찬가지다.

이름에 의도까지 추가하려한다면 이름이 지저분해질 수 있습니다. 그러므로 개발자의 의도는 주석으로 표현하는 것이 좋습니다.

개발자가 어떤 의도를 전달하는 이유는 다른 개발자를 위한 것이다.

아래는 다른 개발자를 위한 주석 예시입니다. 아래 의도들은 주석으로 사용하면 소통에 도움이 될 것 입니다.

[이유를 알려주는 것]

[개발자가 새롭게 발견한 것]

[예상 질문과 답]

[할 일이나 주의, 개선 아이디어를 주는 것]

[다른 사람에게 보완을 요청하는 것]

[개발자의 속마음을 표현한 것]

주석의 반복

반복되는 것이 안 좋은 것만은 아닙니다. 가장 중요한 것은 소통하는 데 충분하느냐입니다. 그 이상으로 반복된다면 줄이는 것이 좋습니다.

주석의 발췌와 요약

발췌는 중요한 것을 뽑아내는 것이다. 중요한 것을 뽑으려면 덜 중요한 것을 빼야 한다.

소통에서 중요한 것은 가독성과 소통이라고 얘기해오고 있습니다. 소통하기에 충분하다면 가독성을 위해서 발췌, 요약하여 주석을 줄여나가야 합니다.

주석도 코드다

주석을 경시하는 개발자들이 있습니다. 그러나 주석 역시 개발자간의 소통을 위한 도구이므로 코드와 목적이 동일합니다.

불필요한 주석은 없애고, 꼭 필요한 주석은 코드처럼 뤄야 합니다.

느낀점

가장 중요한 것은 존재 이유라고 생각합니다. 존재하는 이유에 맞게 사용하고, 존재하기에 충분한 이유가 있다면 존중하며, 존재할 이유가 없다면 줄여야 할 것입니다. 코딩(개발자간 소통),이름(구별)과 주석(의도 전달)의 존재 이유를 항상 생각하며 사용하겠습니다.

참고자료

• '개발자의 글쓰기' 2장

Reponsive web design (RWD) is a web design approach to make web pages render well on all screen sizes and resolutions while ensuring good usability

반응형 디자인은 모든 스크린 사이즈와 해상도를 대비하여 UX를 향상시키기 위한 디자인 접근방식입니다.

Responsive web design is a design approach that addresses the range of devices and device sizes, enabling automatic adaption to the screen, whether the content is viewed on a tablet, phone, television or watch.

반응형 디자인은 장치별 스크린에 맞게끔 자동으로 적응시킵니다.

Responsive web design isn't a separate technology -- it is an approach. It is a term used to describe a set of best practices used to create a layout that can respond to any device being used to view the content

반응형 디자인은 특정한 기술이 아니라 접근방식입니다. 컨텐츠를 장치에 대응되게끔 layout을 만드는 최선의 방법 이라면 반응형 디자인입니다.

예전에는 CSS float가 반응형 디자인으로 소개되었지만, 지금은 best practice가 아닙니다.

Media Query

Media queries allow us to run a series of tests (e.g. whether the user's screen is greater than a certain width, or a certain resolution) and apply CSS selectively to style the page appropriately for the user's needs.

미디어 쿼리는 스크린 너비 구역을 나누는 등, 여러 테스트를 수행하며 선별적으로 적절한 스타일을 적용케합니다.

A common approach when using Media Queries is to create a simple single-column layout for narrow-screen devices (e.g. mobile phones), then check for wider screens and implement a multiple-column layout when you know that you have enough screen width to handle it. Designing for mobile first is known as mobile first design.

일반적인 접근 방식은 하나의 열을 가진 layout을 mobile과 같은 좁은 너비의 기기를 위해 맞추고, 더 넓은 너비는 다양한 열의 layout을 형성하는 mobile first design 입니다.

If using breakpoints, best practices encourage defining media query breakpoints with relative units rather than absolute sizes of an individual device.

만약 breakpoints를 사용한다면 상대적인 단위로 설정하는 것이 권장됩니다.

Media queries can help with RWD, but are not a requirement. Flexible grids, relative units, amd minimum and maximum unit values can be used without queries

미디어쿼리는 반응형 디자인의 수단일 뿐입니다. 미디어 쿼리 없이도 반응형 디자인을 구현할 수 있습니다.

Responsive layout technologies

Responsive sites are built on flexible grids, meaning you don't need to target every possible device size with pixel perfect layouts.

유연한 grid로 반응형 사이트를 만든다는 것은, 개별 장치의 완벽한 픽셀단위의 레이아웃을 만들 필요가 없다는 것입니다. 즉, 개발에 드는 비용이 감소됩니다.

By using a flexible grid, you can change a feature or add in a breakpoint and change the design at the point where the content starts to look bad.

컨텐츠가 못생겨지기 시작한 시점을 breakpoint로 추가하고 변화를 주면 됩니다.

Several layout methods, including Multiple-column layout, Flexbox, and Grid are responsive by default. They all assume that you ar trying to create a flexible grid and give you easier ways to do so.

Multiple-column layout, Flexbox, 그리고 Grid는 기본적으로 반응형이며 이들은 쉽게 유연한 grid를 만들 수 있도록 돕습니다.

What is grid?

a pattern or structure made from horizontal and vertical lines crossing each other to form squares

수평선과 수직선을 만나 형성하는 사각형 모양의 패턴이나 구조라고 생각하면 될 듯 합니다.

Multicol

With multicol, you specify a column-count to indicate the maximum number of columns you want your content to be split into. The browser then works out the size of these, a size that will change according to the screen size.

.container {
  column-count: 3;
}

If you instead specify a column-width, you are specifying a minimum width. The browser will create as many columns of that width as will comfortably fit into the container, then share out the remaining space between all the columns.

  .container {
    column-width: 10em;
  }

You can use the columns shorthand to provide a maximum number of columns and a minimum column width.

Flexbox

In Flexbox, flex items shrink or grow, distributing space between the items according to the space in their container.

.container { display: flex; }
.item { flex: 1; }

CSS grid

In CSS Grid Layout the fr unit allows the distribution of available space across grid tracks.

.container {
  display: grid;
  grid-template-colums: 1fr 1fr 1fr;
}

Responsive images

To ensure media is never larger than its reponsive container, the following approach can be used:

img,
picture,
video {
   max-width: 100%;
}

위 CSS는 image가 변화하는 container보다 커지는 상황을 방지하는 코드입니다. 이는 CSS Reset으로도 많이 설정합니다.

Why responsive images?

넓은 스크린을 가진 장치를 사용할 때는 이미지로 문제가 발생하지 않았지만, 좁은 스크린 장치를 사용하면서 문제들이 발생되기 시작했습니다. 다시 말하면, 컴퓨터만 존재하던 시대에서 이미지는 단일 이미지로 충분했지만, 스마트폰이 등장하면서 컴퓨터에 사용하던 이미지를 변형할 필요가 생긴 것입니다.

The general problem whereby you want to serve different cropped images in that way, for various layouts, is commonly known as the art direction problem

The browser could then determine the optimal resolution to load based on the screen size of the user's device. This is called the resolution switching problem

How do you create responsive images?

Resolution switching: Diffrent sizes

Resolution switching: Same size, different resolutions

Art direction

Why can't we just do this using CSS or JavsScript?

Responsive typography

Using media queries for responsive typography

html { font-size: 1em; }
h1 { font-size: 2rem; }
@media (min-width: 1200px) {
  h1 {
    font-size: 4rem;
  }
}

As this approach to typography shows, you do not need to restrict media queries to only changing the layout of the page. They can be used to tweak any element to make it more usable or attractive at alternate screen size.

이 방식은 페이지 전체 레이아웃을 변경하는 엄격한 미디어쿼리가 아니라 사용성이 높고 매력적이라면 살짝 tweak 하는 걸로 충분하다는 점입니다.

Using viewport units for responsive typography

Viewport units vw can also be used to enable responsive typography, without the need for setting breakpoints with media queries.

h1 { font-size: 6vw; }

The problem with doing the above is that the user loses the ability to zoom any text set using the vw unit.

viewport unit으로 설정하면 스크린 너비에 따라 자동으로 변환될 것입니다. 하지만 zoom을 해도 스크린 너비는 변하지 않기에 zoom에 따른 변경이 적용되지 않을 것입니다. 그러므로 viewport unit들은 혼자 사용되서는 안되고 calc()와 함께 사용되어야 합니다.

h1 {
  font-size: calc(1.5rem + 3vw);
}

이렇게 한 번 설정해두면 font-size는 viewport와 font-size에 따라 변경될 것이므로 위의 문제를 해결할 수 있을것입니다.

The viewport meta tag

you should always include the viewport meta tag in the head of your documents.

<meta name="viewport" content="width=device-width,initial-scale=1" />

This viewport meta tag tells mobile browsers that they should set the width of the viewport to the device width, and scale the document to 100% of its intended size, which shows the document at the mobile-optimized size tha you intended.

By setting width=device-width you are overriding a mobile device's default with the actual width of the device.

이 메타태그는 스마트폰이 등장할때 존재했는데, 대부분의 사이트들은 모바일 최적화되어 있지 않았습니다. 그러므로 모바일 브라우저들은 그들의 viewport width에 맞게 페이지를 렌더했고 이는 데스크탑 레이아웃을 줌 아웃한 것처럼 보였습니다. 이에 이용자들은 불편함을 느꼈고 이는 당신이 viewport meta tag를 <head>에 사용해야할 이유입니다.

느낀점

반응형 디자인을 위한 코드는 개발의 역사(history)를 공부하면 쉽게 이해되는 부분이 많았습니다. 앞으로 개발 공부함에 있어서 현 상황을 단순히 받아들이지 않고 왜 사용해야하는 지를 계속 공부하고 이해해나가겠습니다.

참고사이트

• 코딩애플 HTML/CSS 강의
• https://developer.mozilla.org/en-US/docs/Learn/CSS/CSS_layout/Responsive_Design
• https://dictionary.cambridge.org/ko/%EC%82%AC%EC%A0%84/%EC%98%81%EC%96%B4/grid
• https://developer.mozilla.org/en-US/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images

In programming, Semantics refers to the meaning of a piece of code

semantic의 의미 그대로 프로그래밍에서도 code 조각의 의미를 뜻합니다. 코드 조각의 의미는 태그가 지니고 있는 컨텐츠의 의미라고 생각하시면 됩니다. semantic tag가 있다면 의미없는 태그가 있다는 소리일까요?

non-semantic tags

div 와 span이 대표적인 예로서 이 태그들은 컨텐츠에 대해서 아무것도 말해주지 않습니다. html4 이전에는 위 태그들에 id 나 class 속성을 부여하여 의미를 부여하였으나 HTML5부터 시멘틱 태그가 등장하였습니다.

Semantics in HTML

HTML should be coded to represent the data that will be populated and not based on its default presentation styling.

When approaching which markup to use, ask yourself, "What element(s) best describe/ represent the data that I'm going to populate?"

Benefits from writing semantic markup

Search engines will consider its contents as important keywords to influence the page's search rankings

검색엔진에 상위 노출되기 위해 중요한 요소입니다. (검색하는 사용자들과 소통에 도움이 됩니다.)

Screen readers can use it as a signpost to help visually impaired users nevigate a page

스크린 리더의 이정표로 사용되기에 중요합니다. (읽기 어려운 분들과 소통에 도움이 됩니다.)

Finding blocks of meaningful code is significantly easier than searching through endless divs with or without semantic or namespaced classes

div로만 이루어져있는 것보다 의미있는 코드를 찾기 쉽습니다. (개발자간의 소통에 도움이 됩니다)

Suggests to the developer the type of data that will be populated

개발자에게 어떤 데이터가 입력되어야 할 지 제안합니다. (컴퓨터와 소통하는 데 도움이 됩니다.)

Semantic naming mirrors proper custom element/component naming

Semantic elements

100여개가 넘는 semantic elements 중 몇개만 소개해보겠습니다.

<article>

The <article> HTML element represents a self-contained composition in a document, page, application, or site, which is intended to be independently distributable or reusable

<article> 태그는 독자적으로 정보를 구성할 수 있는 글에 사용됩니다.

사용예시

• a forum post
• a magazine or newspaper article
• a blog entry
• a product card
• a user-submitted comment
• an interactive widget or gadget
• any other independent item of content

참고사항

• 개별 <article>은 식별되어야하므로 heading(h1~h6)를 자식으로 가져야합니다.
• <article>이 중첩된다면, 내부 요소는 외부 요소와 관련있어야 합니다.

<aside>

The <aside> HTML element represents a portion of a document whose content is only indirectly related to the document's main content. Asides are frequently presented as sidebars or call-out boxes

<aside> 태그는 메인 콘텐츠와 간접적으로 연관된 정보를 나타낼때 사용됩니다. 고로 사이드바처럼 옆으로 빠져있는 경우가 대다수입니다.

참고사항

<aside> 태그를 글을 강조하는 목적으로 사용하지 마십시오. <aside>는 비간접적으로 연관된 요소에 사용되기에 강조될 이유가 없습니다.

<details>

The <details> HTML element creates a disclosure widget in which information is visible only when the widget is toggled into an "open" state. A summary or label must be provided usting the <summary> element.

The contents of the <summary> element are used as the label for the disclosure widget.

<summary>

The <summary> HTML element specifies a summary, caption, or legend for a <details> element's disclosure box.

A <summary> element may only be used as the first child of a <details> element.

If a <details> element's first child is not a <summary> element, the user agent will use a default string (typically "Details") as the label for the disclosure box.

<figcaption>

The <figcaption> HTML element represents a caption or legend describing the rest of the contents of its parent <figure> element.

부모 요소인 <figure>를 설명하는 목적으로 사용됩니다.

<figure>

The <figure> HTML element represents self-contained content, potentially with an optional caption, which is specified using the <figcaption> element. The figure, its caption, and its contents are referenced as a single unit.

<figure> 요소는 독립적인 컨텐츠를 나타낼 때 사용됩니다. 부모요소인 <figure>과 자식요소인 contents, <figcaption>은 단일 유닛으로 참조됩니다.(어디에 참조되는 걸까?)

참고사항

Usually a <figure> is an image, illustration, diagram, code snippet, etc.

<figcaption>이 여러 개라면 첫 번째 <figcaption> 이 figure의 caption으로 표시됩니다.

<form>

The <form> HTML element represents a document section containing interactive controls for submitting information.

<form> 요소는 정보 제출과 관련된 상호작용이 포함된 문서 섹션을 표현합니다.

<footer>

The <footer> HTML element represents a footer for its nearest ancestor secioning content or sectioning root element. A <footer> typically contains information about the author of the section, copyright data or links to related documents.

사용예시

• section의 저자
• 저작권관련 자료 in an <address> element.
• 연관된 document로의 링크

참고사항

• 가장 가까운 섹션 컨텐츠나 섹션의 루트 요소가 <body>라면 <footer>는 전체 페이지에 적용됩니다.
• <footer> 요소는 섹션 컨텐츠가 아니므로 새로운 섹션이 포함되지 않습니다.

<header>

The <header> HTML element represents introductory content, typically a group of introductory or navigational aids. It may contain some heading elements but also a logo, a search form, an author name, and other elements.

사용예시

<header>가 사용되는 예시는 2가지 경우가 있습니다.

1. Page Header

   The <header> element defines a banner landmark when its context is the <body> element.

2. Article Header

   The HTML header element is not considered a banner landmark when it is descendant of an <article>, <aside>, <main>, <nav>, or <section> element.

<main>

The <main> HTML element represents the dominant content of the <body> of a document. The main content area consists of content that is directly related to or expands upon the central topic of a document, or the central functionality of an application.

<main> HTML 요소는 <body> 의 주요한 컨텐츠를 표현합니다. 이에 대비되는 semantic element는 <aside>로 보면 될 듯합니다.

A document mustn't have more than one <main> element that doesn't have the hidden attribute specified.

페이지에 보여지는 <main> 요소는 단 하나만 존재해야 합니다. (숨겨져 있는 것은 가능한 듯 합니다)

<main> doesn't contribute to the document's outline; ... <main> doesn't affect the DOM's concept of the structure of the page. It's strictly informative.

<main> HTML element가 DOM's concept에 영향을 끼치지 않는 것에 대해서는 DOM을 공부하면서 다시 알아봐야겠습니다. 지금은 정보전달 목적이라는 것 외에는 잘 모르겠습니다.

<mark>

The <mark> HTML element represents text which is marked or highlighted for reference or notation purposes due to the marked passage's relevance in the enclosing context.

참고사항

1. Marking text of interest 인용문을 작성할 때 original source에서는 알 수 없지만 본인이 생각하기에 관련되어 있다고 생각되는 부분에 사용합니다.
2. Identifying context=sensitive passage 사용자의 현재 행동과 연관된 컨텐츠의 부분에 표기합니다. 예를 들면 검색한 단어를 mark하는 것입니다.
3. <mark>를 강조하는 문법으로 사용하지 마십시오.

<mark> vs. <strong>

<mark> is used to denote content which has a degree of relevance, while <strong> indicates spans of text of importance

<mark>는 컨텐츠의 관련성을 나타내는 반면에 <strong>은 텍스트의 중요성을 나타냅니다.

Accessibility

<mark> 요소는 대부분의 스크린 리더 기술에 의해 읽혀지지 않습니다. CSS content property를 pseudo-elements(::before, ::after)와 함께 사용하면 읽히지만, 글을 이해하는 데 오히려 악영향을 끼칠수 있어서 남용하지 않는 것을 추천합니다.

<nav>

The <nav> HTML element represents a section of a page whose purpose is to provide navigation links, either within the current document or to other documents.

사용예시

• menus
• tables of contents
• indexs

참고사항

1. 모든 링크들이 <nav> element에 포함되는 것은 아닙니다 (반례: <footer>)
2. 페이지 내에 여러개의 <nav>가 존재할 수 있습니다. 접근성 향상을 위해 aria-labelledby 속성이 사용되며 이를 스크린 리더가 참고합니다.

   A document may have several <nav> elements, for example, one for site navigation and one for intra-page navigation. aria-labelledby can be used in such case to promote accessibility.

3. User agent는 <nav>를 참고하여 navigation-only content의 초기 렌더링을 생략할 지 결정할 수 있습니다.

<section>

The <section> HTML element represents a generic standalone section of a document, which doesn't have a more specific semantic element to represent it. Sections should always have a heading, with very few exceptions

<section> HTML 요소는 더 구체적인 semantic 요소로 표현할 수 없는 독립적인 섹션을 나타내는데 사용됩니다. <section>은 반드시 heading을 자식요소로 갖습니다. heading을 갖지 않는 <section>은 스크린 리더에 읽힐 필요가 없다고 판단되는 부분 뿐입니다.

more specific semantic element?

If the contents of the element represent a standalone, atomic unit of content that makes sense syndicated as standalone piece (e.g. a blog post or blog comment, or a newspaper article), the <article> element would be a better choice

If the contents represent useful tangential information that works alongside the main content, but is not directly part of it (like related links, or an author bio), use an <aside>

If the contents represent the main content area of a document, use <main>.

If you are only using the element as a styling wrapper, use a <div> instead.

<time>

The <time> HTML element represents a specific period in time.

사용예시

1. A time on a 24-hour clock.
2. A precise date in the Gregorian calendar (with optional time and timezone information)
3. A valid time duration

참고사항

This element is for presenting dates and times in a machine-readable format.

This element should not be used for dates prior to the introduction of the Gregorian calendar (due to complications in calculating those dates)

The datetime value (the machine-readable value of the datetime) is the value of the element's datetime attribute, which must be in the proper format. If the element doen not have a datetime attribute, it must not have any element descendants, and the datetime value is the element's child text content.

기계가 읽을 수 있는 형식을 지켜야 합니다. 기계가 인식하지 못하는 gregorian calendar 이전의 dates는 사용되지 못합니다. datetime 속성을 사용하는 것이 best이며, 만약 사용되지 않았다면 <time>의 자식요소는 없어야 하며 text content가 datetime value로 인식됩니다.(형식을 지켜야 합니다)

느낀점

Semantic HTML element는 의미를 소통하기 위해 존재한다고 생각합니다. 특히 Screen reader를 사용하는 분들의 접근성을 향상시킨다는 점에서 사용법에 맞게 사용해야 할 듯 합니다. 추후에 Semantic 요소들을 더 알게 되면 계속 추가해나가겠습니다.

참고사이트

• https://developer.mozilla.org/en-US/docs/Glossary/Semantics
• https://www.w3schools.com/html/html5_semantic_elements.asp
• https://developer.mozilla.org/en-US/docs/Web/HTML/Element/article
• https://developer.mozilla.org/en-US/docs/Web/HTML/Element/aside
• https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details
• https://developer.mozilla.org/en-US/docs/Web/HTML/Element/summary
• https://developer.mozilla.org/en-US/docs/Web/HTML/Element/figcaption
• https://developer.mozilla.org/en-US/docs/Web/HTML/Element/figure
• https://developer.mozilla.org/en-US/docs/Web/HTML/Element/form
• https://developer.mozilla.org/en-US/docs/Web/HTML/Element/footer
• https://developer.mozilla.org/en-US/docs/Web/HTML/Element/header
• https://developer.mozilla.org/en-US/docs/Web/HTML/Element/main
• https://developer.mozilla.org/en-US/docs/Glossary/DOM
• https://developer.mozilla.org/en-US/docs/Web/HTML/Element/mark
• https://developer.mozilla.org/en-US/docs/Web/HTML/Element/nav
• https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Heading_Elements#labeling_section_content
• https://developer.mozilla.org/en-US/docs/Web/HTML/Element/section

재사용 + 유지보수 향상

OOCSS(Object Oriented CSS)

It's an approach for writing CSS that's fast, maintainable and standards-based. It adds much needed predictability to CSS so that even beginners can participate in writing beautiful websites.

Object

Basically, a CSS "object" is a repeating visual pattern, that can be abstracted into an independent snippet of HTML, CSS, and possibly JavaScript. That object can then be reused throughtout a site.

작성법

아래 소개된 규칙에 따라 class명을 쪼개는 것이 중요하다고 생각됩니다. 중복되는 것(skin)은 하나로 묶어 빼내고 독립적인 것(content)은 잘게 쪼개는 방향으로 진행합시다.

2 Main Principles of OOCSS

1. Seperate structure and skin

This means to define repeating visual features(like background and border styles) as separate "skins" that you can mix-and-match with your various objects to achieve a large amount of visual variety without much code.

중복되는 디자인 CSS(skin)들을 따로 클래스명으로 작성해서 공통 적용시키는 것입니다.

2. Seperate container and content

Essentially, this means "rarely use location-dependent styles". An object should look the same no matter where you put it.

A container is never useful information to the user on its own; only the content elements whithin it convey reasonable information to the user.

중요한 것은 재사용성이므로 컨텐츠만 별도로 css를 설정하여 다양한 container안의 컨텐트에 적용될 수 있도록 해야합니다.

BEM(Blocks, Elements and Modifiers)

작성법

class="Block__Element--Modifier"

_과 - 병용, 갯수에 따라 구분하는 등 다양한 작성방법이 있으니 본인이 구분하기 쉬운 방법을 사용하면 될 듯 합니다. 저는 확실한 구분을 위해 코딩애플 선생님이 추천하신 class="덩어리이름__역할--세부특징"을 사용하려 합니다.

Block

standalone entity that is meaningful on its own

Block은 스스로 독립적인 의미를 가진 덩어리입니다.

Examples

header, container, menu, checkbox, input

Element

A part of a block that has no standalone meaning and is semantically tied to its block

Element는 독립적인 의미는 없지만 block에 종속되면 의미(역할)를 가지는 아이입니다.

Examples

menu item, list item, checkbox caption, header title

Modifier

A flag on a block or element. Use them to change appearance or behavior.

Modifier는 block 또는 element의 세부특징을 묘사하는 아이입니다.

Examples

disabled, highlighted, checked, fixed, size big, color yellow

SMACSS(Scalable and Modular Architecture for CSS)

Feel free to take this in its entirety or use only the parts that work best for you. Or don't use it at all.

At the very core of SMACSS is categorization. By categorizing CSS rules, we begin to see patterns and can define better practices around each of these patterns.

There are five types of categories: Base/ Layout/ Module/ State/ Theme Much of the purpose of categorizing is to codify patterns - things that repeat themselves within our design.

SMACSS의 공식문서를 읽어보았는데 너무 읽히지 않았습니다. CSS 방법론은 말 그대로 하나의 방법을 제시하는 것이고, 저자 역시 굳이 사용할 필요가 없다고 하였으니 다음에 필요성을 느끼게 된다면 진지하게 읽어보려합니다.

최근경향

CSS 방법론은 대부분 2010년대 초반에 나왔습니다. 현 2020년대 웹개발은 react, view 등 라이브러리를 사용하여 component 단위로 css를 설계하고 있습니다. 고로 css file의 size가 작아졌고 광대한 사이즈의 css파일을 정리하기위한 CSS 방법론은 쓸모가 적어졌습니다.

느낀점

CSS 방법론 3가지를 공부하면서 개발자들에 있어 재사용성, 유지보수를 위한 설계가 중요하다는 것을 다시 깨달았습니다. CSS 방법론들의 철학을 공부할 수 있었던 좋은 기회였습니다.

참고사이트

• 코딩애플 HTML/CSS 강좌
• https://github.com/stubbornella/oocss/wiki
• https://www.slideshare.net/stubbornella/object-oriented-css
• https://github.com/stubbornella/oocss/wiki/Module
• https://webactually.com/2019/10/08/%ea%b0%9d%ec%b2%b4-%ec%a7%80%ed%96%a5-css-%ec%86%8c%ea%b0%9c/
• https://getbem.com/introduction/
• https://smacss.com/book/

CSS Reset과 CSS Normalize의 목표는 모든 브라우저의 기능적, 디자인적 일관성을 실현하는 것이었습니다. 둘의 차이는 브라우저의 내장 스타일 의존 여부입니다. CSS Reset은 브라우저의 내장 스타일에 전혀 의존하지 않는 반면, CSS Normalize는 브라우저 내장 스타일을 최대한 따르면서 차이점들만 손 보는 정도라고 볼 수 있습니다.

CSS Reset

CSS Reset은 프로젝트 css작업 전 전체 css 파일에 적용될 css 설정을 미리 설정해두는 것입니다. 공식이 정해져있는 것은 아니므로, 많이 쓰이는 버전들을 참고하여 자신만의 CSS Reset을 만들면 좋을 듯 합니다. 이 글에서는 Andy라는 디자이너분의 버전을 소개해드리려고 합니다.

Andy's CSS Reset

/* Box sizing rules */
*,
*::before,
*::after {
  box-sizing: border-box;
}

/* Remove default margin */
body,
h1,
h2,
h3,
h4,
p,
figure,
blockquote,
dl,
dd {
  margin: 0;
}

/* Remove list styles on ul, ol elements with a list role, which suggests default styling will be removed */
ul[role='list'],
ol[role='list'] {
  list-style: none;
}

/* Set core root defaults */
html:focus-within {
  scroll-behavior: smooth;
}

/* Set core body defaults */
body {
  min-height: 100vh;
  text-rendering: optimizeSpeed;
  line-height: 1.5;
}

/* A elements that don't have a class get default styles */
a:not([class]) {
  text-decoration-skip-ink: auto;
}

/* Make images easier to work with */
img,
picture {
  max-width: 100%;
  display: block;
}

/* Inherit fonts for inputs and buttons */
input,
button,
textarea,
select {
  font: inherit;
}

/* Remove all animations, transitions and smooth scroll for people that prefer not to see them */
@media (prefers-reduced-motion: reduce) {
  html:focus-within {
   scroll-behavior: auto;
  }

  *,
  *::before,
  *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

하나하나 뜯어보겠습니다.

box-sizing: border-box;

/* Box sizing rules */
*,
*::before,
*::after {
  box-sizing: border-box;
}

이는 박스에 기본적으로 설정되어 있는 속성인 content-box를 border-box로 바꾸는 작업입니다. border-box는 content + border + padding을 전부 고려하여 사이즈를 정하기에 개발자가 디자인하기 편리해집니다. 그리고 pseudo-elements로 경우를 명시적으로 설정해두는 것이 좋다고 생각되어 단순히 *로만 표기하지 않았습니다.

margin: 0;

/* Remove default margin */
body,
h1,
h2,
h3,
h4,
p,
li,
figure,
figcaption,
blockquote,
dl,
dd {
  margin: 0;
}

다른 버전의 경우 *로만 margin을 설정하는 경우가 있었는데 Andy의 경우에는 브라우저 설정이 있는 tag들만 margin을 설정합니다. Andy가 설정하는 방식이 reasonable하다고 판단되어 Andy의 버전이 따르려고 합니다.

scroll-behavior: smooth;

html:focus-within {
  scroll-behavior: smooth;
}

scroll-behavior: smooth;는 스크롤로 작동되는 웹 환경에서 UX를 향상시킬 수 있는 속성이어서 필수라고 생각합니다. pseudo selector를 사용하지 않는 버전도 있었지만 :focus-within 되었을때만 설정되는 것이 reasonable한 것 같습니다.

body

body {
  min-height: 100vh;
  text-rendering: optimizeSpeed;
  line-height: 1.5;
}

min-height: 100vh

height의 단위로 vh를 추천하지않는 글을 읽은 적이 있습니다. 그 이유는 브라우저의 ui가 존재하기에 개발한 웹페이지의 100vh는 화면에 모두 보이지 않기 때문입니다. 예를 들어 내가 사용중인 아이폰13미니의 높이는 2340px로 되어있는데 사파리의 ui가 300px정도 존재한다면 100vh(2340px)로 설정한 디자인은 일부가 잘린채로 보이게 되기 때문입니다.(2340 - 300) 다만, 브라우저마다 ui의 height가 다르기에 일관성을 위해 Andy는 100vh로 설정했다고 해석했으며 이는 충분히 납득되었습니다.

text-rendering: optimizeSpeed;

이 부분은 찾아봐도 잘 모르겠어서 다음에 다시 공부해 봐야겠습니다.

line-height: 1.5;

Use a minimum value of 1.5 for line-height for main paragraph content. This will help people experiencing low vision conditions, as well as people with cognitive concerns such as Dyslexia.

기본 설정은 1.2로 되어있는데, 1.5 이상의 수치를 설정해야 읽는데 어려움이 없다고 합니다.

list-style: none;

ul[role='list'],
ol[role='list'] {
  list-style: none;
}

여기서 중요한 부분은 [role='list']인 경우에 list-style: none;을 적용하는 것입니다. 그 이유는 navigation bar를 주로 list로 만드는데 디자인을 위해 list-style: none;을 설정하게 되면 VoiceOver가 list의 sementic한 요소를 읽지 못하게 됩니다. 이를 개선하기 위해 상위 요소인 ul이나 ol에 role='list'속성을 주게 되면 VoiceOver가 list의 sementic 요소를 읽을 수 있게 되는 것입니다.

text-decoration-skip-ink: auto;

a:not([class]) {
  text-decoration-skip-ink: auto;
}

이는 globally하게 link에 설정되어있지만 Andy가 불편함을 느꼈던 적이 있어 설정한 경우라고 합니다. 이는 굳이 작성하지 않아도 될 듯 합니다.

img

img {
  max-width: 100%;
  display: block;
}

max-width: 100%는 이미지가 viewport에서 짤리게 되면 의미가 없기에 그 안으로 설정해놓는 것인듯하여 reasonable 합니다. display: block은 이미지는 inline 태그이기에 다른 inline 태그들과 섞이게되면 가독성이 떨어질 수 있다고 생각하여 reasonable합니다. 다만, 이 속성은 단순 img만 국한될 필요없이 모든 미디어에 적용되면 좋을 듯 합니다.(picture, video, canvas, svg 등)

font: inherit;

input,
button,
textarea,
select {
  font: inherit;
}

위 설정된 태그들은 기본 설정된 글꼴이 존재합니다. 그렇기에 웹페이지 글꼴과 일치하지 않으면 이질감을 줄 것입니다. 이에 글꼴을 상속하여 통일시킨다면 일관성을 줄 수 있고 UX적으로도 불편하지 않을 듯 합니다.

@media (prefers-reduced-motion: reduce)

@media (prefers-reduced-motion: reduce) {
  *,
  *::before,
  *::after {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    scroll-behavior: auto !important;
  }
}

이 분은 prefers-reduced-motion: reduce와 !important의 활용법이 머리에 들어오지 않아서 우선은 적용하지 않으려고 합니다. 이후 관련 문법이 이해가 된다면 다시 해석하고 적용해보겠습니다.

CSS Normalize

CSS Normalize는 공통으로 사용되는 파일이 존재해서 다운 후 적용하면 될 듯합니다. 그러나 개인적으로 이해없이 다운하여 적용하는 것을 좋아하지 않아서 CSS Reset을 우선 적용하다가 필요를 느끼게된다면 다시 공부 후적용해보겠습니다.

느낀점

CSS도 공부할 게 엄청 많고 깊다는 것을 깨달았습니다. CSS도 쉽게 볼 것이 아니라 분석하고 사용이유를 알고 사용하겠습니다.

참고사이트

• 코딩애플 html/css 강좌
• https://andy-bell.co.uk/a-modern-css-reset/
• https://meyerweb.com/eric/tools/css/reset/
• https://www.joshwcomeau.com/css/custom-css-reset/
• https://itchallenger.tistory.com/885
• https://github.com/necolas/normalize.css/blob/master/normalize.css
• https://dev.to/frehner/css-vh-dvh-lvh-svh-and-vw-units-27k4
• https://www.scottohara.me/blog/2019/01/12/lists-and-safari.html
• https://gerardkcohen.me/writing/2017/voiceover-list-style-type.html
• https://www.daleseo.com/css-normalize-reset/
• https://developer.mozilla.org/en-US/docs/Web/CSS/scroll-behavior
• https://developer.mozilla.org/en-US/docs/Web/CSS/text-rendering
• https://wit.nts-corp.com/2017/09/25/4903
• https://iamvdo.me/en/blog/css-font-metrics-line-height-and-vertical-align
• https://developer.mozilla.org/en-US/docs/Web/CSS/line-height
• https://css-tricks.com/introduction-reduced-motion-media-query/
• https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity

react 예제를 실습하기 위해 npx create-react-app react_dev을 한 뒤 github에 연동하기위해 git clone을 실행하였다.

에러메시지 해석

react_dev라는 경로가 이미 존재하고 그 폴더가 비어있지 않은 것이 문제라는 뜻 같다.

git clone을 해보면 항상 repository이름과 같은 폴더가 만들어지는 경험을 했는데 그 폴더가 CRA로 존재하는 폴더와 이름이 같기때문에 만들어지지 않는 듯 하다.

shooting

당장 떠오르는 방법은

1. 현재 존재하는 CRA 폴더를 삭제하고
2. gitclone을 한 뒤
3. 그 폴더에 CRA를 설치하면 될 것 같다.

gitclone

내 생각에 이번 trouble의 원인은 gitclone을 목적에 맞게 사용하지 않았기 때문인듯 하다.

git-clone : Clone a repositoty into a new direcory

프로젝트를 하면서 gitclone을 했던 경험은 github에 공유된 작업물을 로컬에서 작업하기 위해 베껴오는(clone) 용도였다.

나는 먼저 작업물을 만들고 이미 형성되어있는 repository를 clone하려고 했으니 당연히 안 되었던 것이다.

만약 작업중인 폴더를 github에 올리고 싶다면??

1. git init

git-init : Create an empty Git repository or reinitialize an exisiting one

로컬 폴더에 빈 git repository 를 생성하고

2. git remote add origin [git repository 주소]

remote 에 origin이라는 이름으로 github repository를 추가한 뒤에

3. git push origin master

github에 master라는 이름의 브랜치에 push했다.

trouble again

github에는 main이라는 default branch가 있었는데 main과 관련없는 master라는 브랜치가 뚜둥하고 등장해버렸다. 수습하기위해 로컬에서 push한 master 브랜치를 main 브랜치에 pull request를 해보려했지만 commit history가 달라서 실행을 할 수 없었다.

문제는 commit history가 다른 master 브랜치의 등장이다!

shooting again

당장 떠오르는 방법은

1. 원격의 master 브랜치를 삭제하고
2. local에서 git push origin main으로 main브랜치에 푸시하는 방법이다.

commit history

git이 commit history가 다른 브랜치들의 병합을 기본적으로 막는 설정이 되어 있다는 것은 그만큼 commit history가 git에서 중요하다는 의미일 것이다.

commit history를 직역하면 commit들의 역사란 의미인데 commit이 무엇인가!?

이는 git에 관한 강좌나 자습서를 다시 읽어봐야겠다...

참고사이트

https://git-scm.com/docs/git-clone https://git-scm.com/docs/git-init