반응형
📌 발표 요약 (타입 시스템과 트레이드오프)
1. JavaScript vs TypeScript의 타입 시스템 비교
| 구분 | JavaScript | TypeScript |
|---|---|---|
| 타입 시스템 | 동적 타입 (Dynamic), 약타입 (Weakly Typed) | 정적 타입 (Static), 강타입 (Strongly Typed) |
| 타입 검사 시점 | 런타임 (Runtime) | 컴파일 타임 (Compile Time) |
| 형 변환 | 암묵적 형변환 허용 (암묵적 변환 다수) | 명시적 형변환 필요 (타입 명확) |
| 예시 | "2" + 3 // "23" (문자열 덧셈됨) |
add(2, "3") 에러 (형 일치하지 않음) |
| 결과 예측 가능성 | 낮음 (예상 외의 결과 많음) | 높음 (형 검사로 안정성 확보) |
2. Typing - Static vs Dynamic / Strong vs Weak
| 기준 | 설명 |
|---|---|
| Static Typing | 컴파일 타임에 타입 검사 (TypeScript, Java) |
| Dynamic Typing | 런타임에 타입 결정 (JavaScript, Python) |
| Strong Typing | 암묵적 형 변환 금지 (Python, TypeScript) |
| Weak Typing | 암묵적 형 변환 허용 (JavaScript, PHP) |
그래프 상 구분:
- Strong & Static: C#, Java
- Strong & Dynamic: Python, Ruby
- Weak & Static: C, C++
- Weak & Dynamic: JavaScript, PHP
3. 트레이드오프 (TypeScript vs JavaScript 선택 시)
| 상황/요건 | 선택 / 고려 사항 |
|---|---|
| 빠른 개발, 자유로운 코드 작성 | JavaScript (약타입, 동적타입으로 빠름) |
| 안정적, 예측 가능한 코드, 협업 | TypeScript (정적, 강타입으로 안전성) |
| 형 변환 자유 필요 (Prototype 단계) | JavaScript |
| 대규모 서비스 (안정성 중요) | TypeScript |
✅ 테스트 코드 작성의 트레이드오프 & 기준
1. 테스트 코드 작성의 트레이드오프 (Trade-off)
| 관점 | 장점 | 단점 / 비용 |
|---|---|---|
| 많이 짤 때 (광범위한 테스트) | - 높은 신뢰성 - 리팩토링/변경 시 안정성 확보 - QA 대체 가능 |
- 개발 속도 저하 - 유지보수 비용 상승 - 처음부터 과도하면 개발 부담 |
| 최소한으로 짤 때 (핵심만 테스트) | - 빠른 개발 - 유지보수 부담 적음 |
- 리팩토링/버그 시 위험 - QA 의존 높음 |
2. 그렇다면 언제 테스트 코드를 반드시 짜야 할까? (핵심 기준)
| 상황 | 이유 |
|---|---|
| 1. 변하면 안 되는 핵심 로직 (서비스 무결성) | - 장애 방지 - 유저 신뢰 확보 |
| 2. 반복되는 휴먼 QA 작업 (시나리오 존재) | - 자동화로 QA 비용 절감 - 일관된 검증 |
| 3. 공통 컴포넌트 영향 받는 페이지 | - 다른 페이지까지 영향도 커서 검증 필요 |
| 4. 변화가 잦은 기능, 자주 고쳐지는 부분 | - 회귀 테스트 필요 (Regression) |
3. 실제 테스트 작성시 현실적인 접근법
| 구분 | 설명 |
|---|---|
| Happy Case 중심의 Unit Test | - 예상 가능한 정상 흐름 위주 - 함수형, 유틸성 기능 우선 |
| 중요 시나리오는 E2E | - 사람 대신 반복 확인 필요한 작업 ex) 로그인, 결제, 주요 흐름 |
| 모든 기능을 다 테스트 X | - 변경 가능성, 중요성, 리스크 고려하여 선별적으로 진행 |
| QA 시나리오 있으면 활용 | - 기존 사람이 수작업하던 걸 코드로 자동화 → 이미 정의된 시나리오 코딩화 |
4. 테스트 코드와 클린 코드 연결
| 클린 코드 원칙 | 테스트 코드와 연결 |
|---|---|
| 작은 함수, 단일 책임 | 테스트가 쉬운 구조 (한 함수가 하나만 하게) |
| 명확한 입출력 (Pure function) | 테스트 가능한 함수, 사이드이펙트 최소화 |
| 확장 가능한 코드 (OCP) | 새로운 테스트 케이스 쉽게 추가 가능 |
| 의존성 주입 (DI) | 모킹(mock) 가능, 독립적 테스트 가능 |
5. Best Practice를 위한 질문 리스트 (의사결정 가이드)
- 이 기능이 깨지면 서비스 전체에 치명적인가? (예: 결제, 인증)
- 이 부분이 변경될 때마다 QA가 반복되고 있나?
- 이 기능이 여러 페이지/컴포넌트에 공유되는가?
- 리팩토링/기획 변경 시 자주 깨질 위험이 있나?
- 이 기능의 정상 동작을 사람이 확인하는 게 시간이 오래 걸리나?
💡 최종 한 줄 요약
"모든 것을 테스트할 수 없다. 하지만 깨지면 안 되는 것을 중심으로 최소한의 안전망을 코드로 가져가자."
타입스크립트와 클린코드를 통해 예측 가능한 코드를 만들고, 테스트를 통해 유지보수를 보장하자.
반응형
'개발공부 > Javascript' 카테고리의 다른 글
| [프로그래머스]옹알이(1) (0) | 2025.02.13 |
|---|---|
| [Javascript]JavaScript 이터러블과 이터레이터 (0) | 2025.02.12 |
| try catch finally 는 항상 비동기를 기다리지 않는다 (1) | 2025.02.08 |
| ECMAScript 6 (0) | 2021.12.28 |
| DOM 이란? (0) | 2021.12.28 |