anchor.diff:  
   .l-main-section
   :marked
  +  ### <a id="04-09"></a>기능 모듈
     ### <a id="04-09"></a>Feature modules
     #### <a href="#04-09">Style 04-09</a>
   .s-rule.do
   
     :marked
  +    **필수** 애플리케이션의 모든 고유 기능 (예: `Heroes` 기능)에 대해 Angular 모듈을 만듭니다.
  +
       **Do** create an Angular module for all distinct features in an application (e.g. `Heroes` feature).
   
   .s-rule.do
     :marked
  +    **필수** 기능 모듈을 기능 영역과 같은 이름의 폴더에 둡니다 (예: `app/heroes`).
  +
       **Do** place the feature module in the same named folder as the feature area (.e.g `app/heroes`).
   
   .s-rule.do
     :marked
  +    **필수** 기능 영역과 폴더의 이름을 반영하여 기능 모듈 파일을 네이밍합니다. (예: `app/heroes/heroes.module.ts`)
  +
       **Do** name the feature module file reflecting the name of the feature area and folder (e.g. `app/heroes/heroes.module.ts`)
   
   .s-rule.do
     :marked
  +    **필수** 기능 영역과 폴더, 파일의 이름을 반영하여 기능 모듈 기호를 네이밍합니다. (예: `app/heroes/heroes.module.ts` defines `HeroesModule`)
  +
       **Do** name the feature module symbol reflecting the name of the feature area, folder, and file (e.g. `app/heroes/heroes.module.ts` defines `HeroesModule`)
   
   .s-why
     :marked
  +    **이유** 기능 모듈은 다른 모듈에 구현을 숨기거나 노출할 수 있습니다.
  +
       **Why?** A feature module can expose or hide its implementation from other modules.
   
   .s-why
     :marked
  -    **Why?** A feature module identifies distinct sets of related components that comprise the feature area. 
  -
  -.s-why
  -  :marked
  -    **Why?** A feature module can easily be routed to both eagerly and lazily. 
  -
  -.s-why
  -  :marked
  -    **Why?** A feature module defines clear boundaries between specific functionality and other application features. 
  -
  -.s-why
  -  :marked
  +    **이유** 기능 모듈은 기능 영역을 구성하는 관련 컴포넌트와 구별되는 세트를 식별합니다.
  +
  +    **Why?** A feature module identifies distinct sets of related components that comprise the feature area.
  +
  +.s-why
  +  :marked
  +    **이유** 기능 모듈은 즉시 로딩과 지연 로딩 모두에 쉽게 라우팅 될 수 있습니다.
  +
  +    **Why?** A feature module can easily be routed to both eagerly and lazily.
  +
  +.s-why
  +  :marked
  +    **이유** 기능 모듈은 특정 기능과 다른 애플리케이션 기능 사이의 경계를 명확히 정의합니다.
  +
  +    **Why?** A feature module defines clear boundaries between specific functionality and other application features.
  +
  +.s-why
  +  :marked
  +    **이유** 기능 모듈을 사용하면 개발 책임을 여러 팀에 쉽게 할당하고 명확히 할 수 있습니다.
  +
       **Why?** A feature module helps clarify and make it easier to assign development responsibilities to different teams.
   
   .s-why.s-why-last
     :marked
  +    **이유** 기능 모듈을 사용하면 테스트 분리가 쉽습니다.
  +
       **Why?** A feature module can easily be isolated for testing.
   
   a(href="#toc") Back to top
   
   .l-main-section
   :marked
  +  ### <a id="04-10"></a>공유 기능 모듈
     ### <a id="04-10"></a>Shared feature module
     #### <a href="#04-10">Style 04-10</a>
   
   .s-rule.do
     :marked
  +    **필수** `shared` 폴더의 `SharedModule`이라는 이름의 기능 모듈을 만드세요. (예: `app/shared/shared.module.ts` defines `SharedModule`)
  +
       **Do** create a feature module named `SharedModule` in a `shared` folder (e.g. `app/shared/shared.module.ts` defines `SharedModule`).
   
   .s-rule.do
     :marked
  -    **Do** declare components, directives, and pipes in a shared module when those 
  +    **필수** 컴포넌트, 지시자, 파이프가 재사용되고 다른 기능 모듈에 선언된 컴포넌트에서 참조할 경우
  +    공유 모듈에 선언하세요.
  +
  +    **Do** declare components, directives, and pipes in a shared module when those
       items will be re-used and referenced by the components declared in other feature modules.
   
   .s-rule.consider
     :marked
  -    **Consider** using the name SharedModule, when the contents of a shared 
  +    **권장** 공유 모듈의 컨텐츠가 전체 애플리케이션에 걸쳐 참조될 경우
  +    SharedModule이라는 이름을 사용하세요.
  +
  +    **Consider** using the name SharedModule, when the contents of a shared
       module are referenced across the entire application.
   
   .s-rule.do
     :marked
  -    **Do** not provide services in shared modules. Services are usually 
  -    singletons that are provided once for the entire application or 
  +    **필수** 공유 모듈에 서비스를 만들지 마세요.
  +    서비스는 보통 전체 애플리케이션이나 특정 기능 모듈에서
  +    한번만 제공되는 싱글톤입니다.
  +
  +    **Do** not provide services in shared modules. Services are usually
  +    singletons that are provided once for the entire application or
       in a particular feature module.
   
   .s-rule.do
     :marked
  +    **필수** `SharedModule`에 있는 자산에 필요한 모든 모듈을 임포트하세요. (예: `CommonModule` 과 `FormsModule`)
  +
       **Do** import all modules required by the assets in the `SharedModule` (e.g. `CommonModule` and `FormsModule`).
   
   .s-why
     :marked
  +    **이유** `SharedModule`은 다른 공통 모듈의 기능을 필요로 하는 컴포넌트, 지시자, 파이프를 포함합니다. (예: `ngFor` in `CommonModule`)
  +
       **Why?** `SharedModule` will contain components, directives and pipes that may need features from another common module (e.g. `ngFor` in `CommonModule`).
   
   .s-rule.do
     :marked
  +    **필수** 모든 컴포넌트, 지시자, 파이프를 `SharedModule`에 선언하세요.
  +
       **Do** declare all components, directives, and pipes in the `SharedModule`.
   
   .s-rule.do
     :marked
  -    **Do** export all symbols from the `SharedModule` that other feature modules need to use.  
  -
  -.s-why
  -  :marked
  +    **필수** 다른 기능 모듈에서 필요한 `SharedModule`의 모든 기호를 익스포트하세요.
  +
  +    **Do** export all symbols from the `SharedModule` that other feature modules need to use. 
  +
  +.s-why
  +  :marked
  +    **이유** `SharedModule`은 공통적으로 사용되는 컴포넌트, 지시자, 파이프를 다른 많은 모듈의 컴포넌트 템플릿에서 사용할 수 있도록 하기 위해 존재하니다.
  +
       **Why?** `SharedModule` exists to make commonly used components, directives and pipes available for use in the templates of components in many other modules.
   
   .s-rule.avoid
     :marked
  +    **금지** `SharedModule` 안에 앱 전역 싱글톤 제공자를 지정하는 것. 의도적인 싱글톤이라면 괜찮습니다. 조심하세요.
  +
       **Avoid** specifying app-wide singleton providers in a `SharedModule`. Intentional singletons are OK. Take care.
   
   .s-why
     :marked
  +    **이유** 해당 공유 모듈을 가져오는 지연 로딩된 기능 모듈은 자체 서비스 복사본을 만들고 바람직하지 않는 결과를 초래할 수 있습니다.
  +
       **Why?** A lazy loaded feature module that imports that shared module will make its own copy of the service and likely have undesireable results.
   
   .s-why.s-why-last
     :marked
  -    **Why?** You don't want each module to have its own separate instance of singleton services. 
  +    **이유** 각 모듈이 분리된 자체 싱글톤 서비스 인스턴스를 가지기를 원하지는 않습니다.
  +    그러나 `SharedModule`이 서비스를 제공한다면 실제로 발생할 위험이 있습니다.
  +
  +    **Why?** You don't want each module to have its own separate instance of singleton services.
       Yet there is a real danger of that happening if the `SharedModule` provides a service.
   
   .filetree
  
positive.code: 
  .l-main-section
  :marked
    ### <a id="02-04"></a>Service names
    #### <a href="#02-04">Style 02-04</a>
  
  .s-rule.do
    :marked
      **Do** use consistent names for all services named after their feature.
  
  .s-rule.do
    :marked
      **Do** suffix a service class name with Service. 
      For example, something that gets data or heroes 
      should be called a `DataService` or a `HeroService`.
  
      A few terms are unambiguously services. They typically 
      indicate agency by ending in "er". You may prefer to name 
      a service that logs messages `Logger` rather than `LoggerService`. 
      Decide if this exception is agreeable in your project. 
      As always, strive for consistency.
  
  .s-why
    :marked
      **Why?** Provides a consistent way to quickly identify and reference services.
  
  .s-why
    :marked
      **Why?** Clear service names such as `Logger` do not require a suffix.
  
  .s-why.s-why-last
    :marked
      **Why?** Service names such as `Credit` are nouns and require a suffix and should be named with a suffix when it is not obvious if it is a service or something else.
  
  - var top="vertical-align:top"
  
negative.code: 
  .s-rule.consider
    :marked
      **권장(Consider)** 가이드라인은 일반적으로 따라야 하는 것입니다.
      만약 가이드라인 뒤에 있는 뜻을 완전히 이해하고 다른 방법을 사용할 타당한 이유가 있다면 그렇게 해도 됩니다. 부디 일관성을 유지하세요.
  
      **Consider** guidelines should generally be followed.
      If you fully understand the meaning behind the guideline and have a good reason to deviate, then do so. Please strive to be consistent.
  
  .s-rule.avoid
    :marked
      **금지(avoid)**는 거의 해서는 안되는 것을 나타냅니다. *금지*에 대한 코드 예제는 실수를 하지 않도록 빨간색 머리글로 표시했습니다.
  
      **Avoid** indicates something you should almost never do. Code examples to *avoid* have an unmistakeable red header.
  .l-main-section
  
  :marked
    ## 파일 구조 규칙
    ## File structure conventions
  
    어떤 코드 예제는 한 개 또는 한 개 이상의 비슷한 이름을 가진 동반 파일을 보여줍니다.
    예를 들어 `hero.component.ts`와 `hero.component.html`과 같은 것입니다.
  
    Some code examples display a file that has one or more similarly named companion files.
    For example, `hero.component.ts` and `hero.component.html`.
  
    가이드라인에서는 이러한 다양한 파일을 표시하기 위해 `hero.component.ts|html|css|spec` 단축표기법을 사용합니다. 이러한 단축표기법을 사용하여 가이드의 파일 구조를 보다 읽기 쉽고 보다 간결하게 합니다.
  
    The guideline will use the shortcut `hero.component.ts|html|css|spec` to represent those various files. Using this shortcut makes this guide's file structures easier to read and more terse.
  
  .l-main-section
  a(id='toc')
  
  :marked
    ## 목차
    ## Table of contents
  
      1. [단일 책임](#single-responsibility)
  
      1. [Single responsibility](#single-responsibility)
  
      1. [네이밍 규칙](#naming)
  
      1. [Naming](#naming)
  
      1. [코딩 컨벤션](#coding-conventions)
  
      1. [Coding conventions](#coding-conventions)
  
      1. [앱 구조와 Angular 모듈](#app-structure-and-angular-modules)
  
      1. [App structure and Angular modules](#app-structure-and-angular-modules)
  
      1. [컴포넌트](#components)
  
      1. [Components](#components)
  
      1. [지시자](#directives)
  
      1. [Directives](#directives)
  
      1. [서비스](#services)
  
      1. [Services](#services)
  
      1. [데이터 서비스](#data-services)
  
      1. [Data services](#data-services)
  
      1. [라이프사이클 훅](#lifecycle-hooks)
  
      1. [Lifecycle hooks](#lifecycle-hooks)
  
      1. [부록](#appendix)
  
      1. [Appendix](#appendix)
  
  .l-main-section
  :marked
    ## 단일 책임
    ## Single responsibility
  
    <a href="https://wikipedia.org/wiki/Single_responsibility_principle" target="_blank"><i>단일 책임 원칙</i> (SPR)</a>을
    모든 컴포넌트, 서비스, 다른 기호에 적용하세요.
    앱을 보다 깔끔하고, 읽고 관리하기 쉽고, 테스트하기 쉽게 도와줍니다.
  
    Apply the
    <a href="https://wikipedia.org/wiki/Single_responsibility_principle" target="_blank"><i>Single Responsibility Principle</i> (SPR)</a>
    to all components, services, and other symbols.
    This helps make the app cleaner, easier to read and maintain, and more testable.
  
    ### <a id="01-01"></a>_하나의 규칙_
    ### <a id="01-01"></a>_Rule of One_
    #### <a href="#01-01">Style 01-01</a>
  .s-rule.do
    :marked
      **필수** 파일 당 서비스나 컴포넌트 하나만 정의합니다.
  
      **Do** define one thing, such as a service or component, per file.
  
  .s-rule.consider
    :marked
      **권장** 파일에 코드는 400라인으로 제한합니다.
  
      **Consider** limiting files to 400 lines of code.
  
  .s-why
    :marked
      **이유** 파일 당 하나의 컴포넌트를 만들면 읽고, 관리하고, 팀에서 소스 제어 시
      충돌을 회피하기에 훨씬 쉽습니다.
  
      **Why?** One component per file makes it far easier to read, maintain, and avoid
      collisions with teams in source control.
  
  .s-why
    :marked
      **이유** 파일 당 하나의 컴포넌트를 만들면 숨겨진 버그를 회피할 수 있습니다. 한 파일에 여러 컴포넌트를 합칠 경우 변수를 공유하고, 원하지 않는 클로저를 만들거나, 원하지 않는 의존성에 묶이면서 숨겨진 버그가 발생할 수 있습니다.
  
      **Why?** One component per file avoids hidden bugs that often arise when combining components in a file where they may share variables, create unwanted closures, or unwanted coupling with dependencies.
  
  .s-why.s-why-last
    :marked
      **이유** 단일 컴포넌트는 라우터에서 지연 로딩을 활용할 수 있는 파일의 기본 익스포트가 될 수 있습니다.
  
      **Why?** A single component can be the default export for its file which facilitates lazy loading with the router.
  :marked
    요점은 보다 재사용성이 높고, 읽기 쉽고, 실수를 유발할 가능성이 적은 코드를 만드는 것입니다.
  
    The key is to make the code more reusable, easier to read, and less mistake prone.
  
    다음 *부정적인* 예제는 `AppComponent`를 정의하고, 앱을 실행(bootstrap)하고, `Hero` 모델 객체를 정의하고, 서버에서 히어로를 로드합니다 ... 모두 같은 파일에서요. *이렇게 하지 마세요*.
  
    The following *negative* example defines the `AppComponent`, bootstraps the app, defines the `Hero` model object, and loads heroes from the server ... all in the same file. *Don't do this*.
  
  +makeExample('style-guide/ts/01-01/app/heroes/hero.component.avoid.ts', '', 'app/heroes/hero.component.ts')(avoid=1)
  :marked
    컴포넌트와 지원 클래스를 자신만의 지정된 파일로 배포하는 것이
    보다 좋은 습관입니다.
  
    It is a better practice to redistribute the component and its
    supporting classes into their own, dedicated files.
  
  +makeTabs(
  