고치기 어려운 코드?

• 그 코드가 하는 일의 종류가 다양하거나
• 그 코드의 복잡한 내부구조를 이해해야 하거나
• 그 코드를 고쳤더니 다른곳에서 문제가 발생하거나
   
• 다른 이유도 많이 있겠죠.
  그 코드가 사람의 직관대로 작동하지 않는다던지?
  예: php, javascript 등으로 작성된 모든 코드

하는 일의 종류가 너무 다양하면

한가지 일만 담당하도록 코드를 쪼개면 됩니다

복잡한 내부구조를 알아야하면

추상화 수준을 쌓아올리면 됩니다

코드를 고쳤을 때

다른 곳에서 문제가 발생하지 않도록 하려면

캡슐화를 하면 됩니다

캡슐화

내부 구현디테일을

외부에서 알 수 없도록 하는 것

내부 구조가 바뀌어도

가져다 사용하는 곳에서는

아무것도 바꿀 필요가 없습니다

내부 구현디테일을 외부에서 알 수 없다면?

(바꿔 말하면)

많은 곳에서 사용되고 있었어도

모든 곳을 일일이 고치지 않으면서

내부 구조를 바꿀 수가 있습니다

깔끔하게 캡슐화된 코드는
인터페이스가 그 자체로 문서의 역할도 합니다

UI 컴포넌트

UI가 캡슐화된 단위

컴포넌트로 만들만한 녀석들:

• button
• toggle
• table
• ...etc

컴포넌트화되지 않은 토글 예시

// toggle을 사용하고싶은 곳에서
<div>
<span class="toggle-wrapper">
  <input class="toggle" id="toggle" type="checkbox" checked>
  <label class="toggle-inner" for="toggle">
    <span class="toggle-text"></span>
  </label>
</span>
</div>

// ^ 위와 같은 마크업 구조를 일일이 작성함
// 후에 디자인 변경등의 이슈로 마크업이 바뀌어야 할 때
// toggle을 사용하는 모든 코드가 같이 수정되어야 함

리액트 컴포넌트 예시

// toggle을 사용하고싶은 곳에서

render() {
    return <div>
    //v v v v v v v v v v v v v v
        <Toggle checked={true}/>;
    //^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
    </div>;
}

// Toggle 내부가 바뀌어도 이 코드는 고칠 필요가 없음

// 게다가 코드가 단순해졌습니다.
// 이 코드가 본래 하고자하는 것에 집중할 수가 있습니다.
// -> 고치는게 쉬워졌습니다.

두부를 리액트 컴포넌트 라이브러리로

만들자는 이야기는

이미 저번에 얘기했죠

제낄게요

모듈

독립적인 기능으로 쪼개진 단위

스타일시트에서 모듈로 만들만한 녀석들:

• color scheme
• grid system
• icons
• ...etc

독립적?

그 자체로 가져다 쓰일 수 있어야 합니다

예를 들자면 mo의 `_colors.scss`는 독립적인 모듈입니다

// 예시) dodo-landing/landing/static/css
// /campaign/paper_coupon.scss 에서 따옴

@import '../../_sass/mo/_colors.scss';
// _colors.scss 하나만 import 하면

$image-path: '/static/images/campaign/';
$background-size-path: '/bower_components/background-size-polyfill/backgroundsize.min.htc';

body.paper-coupon {
  .section-cover {
...blabla
    // 별 부작용 없이 바로 변수를 가져다 쓸 수 있습니다.
    background-color: $grey-3;
  }
...blabla

독립적이면 좋은 것

전역변수를 사용하지 않기 때문에

어떤 변수가 어떤 곳에 정의돼있는지

코드를 처음 보는 사람이 쉽게 찾아갈 수 있습니다

왜 쪼개는가

• 의도하지 않은 부수효과를 피할 수 있습니다
• 코드베이스에 익숙하지 않은 사람이
  고쳐야할 지점을 쉽게 찾아갈 수 있습니다
• 쪼개진 코드에만 집중할 수 있습니다

쪼개져있으면 사용하는 쪽에서...

의도하지 않은 부수효과?

• scss 에 선언된 변수나 믹스인만 얻고 싶은데
  css 셀렉터와 스타일까지 같이 import되면
  의도하지 않은 스타일이 dom에 적용됩니다
   
• import한 scss 파일에 너무 많은 변수가 선언되어있으면
  작성중이던 스타일시트와
  겹치는 변수명이 생길 가능성이 높아집니다

그런 일이 언제 생기는가

css 파일을 나눠서 컴파일하면 항상 생깁니다

• 랜딩페이지의 종이쿠폰 캠페인 페이지는
  메인의 css를 가져다 사용하는데 전용 css파일도 따로 씁니다
• 통합약관페이지는 layout과 content css를 나눠서 사용합니다

예상 문제 시나리오

1. `hello.html`에서
   1. `<link rel="stylesheet" type="text/css" href="a.css">`
   2. `<link rel="stylesheet" type="text/css" href="b.css">`
2. `a.css`에서
   1. 두부 import
   2. 스타일 오버라이드
3. `b.css`에서
   1. 스타일 오버라이드 중 두부의 변수(예: `$bg-grey`)가 필요
   2. 파일의 상단에서 두부 import
4. 3.2. 에서 import한 두부가 2.2. 에서 정의한 스타일을 덮어씀

왜 css 파일을 나눠서 컴파일하는가

• 중복되는 코드를 피하고 싶어서
• 첫 페이지만 방문할 사용자에게 모든 페이지의 스타일이
  다 들어간 css를 내려주지 않아도 되도록 하기 위해
• 새로 배포된 뒤로 처음 페이지를 방문하는 사용자의
  로딩타임을 줄이기 위해
• HTTP/2 에서는 요청당 오버헤드가 적어서
  리소스를 쪼개는게 오히려 성능에 도움이 되기 때문에
• 귀찮아서
• ...etc

두부는 많은 곳에서 사용되고 있기 때문에
다양한 요구사항을 가지고 있습니다

그렇기 때문에 다양한 요구사항에
유연하게 대처할 수 있는 구조로 바뀌어야 한다고 생각합니다

두부를 좀 더 고치고 싶어요

대강 이러이러하게

독립적이지 않은 코드를

예를 들자면 두부의 `_variables.scss`는 독립적이지 않습니다

// 가상의 코드

@import 'dooboo/_variables.scss';

body {
    background: $bg-grey; // 컴파일 에러
}

// _variables.scss
$bg-grey: $grey-0;

// `$grey-0`이 `_variables.scss`안에 없기 때문

독립적인 코드로

`_variables.scss`안에서 `_colors.scss`를 import 한다면

// `_variables.scss`만 import 하고도
// `$bg-grey`를 사용할 수 있습니다.

@import 'dooboo/_variables.scss';

body {
    background: $bg-grey; // 이상없음
}

// _variables.scss
@import 'mo/_colors.scss';

$bg-grey: $grey-0;

// `$grey-0`은 `_colors.scss`에 들어있음

쪼갤 수 있는 것들

`_variables.scss`의 제목 주석들만 모아보았습니다

// Layout
// Grid
// Service color
// Type
// Text color
// General UI
// Checkbox and Radios
// Toggle
// for muenus like "Dropdown menus", "Sidebar menus"
// Sidebar
// Page Header
// Subnav
// Footer
// Buttons
// Label
// Alerts
// Dropdown
// Navbar
// Topnav
// Tables
// Forms
// Modal
// Toast
// Panels
// Hero
// Section
// Transition
// Z-index master list

이런 것들은 별도 파일로 나누고

• Layout
• Grid
• Service color
• Type
• Text color
• General UI

이런것들은 리액트 컴포넌트 코드와

같이 묶어놓으면 좋겠습니다

• Checkbox
• Toggle
• Page Header
• Subnav
• Footer
• Buttons
• Label
• Alerts
• Dropdown

• Radios
• Navbar
• Topnav
• Tables
• Forms
• Modal
• Toast
• Panels
• Hero