패스트캠퍼스 강의를 정리한 내용입니다.
"The RED : 프론트엔드 Back to the Basics : 지속 가능한 코드작성과 성능 향상법 by 김태곤"
좋은 코드
-
사람이 읽기 좋아야 함
-
간결하고 의도가 명확해야 함
→ 주석으로 보조하는 건 괜찮지만 가능하다면 코드 만으로도 의도가 충분히 드러니도록 작성
"사람이 이해할 수 있는 코드는 바보라도 작성할 수 있다. 좋은 프로그래머는 사람이 이해할 수 있는 코드를 작성한다" - 마틴파울러
추천 도서 : 리팩터링 2판 (저자 마틴파울러)
→ 단순성(Simplicity). 복잡성이 증가하면 확장성(Scalability), 성능(Performance), 보안(Security) 등에 문제를 초래할 수 있음 -
가능하면 의존성이 적은 코드
JavaScript는 노드와 npm이 나타난 이후 다른 사람 코드를 가져다 쓰기 용이하나 가져다 쓰는 경우 의존성이 높아짐
2016년 발생한 leftpad 사건
leftpad: 문자열의 길이가 주어진 숫자보다 작으면 공백 또는 전달한 문자를 채워넣어서 길이를 맞춰주는 모듈
leftpad 모듈 코드: https://github.com/left-pad/left-pad/blob/master/index.js
leftpad 개발자가 모종의 사건때문에 자신이 올린 프로젝트를 다 지웠는데 이때 leftpad가 포함되어 있었고, 이 사건으로 인해 이에 의존하는 다른 수많은 모듈도 작동이 멈춰버림
관련 기사 참고: "11줄의 코드, 인터넷을 패닉에 빠뜨리다"
- 하나의 함수, 메소드, 클래스는 각각 명확한 하나의 책임만 지니도록 함
접속사 없이 한 문장으로 설명할 수 없으면 코드에 대해 다시 고민해보기
분기가 발생하는 조건문, 반복문이 많아질 수록 복잡도 증가
디버깅
일반적인 디버깅 단계
- 정상 시스템의 동작, 즉 기대하는 동작 정의
- 원인을 섣불리 추측하지 않고, 일단은 "모른다"고 생각하고 출발
- 근본적인 원인을 알 때까지 최대한 많은 데이터를 모으며 현상 관찰
- 증상이 아닌 원인을 수정
버그 정의에 필요한 세 가지
-
재현 과정
백엔드는 로그를 보고 데이터의 입출력 확인이 가능하지만, 프론트는 사용자의 액션으로 발생하는 버그가 대부분이므로 정확한 재현 과정 필요
웹 브라우저에 설치한 확장 기능 때문에 버그가 발생할 수도 있고, 사용자의 인터넷 환경이 느리거나 불안정해서 문제가 생길 수도 있음 -
기대 동작(정상 시스템의 동작)
왜 이것을 에러라고 인식했는가
예를 들어,
"주문 버튼을 클릭했는데 주문 완료까지 3초가 걸렸다"
이것은 에러일 수도 있고 아닐 수도 있음
에러가 되려면 "결제는 1초 안에 완료되어야 한다"와 같이 기대 동작이 있어야 함
"한국어 입력에 문제가 있다"는 무의미한 버그 보고
"'패스트캠퍼스'를 입력했는데 캠 부분의 받침이 분리되어야 캐ㅁ으로 된다"와 같이 정확한 기대 동작이 있어야 유의미한 버그 -
에러 메시지
브라우저 콘솔에 에러 메시지가 나타나는 버그는 상대적으로 원인을 발견하기 쉬운 편
정적 분석: 실행하지 않고 코드를 분석해 문제점을 찾아내는 것
타입스크립트는 정적 분석을 지원함
테스트
- 작성한 코드가 의도한 대로 동작하는지 확인하는 자동화 되고 표준적인 방법
- 시스템에 관한 지식을 전달하는 것에 목적이 있음
- 좋은 테스트란 시스템에 관해 필요한 지식을 빠짐없이 전달할 수 있어야 함
- 특정 라이브러리 사용 시 공식 문서를 봐도 사용법이 어렵다면 관련 테스트 코드를 보는 것을 추천
- 에지 케이스(edge case)
- = 경계 케이스(boundary case)
- 주어진 조건이 극한의 상황일 때 발생하는 문제를 말함
- 일부러 테스트가 실패할 법한 값을 넣어서 테스트를 진행하는 것
좋은 테스트의 조건
- 빠른 실행 속도
- 내부 구현(테스트하지 않는 부분)을 변경했다고 해서 깨지면 안됨. 인터페이스(입출력 위주)를 중심으로 작성
- 테스트 시나리오를 잘 설정하여 버그를 찾을 수 있어야 함
- 테스트 결과에 일관성이 있어야 함
코드는 안 변했는데 실행할 때마다 테스트 결과가 달라지는 오류가 없어야 함 - 의도가 명확히 드러나야 함
