typescript

서론 좋은 코드의 조건을 다양합니다. 하지만 "표현이 직관적이며 동작이 예상 가능한 코드"가 좋은 코드라는 것에는 이견이 없을 것이라 생각합니다. 동작이 예상 가능한 코드라는 표현을 달리 말하면 오용하기 어려운 코드라고 할 수 있습니다. 오늘 주제는 코드의 제약 조건에 의해 발생하는 오용 가능성과 이런 제약 조건을 핸들링해서 오용 가능성을 좁히는 내용입니다.(이 내용은 좋은 코드, 나쁜 코드에 수록된 내용을 정리한 것임을 밝힙니다.)  제약 조건이 있는 코드오용하기 쉬운 코드는 암묵적 제약 조건이 많은 코드라고 할 수 있습니다. 제약 조건에 대한 이해가 있어야 제대로 사용할 수 있는 코드라는 말은 자칫 잘못 사용되기 쉬운 코드라는 말이 됩니다. 다음의 예제를 통해 코드에서 발생하 수 있는 제약조건에 대해..

1. Type assertion 대신 Type Guard로 타입 좁히기as(type assertion)대신 type guard를 사용하는 것이 대부분 더 안전합니다.as(type assertion)의 경우 type 체크의 블랙박스를 만들고 운영 이슈로 이어질 수 있습니다.const dog = {} as Dog;// ❌ 런타임 에러가 나기 쉽다.dog.bark();interface Animal { type: 'dog' | 'bird'}type AnimalType = Animal['type']interface Dog extends Animal { type: 'dog'; bark: VoidFunction}interface Bird extends Animal { type: 'bird'; ..