우선 이 저장소는 비전공자 → 개발자 사고 전환을 목표로 한 단기간 집중 훈련 과정입니다. DOM, 프론트엔드 UI 대신 순수 로직 / 함수 분리 / 클린 코드 / 테스트 기반 개발에 초점을 맞추었습니다.
우테코 프리코스, 소마, SSAFY 등의 코딩 테스트를 준비하기 전, 워밍업과 기본기 다지기에 적합합니다.
- 문제를 작게 쪼개고 함수 단위로 해결하는 습관 기르기
- 매직 넘버/문자 제거, 의미 있는 변수/함수명 사용
- Jest를 활용한 테스트 주도 개발(TDD) 경험
- 14 Unit을 통해 개발자식 사고로 전환
- Unit 01: 문자열 뒤집기, 배열 합/최댓값 (매우 쉬움 - 스킵하셔도 좋습니다)
- Unit 02: 문자열 계산기 (기본, 구분자 , :)
- Unit 03: 문자열 계산기 (확장, 커스텀 구분자)
- Unit 04: 로또 번호 생성기
- Unit 05: 숫자 야구 게임
- Unit 06: 정렬 & 탐색 (버블정렬, 이진탐색)
- Unit 07: 리팩토링 및 1주차 종합
- Unit 08: Stack & Queue, 괄호 유효성 검사
- Unit 09: DFS/BFS, 미로 탐색 (어려울 수 있음 - Unit 10 먼저 해도 괜찮습니다)
- Unit 10: Map/Set 활용, 로또 통계
- Unit 11: 슬라이딩 윈도우, 투포인터 (어려울 수 있음 - Unit 12 먼저 해도 괜찮습니다)
- Unit 12: 장바구니 로직 (순수 함수형)
- Unit 13: 코드 리팩토링
- Unit 14: 최종 콘솔 프로젝트 (문자열 계산기 + 장바구니 + 로또)
solutions 파일에 각 Unit 풀이과정 및 학습노트(생각 과정)를 적어두었습니다.
개발자식 사고와 클린 코드 습관을 익히는 것을 목표로 합니다. 그렇기에 모든 문제 풀이에서 아래 규칙을 지킵니다.
var사용 금지 → 항상const/letelse if/else지양 → 가급적 조기return으로 흐름 단순화- 함수는 한 가지 역할만 수행 (SRP 원칙)
- 의미 있는 이름 사용 (예:
arr대신numbers,str대신inputText) - 매직 넘버/문자 제거 → 상수로 정의 (
const MAX_SIZE = 6;) - 테스트 우선: 문제 풀기 전에 Jest 테스트부터 작성
- 들여쓰기: 2칸
- 함수 길이: 10줄 이내 권장
- 화살표 함수는 간단한 콜백일 때만 사용
- 나머지는 명확성을 위해 일반 함수 선언 사용
- 입력값이 잘못되면
throw new Error(...) - 빈 배열, 빈 문자열 등 엣지 케이스 테스트 필수 작성
# 1. 레포 클론
git clone https://github.com/lee-eojin/VanillaJS-CleanCode-Focus.git
cd VanillaJS-CleanCode-Focus
# 2. 패키지 설치
npm install
# 3. Unit-01부터 시작
cd Unit-01
# README 읽고 구현 → npm test로 확인Q. 테스트가 통과하는데 답이 맞는지 모르겠어요
테스트 코드를 읽어보세요. 테스트는 요구사항 명세서입니다.
- 어떤 입력에 어떤 출력이 나와야 하는지
- 예외 상황은 어떻게 처리해야 하는지
모두 테스트 코드에 있습니다.
Q. `var`를 쓰면 안 되나요?
저도 'var'로 공부를 시작해서 습관을 고치는게 오래걸렸습니다.
우테코/소마 등 실전 코딩 테스트에서는 var 사용을 권장하지 않습니다.
const: 재할당 불가 (기본값)let: 재할당 필요할 때만
함수 스코프인 var는 예상치 못한 버그의 원인이 됩니다.
Q. `else`를 왜 지양하나요?
조기 return으로 분기를 줄이면 가독성이 높아집니다.
// Bad
function validate(input) {
if (input) {
if (input.length > 0) {
return true;
} else {
return false;
}
} else {
return false;
}
}
// Good
function validate(input) {
if (!input) return false;
if (input.length === 0) return false;
return true;
}Q. 함수가 너무 작아지면 오히려 복잡하지 않나요?
저도 처음엔 그랬습니다. 하지만 반대로, 작은 함수 = 테스트하기 쉬운 함수입니다.
- 각 함수가 하나의 역할만 하면 버그 추적이 쉬움
- 재사용 가능
- 함수명으로 의도를 표현 가능
익숙해지면 오히려 읽기 편합니다!
Q. 랜덤 함수는 어떻게 테스트하나요?
Unit 04 심화 섹션을 참고하세요.
- 의존성 주입으로 테스트용 RNG 전달
- 시드 기반 결정적 테스트
- 속성 기반 테스트 (fast-check)
Q. Unit 09, 11이 너무 어려워요
순서를 바꿔도 괜찮습니다.
- Unit 09(DFS/BFS) ⇒ Unit 10 먼저
- Unit 11(슬라이딩 윈도우) ⇒ Unit 12 먼저
난이도가 높은 문제는 나중에 도전하세요. 아니면 solutions 파일을 참고해보세요.
개선 제안이나 오타 수정 있으면 이슈나 PR 남겨주세요!
- 포크하기
- 브랜치 만들기 (
git checkout -b fix-typo) - 수정사항 커밋 (
git commit -m '오타 수정') - 푸시 (
git push origin fix-typo) - PR 올리기
만든이: @lee-eojin