회사에서 세미나를 위해 준비했던 내용을 벨로그에 옮겨봅니다.

기본 개념

Storybook은 프론트엔드 개발자들이 사용하는 오픈 소스 도구입니다. Storybook은 개발자들이 컴포넌트 기반의 사용자 인터페이스(UI)를 개발, 테스트, 문서화하는 데 도움을 주는 환경을 제공합니다.

Storybook은 개발자가 작성한 각각의 컴포넌트를 독립적으로 테스트하고 시각적으로 확인할 수 있게 해줍니다. 개발자는 각각의 컴포넌트를 스토리라는 단위로 구성하여 개별적으로 렌더링하고 상태를 조작하며 여러 상황에서 컴포넌트의 동작을 테스트할 수 있습니다. 이를 통해 컴포넌트의 외형과 상태 변화를 쉽게 확인할 수 있으며, 개발자들끼리 컴포넌트의 동작을 공유하고 협업할 수 있습니다.

또한, Storybook은 컴포넌트의 문서화를 위한 훌륭한 도구입니다. 개발자는 컴포넌트에 대한 설명, 속성, 예제 등을 작성하여 문서화할 수 있으며, 이를 통해 다른 개발자들이 컴포넌트를 사용하는 방법을 이해하고 쉽게 활용할 수 있습니다.

Storybook은 다양한 프레임워크와 라이브러리를 지원하며, React, Vue, Angular 등의 주요 프론트엔드 프레임워크와 함께 사용할 수 있습니다. 또한, Storybook은 확장성이 뛰어나고 커스터마이징이 용이하여 개발자들이 자신의 프로젝트에 맞게 활용할 수 있습니다.

설치 & 실행

// 프로젝트 시작
npx create-react-app@latest first-storybook --template=typescript

// Storybook 설치
// 각 환경에 따라 다를 수 있습니다.
npx -p @storybook/cli sb init

// Storybook 실행
npm run storybook

장단점

장점:

1. 개발 생산성 향상: Storybook은 컴포넌트를 독립적으로 테스트하고 시각적으로 확인할 수 있는 환경을 제공하여 개발자가 컴포넌트를 빠르게 개발하고 디버깅할 수 있도록 도와줍니다. 또한, 컴포넌트의 상태를 조작하고 다양한 상황에서 테스트할 수 있으므로 개발 생산성을 향상시킬 수 있습니다.

2. 시각적 테스트 및 디자인 시스템 구축: Storybook은 컴포넌트의 시각적인 모습을 확인할 수 있는 테스팅 환경을 제공합니다. 따라서 디자이너나 비개발자들과의 협업 시에도 컴포넌트의 디자인을 시각적으로 검토하고 피드백을 주고받을 수 있습니다. 또한, Storybook은 디자인 시스템을 구축하는 데에도 활용될 수 있어 일관된 UI 개발을 도모할 수 있습니다.

3. 문서화와 커뮤니케이션: Storybook은 컴포넌트에 대한 문서화를 용이하게 해줍니다. 개발자는 각각의 스토리에 대한 설명, 속성, 예제 등을 작성하여 컴포넌트를 자세히 설명할 수 있습니다. 이를 통해 개발자들 간의 커뮤니케이션을 원활하게 하고, 다른 개발자들이 컴포넌트를 쉽게 이해하고 활용할 수 있습니다.

단점:

1. 학습 곡선과 초기 설정: Storybook은 초보자에게는 학습 곡선이 상대적으로 높을 수 있습니다. 초기 설정이 필요하며, 프로젝트에 맞게 Storybook을 구성하는데 시간과 노력이 필요할 수 있습니다. 하지만 한번 설정해두면 개발 생산성 향상과 유지 보수 측면에서 큰 이점을 얻을 수 있습니다.

2. 프로젝트 규모에 따른 복잡성:

대규모 프로젝트에서 Storybook을 사용하는 경우에는 몇 가지 복잡성이 발생할 수 있습니다.

a) 구성 및 관리의 어려움: 대규모 프로젝트에서는 수많은 컴포넌트와 스토리가 존재하게 됩니다. 이들을 구성하고 관리하는 것은 복잡성을 증가시킬 수 있습니다. Storybook은 컴포넌트를 스토리 단위로 구성하므로, 스토리의 수가 많아질수록 관리가 어려워질 수 있습니다. 따라서 적절한 네임스페이스, 그룹화, 태그 등을 사용하여 컴포넌트 및 스토리를 조직화하는 것이 필요합니다.

b) 성능 문제: Storybook 환경에서 많은 수의 컴포넌트와 스토리를 처리하고 렌더링하는 과정에서 성능 문제가 발생할 수 있습니다. Storybook은 개발자들이 컴포넌트를 빠르게 테스트하고 시각적으로 확인하기 위한 도구이지만, 대규모 프로젝트에서는 렌더링 속도가 저하될 수 있습니다. 이를 해결하기 위해 코드 스플리팅, 레이지 로딩 등의 최적화 기술을 활용하여 필요한 컴포넌트와 스토리만 로드하도록 구성할 수 있습니다.

c) 협업과 일관성 유지: 대규모 프로젝트에서는 여러 개발자와 디자이너가 동시에 Storybook을 사용하게 됩니다. 이는 일관성을 유지하기 위한 협업과 커뮤니케이션의 중요성을 높입니다. Storybook을 사용하는 동안 일관성을 유지하기 위해 문서화, 스타일 가이드, 컴포넌트 재사용 등의 도구와 규칙을 도입하여 통일된 개발 접근 방식을 유지할 필요가 있습니다. 이는 초기 설정과 유지보수에 추가적인 노력을 요구할 수 있습니다.

예시

// Button.js

import React from 'react';

const Button = ({ label, onClick }) => {
  return (
    <button onClick={onClick}>{label}</button>
  );
};

export default Button;

// Button.stories.js

import React from 'react';
import { storiesOf } from '@storybook/react';
import Button from './Button';

// 스토리 추가
storiesOf('Button', module)
  .add('Default', () => (
    <Button label="Click me" onClick={() => alert('Button clicked!')} />
  ))
  .add('Disabled', () => (
    <Button label="Click me" onClick={() => alert('Button clicked!')} disabled />
  ));

위의 예제에서는 Button 컴포넌트를 정의하고, Button.stories.js 파일에서 해당 컴포넌트의 스토리를 추가했습니다.

이제 Storybook을 실행하면 Button 컴포넌트의 스토리가 시각적으로 확인되고 테스트할 수 있습니다. 또한, 스토리에 대한 문서화를 추가로 작성할 수 있습니다. 이를 통해 다른 개발자들은 Button 컴포넌트를 이해하고 활용할 수 있게 됩니다.

이 예제는 간단한 버튼 컴포넌트를 다루었지만, 실제 프로젝트에서는 더 복잡한 컴포넌트와 다양한 스토리를 작성할 수 있습니다. Storybook을 사용하면 컴포넌트의 다양한 상태와 상황에서의 시각적인 확인과 테스트를 효과적으로 수행할 수 있습니다.

*: 시스템을 모델로 표현해주는 대표적인 모델링 언어 *

Purpose.

1. 의사소통 또는 설계 논의를 위해
2. 전체 시스템의 구조 및 클래스의 의존성 파악을 위해
3. 유지보수를 위한 설계의 back-end 문서 제작을 위해

Kind

• Structure Diagram 클래스 다이어그램, 객체 다이어그램, 복합체 구조 다이어그램, 배치 다이어그램, 컴포넌트 다이어그램, 패키지 다이어그램

• Behavior Diagram 활동 다이어그램, 상태 머신 다이어그램, 유즈 케이스 다이어그램, 상호작용 다이어그램

Class Diagram

보편적인 시스템의 정적인 면을 보여주는 대표적인 UML 구조 다이어그램으로 시스템을 구성하는 클래스들 사이의 관계를 표현합니다.

Class : 객체 지향 프로그래밍(OOP)에서 특정 객체를 생성하기 위해 변수와 메소드를 정의하는 일종의 틀(template)이다. 객체를 정의하기 위한 메소드와 변수로 구성된다. - Wikipedia
변화의 기본단위 디자인 패턴을 제대로 이해하기 위해 프로그램을 보고 어떤것이 변화하는지 잘 살펴보아야합니다.

Purpose.

1. 문제 해결을 위한 도메인 구조를 나타내어 보이지 않는 도메인 안의 개념과 같은 추상적인 개념을 기술하기 위해
2. 소프트웨어의 설계 혹은 완성된 소프트웨어의 구현 설명을 위해

Expression

속성과 연산의 가시화를 정의

• 접근자를 사용해 나타냅니다.

분석 단계와 설계 단계의 클래스 다이어그램

Relationship

UML에서 클래스 사이의 관계를 나타내는 방법은 다음과 같다.

Reference. https://sabarada.tistory.com/72 https://gmlwjd9405.github.io/2018/07/04/class-diagram.html https://ko.wikipedia.org/wiki/%ED%81%B4%EB%9E%98%EC%8A%A4_(%EC%BB%B4%ED%93%A8%ED%84%B0_%ED%94%84%EB%A1%9C%EA%B7%B8%EB%9E%98%EB%B0%8D)

: Hoist(:끌어 올리다) 에서 비롯된 용어로 인터프리터가 변수와 함수의 메모리 공간을 선언 전에 미리 할당하는 것 뜻합니다.

인터프리터 프로그래밍 언어의 소스 코드를 바로 실행하는 컴퓨터 프로그램 또는 환경을 말한다.

var 키워드로 선언한 변수의 경우 호이스팅 시 undefined로 변수를 초기화합니다. 반면 let과 const로 선언한 변수의 경우는 초기화하지 않습니다.

JavaScript는 함수의 코드를 실행하기 전에 함수 선언에 대한 메모리부터 할당합니다. (= 호이스팅합니다) 덕분에 함수를 호출하는 코드를 함수 선언보다 앞서 배치할 수 있습니다.

함수 호이스팅

함수 호이스팅은 내부적으로 다른 무엇보다 가장 먼저 이루어집니다. 그리고 함수 호이스팅은 함수 선언문에만 해당됩니다.

함수의 선언문은 식별자가 변수 객체에 수집될 때 부가적으로 해당 함수 참조에 대한 초기화까지 자동으로 이루어집니다. 이로 인하여 선언된 함수는 상단에서 참조, 호출이 가능합니다.

함수 표현식은? 함수 표현식은 결국 함수를 변수에 할당하는 것이므로 변수 호이스팅의 사례로 볼 수 있습니다.

변수 호이스팅

변수는 프로그램 내에서 크게 세 가지 단계를 거칩니다.

1. 선언: 파싱 과정에서 변수 객체가 변수에 대한 식별자들을 수집합니다.
2. 초기화: 식별자에 메모리를 할당하고 초기 상태로undefined를 부여합니다.
3. 할당: 변수 안에 직접 값을 넘겨 줍니다.

함수 호이스팅에서 그랬듯이 변수 또한 선언과 초기화를 해주어야만 값의 참조 및 할당이 가능합니다. 다만 변수 선언 방식(키워드)에 따라 선언, 초기화의 시점이 달라질 가능성이 있습니다.

• var: 호이스팅이 발생하면 선언과 초기화가 거의 동시에 이루어집니다. 해당 변수에 대한 메모리가 실행 시점의 스코프 최상단에 존재하기 때문에 선언부 위치에 상관없이 참조, 할당이 가능합니다.

• let, const: 호이스팅이 발생하면 선언만 이루어지고 실행 지점에서 실질적인 선언부를 만날 때까지 초기화가 이루어지지 않습니다. 이 간극만큼 해당 변수에 대한 메모리가 존재하지 않기에 선언부 상단에서 참조, 할당이 불가능합니다.

let, const가 동작하는 과정에서 스코프의 진입지점과 해당 식별자의 실질적 선언부 사이를 일시적 사각지대, TDZ(Temporal Dead Zone) 라고 합니다. 이 시점에서 변수는 존재하지만, 초기화가 이루어지지 않았습니다.

예제

// 1번 코드
function myName(name) {
  console.log("제 이름은 " + name + "입니다");
}

myName("허정우");

// 2번 코드
myName("허정우");

function myName(name) {
  console.log("제 이름은 " + name + "입니다");
}

// 결과: 제 이름은 허정우입니다

1번 코드와 2번 코드는 함수 호출과 선언의 시점이 다르지만 같은 방식으로 동작하는 것을 볼 수 있습니다.

함수 호출이 함수 자체보다 앞서 존재하여도 코드가 동작합니다. 이것이 JavaScript에서 실행 맥락이 동작하는 방식입니다.

호이스팅은 다른 자료형과 변수에도 작동합니다. 변수를 선언하기 전에 먼저 초기화하고 사용할 수 있는 것입니다.

대상

JavaScript는 초기화를 제외한 선언만 호이스팅합니다. 변수를먼저 사용하고 그 후에 선언 및 초기화가 나타나면, 사용하는 시점의 변수는 기본 초기화 상태입니다.

console.log(num); 출력
var num; // 선언
num = 10; // 초기화
// 호이스팅한 var선언으로 인해 undefined 

console.log(num);
num = 10; // 초기화
// 선언이 없고 초기화만 존재, 호이스팅 X
// 변수 읽기 시도 -> ReferenceError 예외 발생

Reference. MDN 호이스팅의 오해와 진실

그런 고민을 하던 중에 기술 스택을 학습하고 사용하는데 있어 어떤 장점을 지니고 있는지, 왜 사용하는지 아는 것이 중요하다고 생각이 들었습니다.

그래서 준비한 이번 블로깅의 주제는 '왜 리액트를 사용하는가?' 입니다.

React를 사용하는 이유

1. 컴포넌트 기반 화면구성

UI를 구성하는 뷰 단위로서, 하나의 요소가 아닌 블록의 역할을 합니다. 따라서 컴포넌트를 작성하고 조합을 통해 페이지를 구성하고, 다른 페이지에서 재사용하는 작업에 편리합니다.

또한, 이러한 장점들로 인해 유지 보수에 친화적이기도 합니다.

2. JSX 구문

JSX는 자바스크립트의 확장 문법으로 HTML과 JS를 결합해놓은듯한 형태로 XML과 비슷하게 생겼습니다. JSX 코드는 브라우저에서 실행되기 이전에 Babel을 사용하여 JS 형태로 변환됩니다.

이러한 JSX의 장점으로는 다음과 같습니다.

• 가독성이 좋고 익숙하다.
• 활용도가 높다
  • JSX는 HTML요소 뿐만 아니라, 컴포넌트도 작성이 가능합니다.

3. Virtual DOM

유저의 인터랙션이 상태 변화를 일으키면 브라우저 작동원리에 따라 랜더링 과정이 반복되는 리랜더링 현상이 발생합니다.

Vitual DOM은 말그대로 가상 DOM으로서, 실제 DOM에 적용되기 전에 랜더링 과정이 없는 가상 DOM에서 연산을 거친 뒤에 실제 DOM에 적용시킵니다.

또한, Virtual DOM은 Diff 알고리즘을 통해 업데이트 전 Virtual DOM의 스냅샷과 비교하여 정확히 어떤 Virtual DOM이 바뀌었는지 파악하여 필요한 DOM 트리만 업데이트할 수 있게 해줍니다.

이러한 과정을 재조정이라고 합니다.

이 접근방식이 React의 선언적 API를 가능하게 합니다. React에게 원하는 UI의 상태를 알려주면 DOM이 그 상태와 일치하도록 합니다. 이러한 방식은 앱 구축에 사용해야 하는 어트리뷰트 조작, 이벤트 처리, 수동 DOM 업데이트를 추상화합니다.

4. 넓은 생태계

다양한 라이브러리를 사용할 수 있으며, 활발한 지식 공유가 이루어지고, 기술의 지원 또한 안정적입니다.

5. 앱 개발

약간의 문법 차이가 존재하지만 거의 비슷한 문법을 지닌 React Native를 활용하여 앱 개발이 가능합니다.

Reference. FE 인터뷰 Github VELOPERT

변수선언과 타입지정

변수 선언 시 타입지정이 가능합니다.

타입을 지정해놓으면 값이 의도치 않게 변경될 경우 에러메세지를 띄워줍니다.

let name :string = 'kim'; // 문자열만 받음
let age :number = 25; // 숫자만 받음

// array 혹은 object
let name :string[] = ['kim', 'park'] // 문자열 요소인 배열만 받음
let age :{ age : number } = { age : number } // age에 대한 값에 숫자만 받음

타입으로 쓸 수 있는 것들

string, number, boolean, bigint, null, undefined, [], {} 등이 있습니다.

let name :string | number = 'kim'  // 문자열, 숫자 둘 다 받을 수 있음

한 변수에 여러가지 타입의 데이터가 들어올 수 있다면 | 기호를 이용해 or 연산자를 표현할 수 있습니다.

type nameType = string | number;
let name :nameType = 'kim';

type 키워드

type 키워드를 이용해 타입을 변수처럼 담아서 사용할 수 있습니다.

type NameType = 'kim' | 'park';
let name :NameType = 'kim';

literal type (나만의 타입)

원하는 글자나 숫자를 입력하면, name 이라는 변수엔 앞으로 'kim' 또는 'park'만 들어올 수 있습니다.

function Func1(x :number) :number {
  return x * 2
}

함수는 파라미터와 return 값에 타입지정이 가능합니다. 실수로 다른 타입이 파라미터로 들어오거나 return될 경우 에러를 발생시킵니다.

type Member = [number, boolean];
let john:Member = [100, false];

tuple array 자료 안에 순서를 포함한 타입지정을 하고 싶으면 tuple 타입을 사용할 수 있습니다. [ ] 안에 들어올 자료의 타입을 순서대로 적으면 됩니다.

type MyObject = {
  name? : string,
  age : number
}
let 철수 :MyObject = { 
  name : 'kim',
  age : 50
}

object 타입도 정의가 너무 길다면 type 키워드로 변수에 담아 사용이 가능합니다. 특정 속성이 선택사항이라면 물음표를 기입할 수 있습니다.

만약 object 안에 어떤 속성이 들어갈지 아직 모른다면,

type MyObject = {
  [key :string] : number,
}

이렇게 모든 키에 대한 타입지정이 가능합니다. 이런 방식을 index signature 이라고 합니다.

class Person {
  name;
  constructor(name :string){
    this.name = name;
  }
}

class에도 타입지정이 가능합니다. 다만, 중괄호 내에 미리 변수를 만들어놔야 생성자 안에서 this.name 처럼 사용이 가능합니다.

모든 프로그래밍 언어에는 내장된 자료구조가 존재하지만 보통 그 내용은 언어마다 다릅니다. 그중 JavaScript는 느슨한(loosely typed)타입의 의 동적(dynamic) 언어입니다. JavaScript의 변수는 어떤 특정 타입과 연결되지 않으며, 모든 타입의 값으로 할당 (및 재할당) 가능합니다.

JS 데이터 타입의 종류

JavaScript의 데이터 타입은 원시 값과 객체로 나뉘어집니다.

• 원시

  • Boolean
  • Null
  • Undefiend
  • Number
  • BigInt
  • String
  • Symbol

• 객체

Symbol 타입 🤔

"심볼" 데이터 형식은 값으로 익명의 객체 속성(object property)을 만들 수 있는 특성을 가진 원시 데이터 형식(primitive data type)입니다. 이 데이터 형식은 클래스나 객체 형식(object type)의 내부에서만 접근할 수 있도록 전용(private) 객체 속성의 키(key)로 사용됩니다. 심볼 데이터 형식은 고도로 특화된 용도로 쓰이며, 범용성은 현저히 떨어집니다

데이터 타입의 필요성

데이터 저장 관점

효율적인 메모리 관리를 위해 필요합니다.

const num = 10;

이런식으로 우리가 10이라는 숫자를 변수에 담으면, JavaSciprt는 내부적으로 숫자 10이라는 값을 할당하기 위해 메모리 공간(Number = 8 byte)을 확보하고, 그 공간을 num이라는 이름을 붙여줍니다. 그리고 num에는 2진수의 형태로 숫자 10이 저장됩니다. 우리가 변수에 할당하려는 값의 '데이터 타입'에 따라 확보해야 할 메모리 공간의 크기가 결정됩니다. 이처럼 어떤 데이터를 저장하는 과정에서 얼마의 메모리 공간을 확보할 것인지 알기 위해 데이터 타입이 필요합니다.

값을 참조할 때 한 번에 읽어 들일 메모리 공간의 크기를 알기 위해 필요합니다.

num변수의 경우, 저장되어 있는 값이 number 타입이므로 8바이트 단위로 읽지 않으면 원하는 값을 얻어낼 수 없습니다. 이렇듯 JavaScript는 변수의 저장된 데이터를 참조할 때 얼만큼의 공간을 읽어 들일지 알기 위해 데이터 타입이 필요하다고 말할 수 있습니다.

정확한 데이터 해석을 위해 필요합니다.

만약 메모리에서 읽어들인 2진수를 0100 0001이라고 한다면, 이는 숫자 65일 수도 있고, 문자 'A'일 수도 있습니다. 이는 JavaScirpt가 해석하는 기준에 따라 달라지는데 JavaScript는 데이터 타입을 확인하여 숫자읹, 문자열인지 해석하여 원하는 값을 얻어내도록 합니다.

정적 타이핑 vs 동적 타이핑

정적 타이핑은 프로그래밍의 어르신인 C언어를 에로 들수 있습니다. C언어에서는 변수를 선언할 때에 타입을 선언해줘야합니다.

int num = 20010314; // 정수
float num = 2001.0314; // 실수
char str = 'birthday'; // 문자

하지만 우리가 쓰는 JavaScript는 동적 타입의 언어라고 언급했습니다. 타입을 명시해주지 않아도 JavaScript 엔진이 알아서 할당해주기 때문에 편리하다는 장점이 있습니다.

하지만 너무나 자유롭기 때문에 타입이 의도치않게 자기 멋대로 변경되는 경우가 생기기도 합니다. 이러한 결점은 규모가 큰 프로젝트에서 심각한 에러로 발전될 확률이 높습니다. 이런 에러를 예방하고자 규모가 큰 프로젝트, 여러 회사에서 TypeScript를 적극 사용하고 있습니다.

타입 변환과 단축 평가

묵시적 타입변환

JavaScript는 특정 타입의 값을 기대하는 곳에 다른 타입의 값이 오면 자동으로 타입을 변환시킵니다.

const a = "10";
const b = "20";
const result = a + b;
console.log(result);    // 1020

result = a - b;
console.log(result);    // -10

result = a * b;
console.log(result);    // 200

const c = "문자";
result = c - a;        // NaN

명시적 타입변환

위의 예시에서 만약 a + b를 숫자로 계산하고 싶다면 어떻게 할까요? 그럴때 사용하는 것이 명시적 타입변환입니다.

대표적으로 명시적 타입변환 메소드인 Number(), String() 등이 그렇습니다.

const result = Number(a) + Number(b)

이런식으로 인자에 대한 타입을 명시적으로 변환시켜 계산하게 됩니다.

단축 평가

논리합, 논리곱 연산자를 이용한 표현식은 언제나 truthy, falsy 값 중 하나로 판별됩니다. JavaScript에선 이 표현식을 수행하던중 어느 한쪽이 확실해졌을 때, 더 이상 표현식을 계산하지 않고 바로 확실해진 값을 반환해줍니다.

Reference. 데이터 타입 데이터 타입의 필요성 정적 타이핑, 동적 타이핑 JavaSciprt 타입 변환 JS 단축평가

정식 명칭은 Flexible Box module이지만 Flex, Flexible Box, Flexbox 라고 부르기도 합니다. Flex는 flexbox 인터페이스 내의 아이템 간 공간 배분 과 강력한 정렬 기능을 제공하기 위해 1차원 레이아웃 모델로 설계 되었습니다.

flex를 1차원이라 칭하는 것은, 레이아웃을 다룰 때 한 번에 하나의 차원(행이나 열)만을 다룬다는 의미입니다.

Flex는 두 개의 축으로 다룹니다.

먼저, 주축과 교차축이라는 두 개의 축에 대한 정의를 알아보겠습니다. flex를 잘 다루기 위해선 이 두 개의 축이 어떻게 동작하는지 처음부터 이해하는 것이 중요합니다.

주축

주축은 flex-direction 속성에 의해 지정되며 4개의 값을 가질 수 있습니다.

• row
• row-reverse
• column
• column-reverse

row 혹은 row-reverse를 부여하면 주축은 인라인 방향으로 행을 따르게 됩니다. column 혹은 column-reverse을 부여하면 주축은 페이지 상단에서 하단으로 블록 방향을 따릅니다.

교차축

교차축은 주축의 수직으로 지정됩니다. 만약 주축이 row 혹은 row-reverse 라면 교차축은 열 방향을 따르게 됩니다.

주축이 column 혹은 column-reverse 라면 교차축은 행 방향을 따르게 됩니다.

위에서 flex는 강력한 정렬 기능을 제공한다고 말씀드렸습니다. flex로 아이템들을 정렬하고 끝을 맞추려면(justify) 어느 축이 어느 방향인지 이해하는 것이 중요합니다.

flex는 주측, 교차축을 따라 항목을 정렬하고 끝을 맞추는 각종 속성들을 적용하는 방식으로 동작합니다.

시작점과 끝점

flex에는 시작점(flex-start)과 끝점(flex-end)이라는 개념이 존재합니다. 이는 두 축의 시작하는 지점과 끝나는 지점을 말하며 방향에 따라 시작점과 끝점이 달라집니다.

줄 바꿈

기본적으로 아이템은 한 줄로만 표시되고 줄 바꿈 되지 않습니다. 따라서 아이템을 줄 바꿈 하려면 flex-wrap 속성을 사용하여야 합니다.

flex-wrap 속성 값

값	설명
nowrap	모든 Item을 한 줄에 표시
wrap	Items을 여러 줄로 묶음
wrap-revers	여러 줄로, wrap의 반대방향으로 묶음

정렬

주축의 정렬 방법

주축은 justify-content 속성을 사용하여 정렬 방법을 지정합니다.

justify-content 속성 값

값	설명
flex-start	Items를 시작점(flex-start)으로 정렬
flex-end	Items를 끝점(flex-end)으로 정렬
center	Items를 가운데 정렬
space-between	시작 Item은 시작점에, 마지막 Item은 끝점에 정렬되고 나머지 Items는 사이에 고르게 정렬됨
space-around	Items를 균등한 여백을 포함하여 정렬됨

교차축의 정렬 방법

교차축은 상황에 따라 align-content 속성과, align-items 속성을 통해 정렬 방법을 지정합니다.

align-content 정렬

align-itmes 정렬

CSS Grid

Grid는 2차원의 레이아웃 시스템을 제공합니다. 위에서 배운 1차원 레이아웃 시스템인 flex도 훌룡하지만, 조금 더 복잡한 레이아웃을 위해 Grid를 사용할 수 있습니다.

Grid Properties

Grid는 Flex와 같이 Container와 Item이라는 두 가지 개념으로 구분되어 있습니다. Container는 Item을 감싸는 부모 요소이며, 그 안에서 각 Item을 배치할 수 있습니다.

Grid Container Properties

Gird Container를 위한 속성은 다음과 같습니다.

Grid Item Properties

Grid Item을 위한 속성들은 다음과 같습니다.

Grid 예시

.container {
  display: grid;
  grid-template-rows: repeat(3, 100px);
  grid-template-columns: repeat(3, 1fr);
  grid-template-areas:
    "header header header"
    "main main aside"
    "footer footer footer";
}
header { grid-area: header; }
main   { grid-area: main;   }
aside  { grid-area: aside;  }
footer { grid-area: footer; }

그럼 언제 Flex와 Grid를 사용하나요?

“플랙스박스는 좀 더 콘텐츠에 초점이 맞춰져 있습니다. 플랙스박스의 이상적인 사용 사례는 여러 아이템을 컨테이너에 고르게 배치하려는 경우입니다. 여기서 콘텐츠의 크기가 각 아이템이 차지하는 공간을 결정합니다. 아이템이 새로운 줄로 줄 바꿈 되면, 아이템의 크기와 해당 줄의 사용 가능한 공간에 따라 간격이 조정됩니다. 그리드는 레이아웃을 먼저 고려하게 됩니다. CSS 그리드 레이아웃을 사용할 때는 우선 레이아웃을 작성한 다음 그 위에 아이템을 배치하거나, 자동 배치 규칙을 통해 견고하게 짜인 그리드 위에 놓인 그리드 셀에 아이템을 배치하게 됩니다.” -MDM

위의 말을 한마디로 정리를 해보자면, flex는 콘텐츠 위주의 정렬에 적합하고, grid는 레이아웃 위주의 정렬에 적합합니다.

Reference. MDN heropy's blog flex와 grid 차이점

나 열심히 했어

절거웠다

난이도와 별개로 재미있는 일이 가장 많았던 섹션이었다.

처음으로 가본 개발 컨퍼런스에서 동기분들과 직접 마주하고 재밌는 시간을 가지기도 했고,

저번주 토요일부터 진행된 5일동안 새벽까지, 밤을 새며 쳐낸 프로젝트 경험도 쌓았다. 그 외에도 재미있는 페어와 그룹원 분들, 스터디 분들 덕분에 가장 재미있다고 느낀 섹션이 아닐까 싶다.

아무튼 해냈어

아무리 어려운 내용이 있어도 나는 해냈어 아무리 어려운 내용이 있어도 나는 해냈어 아무리 어려운 내용이 있어도 나는 해냈어

이제 프로젝트 기간인데 뭐 대수 있겠어요?

지금처럼만 쭉 가면 메인 프로젝트도, 취업도 금방입니다~ 사랑해요 40기 동기분들

S3 D3 M1 F3

• 달달함과 높은 도수, 두마리 토끼를 동시에!
• 소설이나 영화 같은 창작물에 영향을 잘 받는 당신!
• 수 많은 바리에이션이 있어 다양하게 즐길 수 있답니다.

다이키리와 관련된 재미있는 이야기는?

노인과 바다로 유명한 세계적인 작가 어니스트 헤밍웨이가 사랑한 두가지 칵테일 중 하나입니다. ’나의 모히토는 라 보데기타에서, 나의 다이키리는 엘 플로리디타에서.(My mojito in La Bodeguita, my daiquiri in El Floridita.)’ 라는 문구로도 유명하지만, 훗날 위 문구는 위조 문구로 판명나게 되었다는 사실. 재미있지 않나요?

하이볼

S3 L3 M1 T3

• 탄산이 가져다주는 시원한 쳥량감과 레몬, 라임의 상쾌함!
• 이름의 유래만큼 빠르고 현실적인 당신에게 어울립니다.
• 대중적인 칵테일로, 어느 술집에서든 찾을 수 있어요!

하이볼과 관련된 재미있는 이야기는?

하이볼이란 이름의 유래는 예전에 정차된 증기기관차가 출발할 때 신호에 맞춰 출발했는데, 이때 기관사들이 '하이볼'이라고 외쳤습니다. 이에 '하이볼'이라는 의미는 빠르고 신속하게 혹은 무엇인가를 분주히 준비해야 될 때라는 의미로 사용되었는데, 다른 칵테일에 비해서 빠르게 서빙되는 이 칵테일의 특성이 이와 맞아떨어져 기차 식당칸에서 일하던 바텐더들 사이에서 슬랭으로 쓰였다고 합니다. 또한 증기기관차에서 속력과 압력을 나타내는 게이지가 공의 높낮이로 보였는데, 최대 속력일 때 공이 높이 떠 있어 이게 긴 잔에 떠있는 얼음의 모습과 유사하다고 해서 하이볼이라고 쓰였다고도 해요.

잭콕

S1 L3 M3 T2

• 스모키하고 씁스름한 향에 달달한 끝맛!
• 칵테일 중 상대적으로 도수가 낮아 부담없이 즐길 수 있어요.
• 콜라가 주는 탄산의 청량감도 빠질 수 없답니다.

잭콕과 관련된 재미있는 이야기는?

바로 잭 다니엘 증류소의 2인자인 Chris Fletcher는 자기네들끼리 말하는 농담 중에 "잭 다니엘 증류소와 코카콜라 본사가 차량으로 3시간 거리이다 보니 서로 한번 섞어 마셔본 것이 아닐까?"라는 유래에 대한 이야기인데요, 당신은 여러 음료를 섞어 마셨던 기억이 있으신가요?

소맥

B2 L3 C2 T1

• 익숙한게 최고야!
• 눈 앞에서 화려하게 소맥을 말아주는 퍼포먼스를 뽐낼 수 있어요!
• 들어가는 술의 종류와 비율에 따라 다양한 맛과 향을 낼 수 있답니다.

소맥과 관련된 재미있는 이야기는?

1980년 언론통폐합 당시 폐지된 언론사의 언론인들이 소맥을 만들어서 '통폐합주'라고 이름짓고 마셨고 이것이 지금 마시는 소맥의 기원이 되었다고 보는 설이 일반적입니다. 이 당시 언론사 분위기는 어차피 없어지는 직장이니 임원실에 숨겨놨던 양주도 따서 근무중에 마셨다고 해요. 처음엔 양주+맥주의 조합으로 먹다가 양주를 구하기 어려우니 구하기 쉽고 싼 소주로 대체한 것이 지금까지 내려오게 됐답니다. 보도국이 날아갔던 CBS의 경우 아예 뉴스필름으로도 남아있다고 해요.

75일차

알고리즘

75일차에 배운 것 정리.

• 빅오표기법
• 알고리즘 유형

75일차에 어떤 어려움을 겪었는지.

효율적인 문제 해결을 위한 데이터 가공이 서툴러서 더 복잡한 코드를 작성했었다. 더 복잡한 코드를 작성하려니 시간이 오래걸렸고 이로 인해 베어미니멈 문제는 전부 풀었지만 마지막 어드밴스드 문제는 풀지 못했다.

75일차 느낀점.

매번 풀고 느끼는 점이지만 데이터 가공을 잘하면 깔끔하고 효율적인 코드를 작성할 수 있다. 아직 서투르지만 점점 익숙해지는 과정일지도?!

오늘의 영어 공부.

• drive: (차량을) 몰다, 운전하다. Can you drive? 운전 할 수 있니?

• depart: (특히 여행을) 떠나다[출발하다] Flights for Rome depart from Terminal 3. 로마행 비행기는 3번 터미널에서 출발한다.

• analyze: 분석하다 The job involves gathering and analysing data. 그 일에는 데이터를 수집하고 분석하는 일이 포함된다.

• grasping: 욕심 많은 a grasping landlord 욕심 많은 집주인

• profoundly: (영향 등을) 깊이 We are profoundly affected by what happens to us in childhood. 우리는 어릴 적 우리에게 일어나는 일의 영향을 깊이 받는다.

1. 1 프로세스 (Process)

프로세스는 컴퓨터에서 연속적으로 실행되고 있는 컴퓨터 프로그램을 말한다. 종종 스케줄링의 대상이 되는 작업(task)이라는 용어와 거의 같은 의미로 쓰인다. -Wikipedia

여러 개의 프로세서를 사용하는 것을 멀티프로세싱이라고 하며 동시에 여러 개의 프로그램을 띄우는 시분할 방식을 멀티태스킹이라고 합니다.

1. 1. 1 🤔 그럼 프로세스와 프로그램은 같은 것인가요?

아닙니다. 프로그램은 일반적으로 메모리에 저장되어있는 소스코드 자체를 의미하며, 프로세스는 해당 프로그램을 실행하여 메모리 상에서 실행되는 작업 단위를 말합니다.

예를 들어 구글 Chrome을 여러 번 켰을 때, 우리는 하나의 프로그램을 실행한 것이지만 여러 개의 프로세스가 나타나는 것을 확인 할 수 있습니다.

1. 1. 2 프로세스의 상태

프로세스의 상태는 커널이라는 OS의 핵심이 되는 프로그램으로 준비 큐, 대기 큐, 실행 큐 등의 자료 구조를 이용하여 관리합니다.

• 생성(create) : 프로세스가 생성되는 상태입니다.

• 실행(running) : 프로세스가 CPU를 차지하여 명령어들이 실행되고 있는 상태입니다.

• 준비(ready) : 프로세스가 CPU를 사용하고 있진 않지만 언제든지 사용할 수 있는 상태며, CPU가 할당되기를 기다리고 있습니다.

• 대기(wating) : 보류(block)라고 불리기도 하며, 프로세스가 입출력 완료되고 신호 수신 등 어떤 사건을 기다리고 있는 상태입니다.

• 종료(terminated) : 프로세스의 실행이 종료된 상태입니다.

1.1.3 프로세스의 상태전이

하나의 프로그램이 실행되면, 그 프로그램에 대응되는 프로세스가 생성되어 준비 리스트의 끝에 들어가게 됩니다.

이때 우선순위를 부여하여 가장 높은 우선순위를 가진 프로세스가 다음 순서에 CPU 할당을 받게 됩니다.

• 디스패치(dispatch) 가장 높은 우선순위를 가진 프로세스가 CPU 할당을 받아 점유하게 되는 것. 준비 상태에서 실행 상태로 바뀌는 것을 의미합니다.

• 보류(block) 실행중인 프로세스에서 입출력 동작을 요구할 경우 CPU는 입출력 관리자에게 작업을 맡기고 프로세스를 대기 상태로 만듭니다. 이때 해당 프로세스는 CPU 점유를 반납하게 됩니다.

• 깨움(wakeup) 입출력 작업 종료같은 보류의 원인이 끝났을 때, 대기 상태에서 다시 준비 상태로 넘어가는 것을 의미합니다.

• 시간제한(timeout) OS는 효율적인 자원 관리를 위해 프로세스가 계속해서 독점 사용하는 것을 막기 위해 clock interrupt를 두어서 일정 시간동안만 프로세서를 점유할 수 있게 합니다.

1. 2 스레드(Thread)

*스레드(thread)는 어떠한 프로그램 내에서, 특히 프로세스 내에서 실행되는 흐름의 단위를 말한다. * - Wikipedia

일반적으로 한 프로그램은 한 개의 스레드를 가지고 있지만, 프로그램 환경에 따라 둘 이상의 스레드를 동시에 실행할 수 있습니다. 이러한 실행 방식을 멀티스레드라고 합니다. 또한 각각의 스레드는 독립작인 작업을 수행하기 위해 고유한 ID, 프로그램 카운터, 레지스터, 집합, 스택 등을 가지고 있습니다.

1. 2. 1 🤔 프로그램? 프로세스? 스레드?

정리하자면 프로그램을 실행한 작업의 단위를 프로세스라고 부르며, 프로세스 내에서 실행되는 여러 흐름의 단위를 스레드라고 합니다.

스레드는 프로세스에 종속되어 있다고 말할 수 있습니다.

1. 2. 2 싱글 스레드와 멀티 스레드

싱글 스레드

싱글 스레드는 하나의 프로세스에서 오직 하나의 스레드로만 실행되는 방식입니다. 따라서 하나의 레지스터와 스택으로 표현이 가능합니다.

👍 싱글 스레드의 장점

1. 문맥(작업) 교환 작업을 요구하지 않습니다. 문맥 교환은 여러 개의 프로세스가 하나의 프로세서를 공유할 때 발생하는 작업으로 많은 비용을 필요로 합니다.

2. 자원 접근에 대한 동기화에 자유롭습니다 멀티 스레드의 경우 프로세스의 자원을 공유하기 때문에 각 스레드가 원하는 결과를 얻기 위해서 자원에 대한 접근을 제어해야합니다.
   예를 들어 두 개 이상의 스레드가 동시에 같은 자원에 접근하려고 한다면 에러가 발생하거나 원치않는 결과를 초래할 수 있습니다. 따라서, 이런 현상이 방지하지 않도록 제어해주어야만 합니다.

👎 싱글 스레드의 단점

1. 여러 개의 CPU를 활용하지 못합니다.

2. 연산량이 많은 작업의 경우 딜레이가 발생할 수 있습니다. 오래 걸리는 작업을 수행하는 경우 해당 작업이 완료되어야만 다음 작업을 수행할 수 있게 됩니다. 이 현상이 누적되면 딜레이되는 시간은 계속해서 길어지게 됩니다.

멀티 스레드

멀티스레드는 문맥 교환(Context Switching)을 통해 이루어집니다. 여기서 문맥 교환은 CPU에서 여러 프로세스를 돌아가며 작업을 처리하는 과정을 말합니다. 위에서 말한 보류와 깨움으로 이루어진 일련의 작업입니다.

👍 멀티 스레드의 장점

• 시스템 자원의 소모가 감소합니다. 프로세스를 생성하여 자원을 할당하는 시스템 콜이 줄어들어 자원 관리에 효율적입니다.
• 시스템 처리 비용 감소 프로세스 내 각 스레드 간의 자원 공유가 간단해지며 스레드 간의 작업량도 줄어듭니다.

👎 멀티 스레드의 단점

• 주의 깊은 설계가 필요합니다. 멀티 스레드 모델은 싱글 스레드 모델에 비교해 설계하기 굉장히 까다롭습니다.
• 사용하는 스레드의 수만큼 자원을 많이 사용합니다.
• 스레드 스케줄링이 필요합니다. 공유 자원에 동시에 접근하는 경우 다른 스레드에서 사용 중인 엉뚱한 값에 사이드 이펙트를 초래할 수 있습니다. 따라서 스레드 스케줄링을 통해 동시에 접근하는 경우를 막아야합니다.

Reference. 위키피디아 - 스레드 위키피디아 - 프로세스 싱글스레드 vs 멀티스레드 프로세스와 스레드의 차이

74일차

Proxy

74일차에 배운 것 정리.

• webpack proxy
• http-proxy-middleware

74일차에 어떤 어려움을 겪었는지.

setupProxy 파일 설정하는 데 두 포트를 열어주는 설정에 대해 한참을 골머리 앓다가 단순히 use를 두번 적어주면 된다는 것을 보고 충격에 휩싸였다.

74일차 느낀점.

proxy 우회 자체는 많이 써본 기능이었지만 내부적으로 어떻게 작동이 되는지 궁금했던 적은 한번도 없었던 것 같다. 이렇듯이 무의식적으로 실생활에서 자주쓰이는 여러 기술들 한번 생각해보고 공부해보면 좋겠다라는 생각이 들었다.

오늘의 영어 공부.

• prowl: (특히 먹이를 찾아) 돌아다니다. The tiger prowled through the undergrowth. 그 호랑이는 관목 사이를 돌아다녔다.

• quarry: 채석장 a slate quarry 점판암 채석장

• brimful: ~이 넘치는[그득한] She’s certainly brimful of energy. 그녀는 정말 에너지가 넘친다.

• exterior: (특히 건물의) 외부[외면] The exterior of the house needs painting. 그 집은 외부에 페인트칠을 해야 한다.

• peculiarity: 기이한 특징, 특이한 점; 기벽 a physical peculiarity 신체적으로 특이한 점

73일차

CI/CD

73일차에 배운 것 정리.

• CI/CD의 개념
• Github Action

  73일차에 어떤 어려움을 겪었는지.

  오늘의 어려움은 없습니다 :D

73일차 느낀점.

YML 파일을 처음 보았을 때 어떻게 설정해야할지 조금 혼란스러웠지만 천천히 읽으면서 생각하고, 의심하고, 또 찾아보면서 곧 의심에서 확신이 될 수 있었다. 내가 생각하는 것만큼 어렵지는 않구나.

오늘의 영어 공부.

• crest: 산마루, 물마루

• adhere: 들러붙다, 부착되다

• extinct: 멸종된

• coalesce: (더 큰 덩어리로) 합치다

• microscopic: 미세한, 현미경으로 봐야만 보이는

72일차

AWS

72일차에 배운 것 정리.

• AWS 기초

  72일차에 어떤 어려움을 겪었는지.

  AWS를 처음 이용하다보니 백엔드 관련 용어나, 개념이 부족해서 어려움을 겪었다.

72일차 느낀점.

그냥 찍먹했다고 생각하고 프로젝트 진행 할 때에 다시 보며 공부해야겠다.

오늘의 영어 공부.

• niche: 아주 편한[꼭 맞는] 자리[역할/일 등]

• forced: 강제적인, 강요된

• entrust: (일을) 맡기다

• preamble: (책의) 서문; (말의) 서두

• comparative: (무엇에 대한 연구가) 비교를 통한

71일차

최적화

71일차에 배운 것 정리.

• 최적화 DOM, Lighthouse

  71일차에 어떤 어려움을 겪었는지.

  오늘의 어려움은 없습니다. :D

71일차 느낀점.

이미지 포맷에 따라 데이터 절감 차이가 정말 크다는 것을 오늘 체감했다. 앞으로 진행될 프로젝트에도 브라우저 호환에 맞추어 최적화 시켜봐야겠다.

오늘의 영어 공부.

• quash : (법원의 결정을) 파기[각하]하다 His conviction was later quashed by the Court of Appeal. 그의 유죄 판결은 뒤에 항소 법원에서 각하되었다.

• pallor : (얼굴 색깔이 특히 병으로) 창백함 Her cheeks had an unhealthy pallor. 그녀의 뺨은 건강이 안 좋은 듯 파리했다.

• glamour : (흔히 부와 신분에 따른) 화려함[매력] hopeful young actors and actresses dazzled by the glamour of Hollywood. 할리우드의 화려함에 현혹되어 기대에 부푼 젊은 남녀 배우들.

• admonish : 꾸짖다, 책망하다 She was admonished for chewing gum in class. 그녀는 수업 중에 껌을 씹다가 꾸지람을 들었다.

• engagement : 약혼; 약혼 (기간) Their engagement was announced in the local paper. 그들의 약혼은 지역 신문에 발표되었다.

컴퓨터 공학에서의 최적화는 간단하게 최소의 리소스와 최단시간으로 결과를 얻을 수 있도록 하는 것을 의미합니다.

Why?

최소의 리소스를 가지고 빠르게 로딩을 시켜주기 때문에 사용자가 로딩 상태에 오래 머물지 않게 됩니다. 이런 빠른 로딩은 사용자의 이탈률을 현저하게 낮추며 자연스럽게 전환율 증가로 이어지게 됩니다. 이렇게 이탈률을 낮추고 전환율을 높여 트래픽을 증가시키고 회원의 수도 늘어나게 되어 수익 증대의 효과까지 기대 할 수 있습니다.

How?

브라우저에 렌더링 하기 위해서는 HTML과 CSS파일이 필요합니다. 이 둘은 각자 DOM트리, CSSOM 트리를 만들고 이 두개의 트리를 결합하여 렌더링할 때 사용합니다. 이 두개의 트리중 하나만 변경이 되더라도 리렌더링을 유발하고 각 트리가 복잡할수록 리렌더링하는데 더 많은 비용이 소모됩니다. 따라서 HTML CSS 소스코드를 최적화함으로서 성능을 향상 시킬 수 있습니다.

HTML

1. DOM 다이어트

DOM트리의 복잡도를 낮추어야합니다. 방법으로는 불필요한 요소들을 줄이는 정도가 있습니다.

2. 인라인 스타일 지양하기

인라인 스타일을 사용하지 않아야합니다. 인라인 스타일은 코드 가독성을 저해시키는 동시에 코드를 더 길게 만들며 리플로우를 계속해서 발생시켜 렌더링 완료 시점을 늦추게 됩니다. 따라서 웹 표준에 맞게 CSS파일을 따로 만들어 설정을 해주거나, 다른 방법을 통해 스타일을 부여해야합니다.

CSS

1. CSSOM 다이어트

사용하지 않는 스타일 속성은 제거해야합니다. 보통 HTML에서 요소를 지우면서 해당 요소에 부여하던 CSS코드만 남게되는 경우가 많은데 이 또한 CSSOM 트리를 완성하는데 비용이 발생하게 됩니다.

2. 간결한 선택자 사용

최대한 간결한 선택자를 사용해야합니다. 선택자가 복잡할수록 스타일 계산과 레이아웃에 비용을 더 많이 소모하게 됩니다.

브라우저 이미지

페이지를 로딩할 때에 미디어 파일의 데이터가 해당 페이지의 용량 51%나 차지한다는 사실, 그래서 이미지의 용량을 줄이거나 요청하는 수를 줄여야합니다.

1. 이미지 스프라이트

이미지 스프라이트 방식은 여러개의 이미지를 모아 하나의 스프라이트 이미지로 만들어 한번의 요청으로 여러 이미지를 받아오는 방식입니다. 이렇게 받아온 하나의 이미지를 필요한 부분만 CSS 속성을 사용해 클래스로 구분하여 사용할 수 있습니다.

2. 아이콘 폰트 사용

아이콘 사용이 많아진다면 모든 아이콘을 이미지로 사용하는 것보다 아이콘 폰트를 사용하여 데이터 용량을 줄일 수 있습니다. 대표적인 아이콘 글꼴 서비스로는 Font Awesome이 있습니다.

3. Webp, AVIF 포맷 사용

기존 이미지 포맷인 JPEG, PNG 형식에서 새롭게 등장한 포맷으로, 용량을 감소시킬 수 있다는 장점이 있습니다. Webp, AVIF 포맷을 사용하면 기존 포맷을 사용할 때보다 20% ~ 50%의 용량을 절감할 수 있습니다. 신규 포맷은 이러한 장점을 지녔지만 단점 또한 지니고 있습니다. 브라우저 호환성이 낮아 호환이 되지 않는 브라우저를 사용한다면 이미지가 보이지 않습니다. 이럴 때 사용자의 브라우저 호환에 맞춰 이미지를 보여줄 수 있는 <picture> 태그가 있습니다.

<picture>: img 요소의 다중 이미지 리소스를 위한 컨테이너를 정의할 때 사용합니다.

<picture>
  <source srcset="sprite.webp" type="image/webp">
  <img src="sprite.png" alt="logo">
</picture>

이런식으로 <picture> 태그를 사용하여 작성했을 때, 사용자의 브라우저가 Webp 포맷을 지원하지 않는다면 <source> 태그는 무시되고, <img> 태그로 보여주어 브라우저 호환에 맞춘 이미지 최적화가 가능하게 됩니다.

Lighthouse

Lighthoust는 구글에서 개발한 오픈소스로 웹 페이지의 품질을 다양한 지표를 통하여 점수로 나타내주는 자동화 툴입니다.

각 지표에 따른 점수를 표시하고, 어떻게 하면 개선 할 수 있는지 방안까지 제시를 해주어 전반적인 웹 품질을 높일을 향상 시킬수 있습니다.

다음은 제가 백준 홈페이지의 메인화면을 Lighthouse를 통해 성능을 분석한 내용입니다.

성능 분야에서 좋지 않은 점수를 받은 내용은 컨텐츠를 포함한 최대 페인트 항목이었는데 자세히 보니 차세대 형식, 즉 위에서 언급했던 Webp, AVIF 포맷을 사용하지 않아서였습니다. 그 외에도 이미지 요소에 명시적인 너비 및 높이를 설정하여 레이아웃 변경 횟수를 줄이고 누적 레이아웃 변경을 개선 할 수 있는 부분도 존재했습니다.

또한 SEO 항목에서도 메타 설명이 누락된 점, 이미지에 alt 속성이 없는 점 등 검색엔진에 악영향을 미치는 요소가 존재했습니다.

Lighthouse 분석 후기

평소에 괜찮다고 생각한 페이지도 보완해야할 부분이 많이 나와서 놀랐습니다. 하나하나 모두 신경쓸 수는 없지만 특히 이미지에 관한 부분은 꼭 최적화를 해주어야겠다고 생각이 들었습니다.

70일차

TDD

70일차에 배운 것 정리.

• TDD 기초 개념

  70일차에 어떤 어려움을 겪었는지.

  오늘의 어려움은 없습니다. :D

70일차 느낀점.

생각보다 과제가 굉장히 쉬웠다! 또한 TDD 방법론에 대해 관심이 있었는데 FE개발자로서 어떻게 적용할 수 있을지에 대해 고민을 해보는 시간을 가지게 되었다. FE개발자는 작성하는 코드를 브라우저에서 실시간으로 확인 할 수 있기 때문에 '꼭 필요할까?'라는 생가도 들었지만 한편으로는 좀 더 단순한 구조의 코드를 작성하는 습관을 들일 수 있어 좋다고 생각하였다. 지금 바로는 아니지만 BE언어를 배울 때가 올 것이며, 그때는 처음부터 TDD 적용을 습관 들여봐야겠다.

오늘의 영어 공부.

그저께부터 일일 영단어 공부를 시작했지만 TIL에 적진 않았었다. 하지만 TIL에 다시 한 번 적으면서 복습도 하고, 무엇이던지 기록하는 습관을 기르기 위해 오늘부터 적기로 하였다!

• dept : 빚, 빚을 진 상태, 은혜를 입음 I need to pay off all my debts before I leave the country. 나는 이 나라를 떠나기 전에 모든 빚을 갚아야한다.

• excude : (특정한 느낌 등을) 물씬 풍기다 She exuded confidence. 그녀에게서 자신감이 넘쳐 흘렀다.

• digest : (음식을) 소화하다; 소화 되다 Humans cannot digest plants such as grass. 인간은 잔디같은 식물을 소화 시키지 못한다.

• battered : 낡은, 닳은 a battered old car. 낡은 중고차.

• mechanical : 기계로 작동되는 a mechanical device/toy/clock 기계로 작동되는 장치/장난감/시계

코드를 작성하기 이전에 테스트를 진행하는 프래그래밍 방법론이며 테스트 주도 개발이라고 부르기도 합니다.. TDD는 개발자가 기획한 코드의 예상가능한 결과를 미리 코드로 작성해놓고, 해당 테스트 코드로 작성하는 코드를 테스트 하는 방식이며, 버그를 예방하고 자연스럽게 버그를 fix할 시간도 줄어들게 됩니다. 이것이 TDD의 목적이라고 할 수 있겠습니다.

TDD의 개발 주기

TDD의 개발 주기

1. 실패하는 테스트 코드를 작성합니다.
2. 테스트 코드를 통과하는 실제 코드를 작성합니다.
3. 작성된 실제 코드를 리팩토링합니다.

이 과정에 대해 더 이야기를 해보겠습니다.

예상가능한 결과를 테스트 코드로 정확히 작성하지 않았을 때 실제 코드를 작성하게 된다면, 당연하게도 테스트가 원하는대로 이루어지지 않을 가능성이 매우 커집니다. 또한 실제 코드를 바로 방대하게 작성을 한다면 그 도중에 많은 에러를 겪을 수 있고, 그 오류가 어디에서 발생했는지 찾기 힘들어 에러 핸들링을 어렵게 합니다.

따라서 꼭 1단계 과정을 마친 후에 2단계 과정을 진행해야하는 것이고, 2단계 과정을 수행할 때엔 1단계의 테스트 코드를 통과할 최소한의 코드를 작성해야합니다.

이러한 단계가 반복적으로 진행이 되면서 버그가 줄어들고, 더 간결한 코드를 작성 할 수 있게 됩니다.

TDD with React

React 공식 문서에서 Jest를 활용하여 테스트를 진행하는 방안을 확인하실 수 있습니다.

69일차

GraphQL

69일차에 배운 것 정리.

• GraphQL

69일차에 어떤 어려움을 겪었는지.

정말 하나도 모르겠다는 느낌을 받았다. apollo client는 무엇인지 왜 사용하는건지 모르겠고, REST API도 익숙하지 않지만 처음보는 GraphQL이 낯설다 못해 아예 모르겠는 기분이다.

69일차 느낀점.

단기간에 배우기엔 내가 부족하다는 것을 자각하고, 코스를 수료하고 나서 내가 흘린 것과 놓친 것들을 다시, 지금보다는 조금은 여유있지만 더 깊게 파고 들어가고싶다. 지금 하는 블로깅에 누락된 내용들을 채워넣고, 누가 보아도 믿을 수 있는 블로그를 만들것이다. 이는 수료 후 3개월 내로 생각하고 있다. 아 그리고 영어 공부도 어제부터 진행중에 있다. 지금은 귀엽게도 하루 5단어를 외우고 예문을 푸는 정도지만, 어느정도 기초가 쌓였을 때 문법과 말하기를 연습해보자. 어제보다 오늘 나아가지 못 할 수 있지만, 어제보다 오늘 뒤에 있는 날이 없도록.

68일차

컴퓨터 공학 기초

68일차에 배운 것 정리.

• 컴퓨터의 기본 구조
• 운영체제
• 가비지 컬렉션
• 문자열과 그래픽

68일차에 어떤 어려움을 겪었는지.

늘 겪는 많은 분량에 못미치는 나의 이해도가 문제다.

68일차 느낀점.

독일의 탑 소프트웨어 회사에 근무하시는 선배님의 말씀을 듣고 많은 생각을 하게 되었다. 나는 지금 어떤 개발자가 되고싶은건지 다시 한번 생각하는 계기가 되었고 영어 공부의 중요성을 느끼게 되어 일단 영단어 외우기부터 시작했다. 그리고 여지것 품어왔던 의문이 의미가 없었다는 것을 깨닫고 죽기살기로 달려야한다, 머릿속으로 재는 것은 오히려 나의 발목을 잡는 것이라는 것을 떠올리게 되었다. 짜치는 개발자는 되지 말자.