230909.log

Universe·2023년 9월 9일

목록 보기

13/14

🗓️ 날짜 : 2023.09.09

📚 할 일 : 영어 레퍼런스 번역하면서 공부해보기

⌛ 공부시간 : 19:00 ~ 21:00

TIL

영어로 된 레퍼런스 읽어보고 간단하게 정리해보기

도움이 많이 된다고 해서 추천받았다. 그래서 가끔씩 해보려고 한다.
레퍼런스를 읽어보는 행위 자체도 개발공부에 도움이 많이 되지만,
영어와 친해진다는 것은 개발자 인생에 정말 도움이 많이 된다고.

만약에 다른 분들이 이 글을 읽어보신다면 의역이 굉장히 많고 제대로 해석되지 않은 부분이
있을 수 있으니 원문을 읽으시는 것을 추천드립니다.

Array Types in TypeScript

원문

올해 초 매드 포콕이라는 사람은 타입스크립트의 배열을 표현할 때,
Array<string>(일반 표기법) 구문과 string[](배열 표기법) 구문의
사용법에 대해서 설문조사를 진행했다.
설문조사 결과 대부분의 개발자(78.7%)는 string[] 구문을 사용하고 있었다.

문명하게, 어떤 구문을 사용하든 기능적인 차이는 전혀 없다.
취향에 따라서 골라서 사용하면 된다.
어떤 표현법을 사용하던지 일관된 코드 작성을 위해서 array - type eslint rule 을
사용하는 것이 좋다.

78% 트위터 사용자 (개발자) 는 잘못된 표기법을 사용하고 있다.
항상 장단점이 있기 때문에 나는 이런 문제에 대해서 잘 다루지는 않으며,
이러한 경우 어떠한 방법이 더 낫다고 말할 수 없지만,
일반 표기법(Array<string>)이 훨씬 더 낫다고 확신한다.

이러한 논쟁이 있을 때마다 누군가가 배열 표기법을 선호한다고 하면
나는 배열 표기법의 단점과 사례를 보여주며 상대방은 거의 즉각적으로 납득한다.
하지만 그 전에, 배열 표기법을 좋아하는 사람들이 항상 주장하는 장점에 대해서 말해보자.

짧아요

그게 전부다. 그건 장점이다. 작성해야 할 문자가 더 적다.
코드를 짧게 유지하는 것은 유지보수성을 좋게 만드는 지표이다.
let 은 const 보다 작성해야 할 문자가 적은데,
그렇다면 모든 변수 선언에 let을 사용해야 할까? 너무 갔다.

하지만 진지하게 -i 는 index 보다 짧고, d는 dashboard 보다 짧다.
(이 예시는 무슨 예시인지 잘 모르겠다.)
항상 짧은 코드가 좋은 코드가 되는 것은 아니다.
우리는 코드를 작성하는 것 보다 더 자주 코드를 읽게 된다는 사실을 알고 있으므로,
코드를 작성하기 쉽게 만드는 것에 초점을 두는 것이 아니라,
읽는 것을 쉽게 만드는 것에 초점을 맞추는 것이 좋다.

가독성

우리는 언제나 왼쪽에서 오른쪽으로 읽고 더 중요한 것을 항상 처음에 놓는다.
우리는 "이것은 string의 배열이다" 혹은 "이것은 string이나 number의 배열이다"
라고 말한다.

// ✅ 왼쪽에서 오른쪽으로 읽기에 좋다. (Array 에 조금 더 초점을 맞출 수 있다는 뜻인듯)
function add(items: Array<string>, newItem: string)

// ❌ String 과 유사하다. (String 과 String[] 가 유사해서 구별하기 힘들다는 뜻인듯)
function add(items: string[], newItem: string)

이는 배열의 유형이 어딘가에서 유추된 경우와 같이 다소 긴 경우 특히 중요하다.
(무슨 의미인지 잘 모르겠어서 번역기를 돌린부분)
IDE 에서는 언제나 배열 표기법으로 배열의 유형을 표시하기 때문에,
때때로 객체 내부의 배열에 hover 하면 아래와 같은 메시지가 표시된다.

const options: {
  [key: string]: unknown
}[]

내게는 const option 이, 객체 처럼 보이지만 마지막까지 가서야
사실 배열이었다- 라는 것을 알 수 있다.
배열에 property 들이 많다면 콘텐츠가 길어지고 팝업창에 스크롤바가 표시되어
마지막에 있는 [] 기호를 보는 것이 어려워지기 때문에 더욱 더 상황이 나빠진다.
당연하게도, 이것이 tooling problem 일 수도 있지만,
(tooling problem 은 다루는 IDM 의 문제일 수도 있다는 말인듯)
일반 표기법을 사용한다면 이런 문제가 발생하지 않을 것이다.
객체의 배열이다. 여러줄로 분산되어 있다면 그렇게 길지도 않다.

const options: Array<{
  [key: string]: unknown
}>

어찌됐든지, 일반 표기법(array notation 이라고 되어있지만 문맥상 일반 표기법을 말하는듯)
의 장점은 이것 뿐만이 아니므로 계속하겠다.

Readonly Arrays

현실을 직시해라. (Let's face it, 이럴 때 쓰는 표현인가? 모르겠다.)
함수의 입력으로 사용되는 대부분의 배열은 유연한? 의도하지 않은 변형을 방지하기 위해
읽기 전용이어야 한다.
해당 주제는 다른 article 에서 다룰 생각이다. 링크
일반 표기법을 사용하는 경우에는 Array 를 ReadonlyArray로 바꾸고 속행하면 되지만,
배열 표기법을 사용하는 경우, 두 부분으로 나누어서 진행해야 한다.

// ✅ 의도하지 않은 변경을 방지하기 위해 Readonly 를 선호한다.
function add(items: ReadonlyArray<string>, newItem: string)

// ❌ "readonly" 와 Array 가 두 부분으로 나뉘었다.
function add(items: readonly string[], newItem: string)