클린 자바스크립트

1주차 #

• 자바스크립트 언어에 대한 문법을 익히고, '잘' 사용하기 위한 시도를 하고 피드백을 받는다.
  • 어떻게 하면 메서드를 더 잘 사용하는 걸까?
  • 어떻게 하면 메서드를 더 효과적으로 접근할 수 있을까?
• 읽기 좋은 코드를 구현하는 것이 왜 중요한지를 직접 느끼고 코드를 개선해 읽기 좋은 코드로 변경해 보는 경험을 한다
  • 어떤게 읽기 좋은 코드인지?
    • 코드 리뷰
    • 읽기 좋은 코드의 기준, 판단 근거를 만들어가자
• 자신이 구현한 코드에 대해 테스트를 작성하고 리팩터링하는 경험을 한다팩토링을 하는 경험
  • 다양한 테스트 도구
  • 사용자 인터랙션
• 1주차 - 계산기
  • GitHub 기반으로 온라인 코드 리뷰하는 경험
  • 코딩 컨벤션을 준수하며 개발하는 경험
  • Cypress를 사용해 E2E 테스트를 작성하며 개발하는 경험
  • 함수(또는 메서드)를 분리하는 리팩토링 경험
• 2~3주차 - 로또
• 4~5주차 - 자동차 경주 게임
• 6~8주차 - 자판기

2주차 #

TDD(Test Driven Development) #

• 실패하는 테스트를 먼저 만들고, 그 테스트를 통과하기 위해 코드를 짜는 개발 방법
• 제대로 동작하는지 빠르게 피드백을 받기 위한 사고 방식
• 결정과 피드백 사이의 갭에 대한 인식, 더 나아가 결정과 피드백 사이의 갭을 조절하기 위한 테크닉
• 내가 던진 농구공이 들어갔는지 1달 뒤에 알 수 있다면...?
• 결국은 내 결정이 잘 동작하는지 빠르게 피드백을 얻는 것이 중요한 사고 방식
• 테스트 코드는 의도치 않은 유용한 부산물

  더 자주, 더 빨리 피드백을 받는 것 https://docs.google.com/presentation/d/18c4kP9oWbGvKOeX7hd6Tt9FDSWx0NRomdqxQpeUFeto/edit?usp=sharing

장점 #

1. 테스트를 먼저 작성하기 때문에 전체 코드에서 얼마나 많은 코드가 테스트되는가를 측정하는 테스트 커버리지 비율이 자연스럽게 높아진다.
2. 테스트 되는 것만 코드로 작성하므로 코드가 방대해지지 않는다.
3. 버그때문에 발생하는 시간 낭비 줄여주고, 코드가 원하는 바를 명확히 달성하는지 쉽게 확인

방법 #

1. 테스트를 먼저 작성한다. 만족하는 코드가 없는 상태이므로 테스트는 실패함
2. 테스트를 통과하는 코드를 작성한다.
3. 리팩터링: 중복이 보이거나 더 개선할 방법이 있다면 코드를 개선한다.

3대 원칙 - 로버트 C. 마틴 (밥 아저씨, 클린 코더) #

1. 실패할 테스트를 작성하기 전에는 아무런 프로덕션 코드도 작성하지 않는다.
2. 실패할 테스트 말고는 작성하지 않는다.
3. 현재 실패한 테스트를 만족시키는 코드 외에는 작성하지 않는다.

4주차 #

생성자의 의미 #

• 초기화
  • init() ?
  • reset() ?
• 생성자 함수에서 초기화 함수를 또 사용하는 경우?
  • 의미론적으로 고민
  • 여러 형태의 초기화 동작을 한번에 때려박는 경우가 있음

API 활용 #

• appendChild vs append

인자 다루기 #

• 인자가 여러 개인 경우
  • 3개 이상이면, 순서를 지켜야 해서 유연성이 떨어짐.
  • 객체를 고려하라.

Truthy & Falsy #

• equality table

전역 이벤트 등록 #

• closest 활용

에디터 지원 #

회고 #

• KPT 회고
  • Keep
  • Problem
  • Try
• 의식적으로 TDD 원칙을 따르고 있다.
• Cypress 테스트 도구에 익숙해졌다.
• 코드 리뷰에서 리뷰어와 적극적으로 소통한다.
• 프레임워크에 익숙해지면서 VanillaJS로 웹 개발하는게 점점 어렵게 느껴진다.
• JSX를 쓰고 싶다..
• 디자인 패턴 / 프로그래밍 설계 원칙 등 이론적인 부분에서 약점이 있다고 느낀다.
• 프레임워크 없는 프론트엔드 개발 책을 다시 한 번 읽어봐야겠다.
• MVC 패턴 / MVVM 패턴 등등 디자인 패턴에 대한 기초 지식 강화
• TDD는 불확실성이 높은 것에 대해 적용하기 좋은 전략

5주차 #

• HTML(HyperText Markup Language)
  • HyperText : 문서 간의 연결을 담고 있음
• 브라우저
• 디바이스
• 웹

6주차 #

테스트 경험 공유 #

테스트는 왜 할까? #

• QA 시간 절약, 디버깅 시간 감소
• 코드적인 관점이 아니라, 행위적인 관점에서 앱의 흐름을 볼 수 있음
  • 테스트 피라미드
• 최소한의 기능을 구현하기 위해 필요한 '기준'이 생긴다 (불필요한 코드를 줄일 수 있음)
• 코드 수정이 필요한 경우에도 과감해질 수 있음
• 잘 쓴 테스트 명세는 그대로 좋은 문서가 된다 (스펙 명세가 작업의 부산물로 명시적으로 나온다)
• 사람이 놓치기 쉬운 엣지 케이스 실수를 빠르게 체크할 수 있다
• 휴먼 에러를 방지한다 (인간이 만들지만 인간을 믿지 않는다)

무엇을 테스트 할까? #

• 기능 요구사항에 따른 정상적인 흐름
• 정말 중요한 핵심적인 비지니스 로직
• 엣지 케이스
• 잘못되면 타격이 큰 로직
• 최소한의 유효성 검사(밸리데이션)
• 렌더링 기능 (중요한 페이지라면 pixel 단위까지!)
• 네트워크 통신과 같은 비동기 처리
• 정상 플로우를 모르는 사용자 입장에서의 테스트
• 정책