[패캠] 프론트엔드 Back to the Basics : 지속가능한 코드 작성과 성능 향상법 강의 내용 정리

오늘은 패스트캠퍼스에서 최근에 수강했던 김태곤님의 <프론트엔드 Back to the Basics : 지속가능한 코드 작성과 성능 향상법> 강의를 듣고 학습했던 내용을 정리해 보려고 한다. 시작하기에 앞서서 이 강의는 패캠에서 어떠한 대가도 제공받지 않고 직접 수강하고 내용을 정리하는 것임을 밝힌다.

정리는 강의 목차 순서대로 정리했다.

1. 정체되지 않는 프론트엔드 개발자의 일하는 방식

프레임워크를 위주로 공부하다 보면.. 따라가기 급급해진다. 내부적인 원리를 이해하지 못하면 남는 것이 없다.

React, Vue는 컴포넌트 기반 개발이라는 공통점 ⇒ 이를 잘 알고 있으면 새로운 기술도 어렵지 않게 배울 수 있다.

 

• Homebrew → 패키지 매니저 for Mac
• VirtualBox → IE 환경 테스트

 

Frontend Developer : 어플리케이션이 사용자와 맞닿은 접점을 책임지는 사람

여러 기술을 넓게 알아야 하고 그렇다고 얕게 알아서도 안된다.

HTML은 버전이 사라지고 계속 변화하는 Living Standard. CSS도 비슷

매 해 새로운 명세가 나오고... 모르면 뒤쳐진다.

JavaScript 참 다양하게 쓰이는 언어 ⇒ 웹, 모바일 앱, 데스크톱 앱, 머신러닝 등

 

프론트엔드 개발은 배워야 할 것이 너무 많다. 넓게 배우면서 필요한 경우 깊게 들어가라.

• 공부할 범위를 축소하라.
• 공식 문서를 읽어라.
• 한 번에 완벽하게 다 읽기보다는 자주 읽어라.
• 새로 만들고 싶은 프로젝트 주제를 평소에 미리미리 담아두고 새로운 기술이 나오면 하나씩 적용해서 써보자.
• 어느정도 알고 있는 기술은 글로 남겨두어라.
• 복붙을 하더라도 그 안에서 원리를 이해하고 조금씩 부숴보면서 내 것으로 만들 것.

 

풀스택 개발자보다는 프론트엔드의 전문성을 가지는 쪽으로 커리어를 쌓자.

다만 백엔드 개발을 할 수 있을 정도의 지식을 갖추는 것은 바람직하다.

OKR을 세우고 그걸 뒷받침 할 프로젝트를 설정하자.

프로젝트를 할 때 배워간다면서 한다는 생각은 하지 마라.

어쩔 수 없이 배워야 한다면... 배워야 하는 갯수를 줄이자.

배우려고 하는 자세는 좋다. 하지만 일은 좀 더 효율적으로.

백엔드 개발자가 서버 작업을 하는 동안 프론트엔드 개발자는 가짜 서버, 가짜 통신, 가짜 데이터를 만들어서 작업하거나 아예 통신하는 과정을 생략할 수 있다.

사용자가 입력하는 행위는 항상 예상을 뛰어넘을 수 있다. 따라서 작성한 코드를 망가트려 보는 연습을 자주 하라.

 

2. Back to the Basics : 프레임워크보다 기본기

가능하면 영어로 용어를 익혀라 ex.unobstructive JavaScript ⇒ 겸손한 자바스크립트???

SameSite : Chrome 80에 나온 업데이트

• 이 속성이 없으면 다른 도메인의 서드파티 쿠키 값을 저장할 수 없음. 광고 등에서 영향이 있음

명확한 근거 : 모든 결정에는 구체적인 이유를 두자

경험적으로 아는 걸 아무 생각 없이 쓰면 누군가가 물어보았을 때 헤메게 된다.

이 기술을 왜 도입했는지...? : 많은 Big Tech Company는 이걸 항상 관심을 가지고 물어본다.

 

브라우저

노란색에는 자바스크립트 이벤트가 없고 네트워크 영역이다.

 

브라우저는 어떻게 동작하는가 (2011)

모던 웹 브라우저 들여다보기 (2018) → 이걸 좀 더 추천

• Layout 단계를 거치면 그 뒤에 과정(Paint, Rasterize 등)도 다 거쳐야 해서 비용이 많이 들어가기 때문에 Layout 단계를 최소화 하는 것이 성능 최적화를 하는 한 가지 방법이다.
• 이 모든 과정은 점진적으로 실행된다.
• CSS, JS 한 번에 읽도록 하는 이유 ⇒ 찔끔찔끔 가져와서 렌더링을 방해하지 말고, 한 번에 가져와서 성능을 올려라!

 

HTML

Semantic HTML : HTML 엘리먼트의 속성, 속성값은 특정한 의미를 지니도록 정의되었다.

HTML5에 의미를 가지는 태그들이 있는데 적절하게 사용하는 것이 바람직하다.

• section
• header
• footer
• main
• article
• nav

HTML5 → 의미를 기술하기 위한 Microdata가 추가됨

 

CSS

flex-direction: row ⇒ 글쓰기

!important는 가능하면 사용하지 말 것 : userAgent와 같이 브라우저에서 기본으로 지원하는 CSS를 바꿔야 하는 상황이 아닌 이상

• 요즘은 이런 CSS 방법론보다 CSS-in-JS를 더 많이 쓴다.
  • 자바스크립트 코드가 지저분해질 수 있다는 단점이 있다.

 

JAVASCRIPT

 

3. 10년 이상 쓸 수 있는 지속 가능한 코드 작성

좋은 코드란 무엇인가

기능이 단순하고 의존성이 적은 코드는 오랫동안 쓰일 수 있다.

좋은 코드는 간결하고 의도가 명확해야 한다.

컴퓨터가 이해할 수 있는 코드는 바보라도 작성할 수 있다. 좋은 코드는 사람이 이해할 수 있는 코드여야 한다.

1. 간결하고 의도가 명확
2. 의존성이 적은 코드
   1. 2016년 leftpad 사건 → 이 모듈이 사라지니 다른 수많은 의존성이 있는 프로그램이 멈춤
3. 하나의 함수, 클래스, 메소드는 명확한 하나의 책임만 지게 하는 것이 좋다.
   1. 접속사 없이 하나의 문장으로 설명할 수 있는가?
   2. complexity report

디버깅

• 정상 시스템의 동작, 기대하는 동작을 정의
• 원인 섣부른 추측 no, 일단은 모른다는 데에서 출발한다
• 근본적인 원인을 알 때까지 충분한 데이터 수집. 증상이 아니라 원인을 해결
• 시스템마다 미묘하게 다른 차이가 버그를 발생할 수 있다.
  • 웹 브라우저 환경의 차이, 안 좋은 인터넷 환경
• 많은 주니어는 에러 메시지를 읽지 않고 질문을 하는 경우가 많은데, 주니어가 시니어로 가려면 이 부분을 스스로 원인을 찾아 해결할 줄 알아야 한다.

정적분석

• 실행하지 않고 코드를 분석하는 방법
• 타입스크립트가 자바스크립트의 정적 분석을 지원

테스트

• 방어적인 프로그래밍
• 극단적인 상황을 고려
• 작성한 코드가 의도한 대로 동작하는지 확인하는 자동화되고 표준적인 방법
• 테스트의 목적 : 시스템에 필요한 지식을 전달
• 어떤 동작을 의도했는가?
• 어떤 edge case를 예상했는가?
  • 일부러 실패할 것 같은 값을 넣어서 진행 ex. 1.2 + 6 = 7 ?
• 좋은 테스트의 조건
  • 실행 속도가 빨라야 한다.
  • 테스트 하지 않은 부분을 구현했다고 해서 깨지지 말아야 한다.
  • 버그를 찾을 수 있어야 한다.
  • 테스트 결과에 일관성이 있어야 한다.
  • 의도가 명확하게 드러나야 한다.

테스트와 TDD, BDD

코드 커버리지

• 보통 라인수를 기준으로 측정
• 보통 70%가 넘으면 훌륭한 수준이라고 평가
• 100%는 불가능하고 맞출 필요도 없음
• TDD
  1. 테스트를 먼저 작성 (높은 확률로 실패할 것)
  2. 테스트를 통과하는 코드를 작성
  3. 리팩토링
• TDD 3대 원칙
  1. 실패할 테스트를 작성하기 전에는 아무 Production 코드를 작성하지 않는다.
  2. 실패할 테스트 말고는 작성하지 않는다.
  3. 현재 실패한 테스트를 만족하는 코드 외에는 작성하지 않는다.
• 제대로 지켜서 하는 곳 거의 못 봤다.
  • 처음에는 잘 지켜가며 하다가도 업무가 바쁘면 우선순위가 밀리기 마련

리팩토링

• 비슷한 작업을 세 번째 할 때 리팩토링을 해야 한다.
• 마틴 파울러 <리팩토링> 을 꼭 읽어볼 것
• 리팩토링을 하면서 기능이 그대로 유지되지 않은 경우 이는 리팩토링이라고 볼 수 없다.
  • Happy Case만 테스트 해보는 경우
• 테스트가 없는 리팩토링은 끔찍하다.

리팩토링 방법

1. 함수를 추출하거나 옮기는 방법
   • 로직을 별도의 함수나 모듈로 분리하기
2. 중간 변수를 도입하기
3. 조금 복잡한 계산이 필요하다면 함수로 만들어 보기
4. var 대신, let, const 쓰기, 순수함수 쓰기
5. 빠른 실패 코딩 패턴 (fast fail)
6. 반복문 보다는 pipe
7. 배열이나 객체는 immutable하게 다루는 것이 좋다.

 

4. 웹 어플리케이션의 성능을 200% 끌어올리기 위한 코드 점검 및 개선 방법

프론트엔드 개발자가 왜 성능을 신경써야하나요

Make it work, Make it right, Make it fast

by Kent Beck

• 프론트엔드 개발에서 성능 최적화는 다른 작업보다 우선 순위가 떨어짐

근데 왜?

• 속도가 빨라지면 사용자 경험이 좋아진다.
• 비용을 아낌
• 면접 문제로 자주 나옴

코드 바깥의 성능

시간

• 초기 구동 시간

• 6개 이상이면.. 한꺼번에 불러오지 않고 큐에 넣었다가 앞의 작업이 끝나고 나서 순차적으로 불러옴 → 사용자 경험 저하
  • 도메인을 여러개로 분산하여 불러와라
    • HTTP 1.1 기준
    • HTTP 2에서는 이 부분을 신경 쓸 필요는 없음
    • Network > Protocol > h2 (HTTP 2)
    • 크롬은 HTTP3 도 지원

• 컨텐츠 렌더링
• 인터렉션 기능

• 사람들은 오른쪽보다 왼쪽이 더 빠르게 컨텐츠가 나타난다고 생각한다.

• 계산 시간
• 자바스크립트는 싱글 스레드 언어이지만, 웹 워커(Web Worker)를 사용하면 멀티스레드처럼 사용이 가능하다.

• 느긋한 평가(Lazy Evaluation) : 값이 필요해지기 전까지 계산을 미뤄두는 기법
• 메모이제이션(Memoization) : 계산 결과를 기억해두고 반복 사용하는 기법. 루프, 재귀 호출 등 최적화

애니메이션 성능

반응 시간 : 지나치게 느린 애니메이션 및 응답 속도는 사용자 경험을 저해한다.

• 렌더링 순서
  1. 자바스크립트 : 자바스크립트로 시각적 변화 유발
  2. 스타일 : 어떤 규칙을 어떤 요소에 적용할지 계산
  3. 레이아웃 : 요소가 화면에서 차지하는 공간과 위치 계산. 다른 요소에 영향을 줄 수도 있음.
  4. 페인트 : 각 레이어에 픽셀을 그려내는 과정. 텍스트, 색, 이미지, 경계선, 그림자 등을 표현
  5. 합성 : 정해진 순서로 레이어를 합성하여 최종 결과물을 그려내는 과정
• 1~4번 : 메인 스레드(main thread), 5번 : 컴포지터 스레드(compositor thread)
  • 가능하면 메인 스레드의 과정을 줄이고, 컴포지터 스레드에서 작업을 처리할 수 있게 하는 것이 중요
  • 어떤 속성이 어떤 단계를 유발하는가? → CSS Trigger 사용

 

JavaScript 코드의 성능

• 리소스
  • 자원 소모
  • CPU, 메모리, 스토리지, 네트워크 트래픽 등등
  • 스크립트 언어는 CPU나 메모리, 스토리지는 크게 걱정할 필요가 없다.
• 메모리 누수 (Memory Leak) : 프로그램이 필요하지 않은 메모리를 계속 점유하는 현상
  • C, C++와 달리 JS엔진이 추정 후 해제 (GC)
  • 사용되지 않는 메모리는 참조를 해제해 주어야 하며, 그렇지 않을 경우 메모리 누수가 발생한다