Astroの特徴を実装しながら確認していく

Astro


今回は自分が設定したいルールが npm パッケージにないことを想定して作っていきます。

チームなどで結構こういうのが必要になる場面がたまにあるので、こう言った時にサクッと作れると何かと楽できたりする時があります

また、コーディングガイドを作っても結局守られないみたいなことをなくせます

## 0. 作成するルール

snakecaseで定義された変数をエラーにするルールを作っていきます

（ESLintのデフォルトルールで [camelcaseルール](https://eslint.org/docs/latest/rules/camelcase) はありますが、今回は入門のため）

```jsx
const test_variable = 'snake' // error

const testVariable = 'camel' // pass
```

## 1. 環境構築

各自ワークスペースに移動し、ディレクトリの作成とpackage.jsonを作成します

```bash
$ mkdir eslint-plugin-handson-sample
$ cd eslint-plugin-handson-sample
$ yarn init -y
```

必要なパッケージを追加

```bash
$ yarn add -D eslint typescript @typescript-eslint/parser @types/eslint jest ts-jest
```

`tsconfig.json` の作成

```bash
$ yarn tsc --init
```

`tsconfig.json` を以下に変更します

```json
{
	"compilerOptions": {
    "target": "es2016",
    "module": "commonjs",
    "moduleResolution": "node",
    "esModuleInterop": true,
    "forceConsistentCasingInFileNames": true,
    "strict": true,
    "skipLibCheck": true,
    "rootDir": "./src",
    "outDir": "./lib"
  },
  "exclude": ["**/*.spec.ts"]
}
```

`package.json` にscriptsとjestの設定を追加します

```json
{
  ...,
  "scripts": {
    "build": "tsc",
    "test": "jest"
  },
  "jest": {
    "roots": [
      "<rootDir>/src"
    ],
    "moduleFileExtensions": [
      "ts",
      "js"
    ],
    "transform": {
      "^.+\\\\.ts$": [
        "ts-jest",
        {
          "tsconfig": "tsconfig.json"
        }
      ]
    },
    "testEnvironment": "node"
  }
}
```

これは必須ではないですが、あると便利なので `prettier` も準備しておきます

```bash
$ yarn add -D prettier
$ touch .prettierrc
```

`.prettierrc` を以下に編集

```json
{
  "semi": true,
  "singleQuote": true
}
```

## 2. ルールの作成

実際にルールを作成していきます

以下の構成で作成していきます

```text
src
├── rules
│   ├── no-snakecase.ts
│   └── __tests__
│       └── no-snakecase.spec.ts
└── index.ts // rules配下のルール等をまとめる
```

`src/rules/no-snakecase.ts` を作成

ESLintのデフォルトリコメンドルールで [camelcase](https://eslint.org/docs/latest/rules/camelcase) があり、違う命名にしておいた方がルールのバッティングなど回避できるので今回は `no-snakecase` と命名します

※ [命名規則は以下のように定義されています](https://eslint.org/docs/latest/developer-guide/working-with-rules#rule-naming-conventions)

-   `eval()` を禁止する場合は`no-eval`、`debugger` を禁止する場合は`no-debugger` のように、何かを禁止するルールの場合は、`no` をプレフィックスとして付ける
-   ルールが何かを含めることを強制するものである場合、特別な接頭辞のない短い名前を使用する
-   単語と単語の間にハイフンを使用する

基本的なフォーマットとしては以下の形のオブジェクトをexportします

```ts
module.exports = {
    meta: {
			// ルールの説明、autofix可能かなどのメタ情報を定義
    },
    create: function(context) {
        return {
            // ASTに対して解析ロジックを書いていく
        };
    }
};
```

-   meta
    -   ルールのタイプ、説明やルールへのリンク、autofix関連についてのメタ情報を定義
-   create
    -   ASTに対しての解析ロジックを含むオブジェクトをreturnする
    -   引数に [context](https://eslint.org/docs/latest/developer-guide/working-with-rules#the-context-object) を受け取ります
        -   [context.report](https://eslint.org/docs/latest/developer-guide/working-with-rules#contextreport) メソッドが発火されると、lint時にエラーや警告を発します
        -   そのため、最終的にはASTを探っていき期待される状態で [cotext.report](http://cotext.report) を発火させるためにロジックを書いていきます
        -   その他解析に必要な情報やロジックが色々入っている

```ts
import { Rule } from 'eslint';

export const rule: Rule.RuleModule = {
  meta: {
    type: 'problem',
  },
  create: (context) => {
    const isSnakeCaseVariable = (name: string) => {
      // 先頭と末尾の_を取り除く
      const nameBody = name.replace(/^_+|_+$/gu, '');

      // 定数（ex: TEST_VARIABLE）の場合は該当させない
      return nameBody.includes('_') && nameBody !== nameBody.toUpperCase();
    };

    return {
      VariableDeclarator: (node) => {
        context.getDeclaredVariables(node).forEach((variable) => {
          if (isSnakeCaseVariable(variable.name)) {
            context.report({
              message: 'camelcaseで定義してください',
              node,
            });
          }
        });
      },
    };
  },
};
```

**meta**

type

-   `problem` `suggestion` `layout` の3種類で設定

他にも設定できるオプションはありますが、今は設定不要なのでこれだけ指定しておきます

**create**

まずエラーにしたい `const test_variable = 'test'` をAST Exprolerで見てみる

```json
{
  "type": "Program",
  "body": [
    {
      "type": "VariableDeclaration",
      "declarations": [
        {
          "type": "VariableDeclarator",
          "id": {
            "type": "Identifier",
            "name": "test_variable",
            "range": [
              6,
              19
            ]
          },
          "init": {
            "type": "Literal",
            "value": "test",
            "raw": "'test'",
            "range": [
              22,
              28
            ]
          },
          "range": [
            6,
            28
          ]
        }
      ],
      "kind": "const",
      "range": [
        0,
        28
      ]
    }
  ],
  "sourceType": "module",
  "range": [
    0,
    29
  ]
}
```

一つの式の塊ごとにbody内にオブジェクトが作られます

その式のtypeが頭の`type` keyで示されており、この場合は `VariableDeclaration`

`name: "test_variable"` を判定に使う為位置を確認しておきます

```ts
return {
  VariableDeclarator: (node) => {
   ...
```

ASTのtype keyと同じキーを設定することで該当のtypeのオブジェクトだけをfilterしたnodeオブジェクトを引数から取得できます。

今回の場合は引っ掛けたい`name: "test_variable"` は `VariableDeclarator` にあるのでこれをキーに設定します

```ts
    const isSnakeCaseVariable = (name: string) => {
      // 先頭と末尾の_を取り除く
      const nameBody = name.replace(/^_+|_+$/gu, '');

      // 定数（ex: TEST_VARIABLE）の場合は該当させない
      return nameBody.includes('_') && nameBody !== nameBody.toUpperCase();
    };

    return {
      VariableDeclarator: (node) => {
        context.getDeclaredVariables(node).forEach((variable) => {
          if (isSnakeCaseVariable(variable.name)) {
            context.report({
              message: 'camelcaseで定義してください',
              node,
            });
          }
        });
      },
    };
```

そうすると引数nodeが以下のようにとれますが該当のvariableまでアクセスするために contextに用意されている `getDeclaredVariables` を使用してオブジェクトを取得します

で定数や他のケースを想定した加味した上で `[context.report](<http://context.report>)` を発火します

messageの定義に加えて、nodeもしくはlocオプションが必要となります

ref: [Custom Rules - ESLint - context.report](https://eslint.org/docs/latest/developer-guide/working-with-rules#contextreport)

```ts
<ref *1> {
      type: 'VariableDeclarator',
      id: {
        type: 'Identifier',
        name: 'test_variable',
        range: [ 6, 19 ],
        loc: { start: [Object], end: [Object] },
        parent: [Circular *1]
      },
      init: {
        type: 'Literal',
        value: 'test',
        raw: "'test'",
        range: [ 22, 28 ],
        loc: { start: [Object], end: [Object] },
        parent: [Circular *1]
      },
      range: [ 6, 28 ],
      loc: { start: { line: 1, column: 6 }, end: { line: 1, column: 28 } },
      parent: {
        type: 'VariableDeclaration',
        declarations: [ [Circular *1] ],
        kind: 'const',
        range: [ 0, 28 ],
        loc: { start: [Object], end: [Object] },
        parent: {
          type: 'Program',
          body: [Array],
          sourceType: 'script',
          range: [Array],
          loc: [Object],
          tokens: [Array],
          comments: [],
          parent: null
        }
      }
    }
```

`src/rules/index.ts` のファイルを作成し、ruleをexportします

これによって実際にruleの使用が可能になります

```ts
import * as NO_SNAKECASE from './rules/no-snakecase';

module.exports = {
  'no-snakecase': NO_SNAKECASE.rule,
};
```

## 3. テストの作成

次に書いたコードが正しいかをテストから確認していきます

`src/rules/__tests**__**/no-snakecase.spec.ts` を作成し以下を記述します

```ts
import { RuleTester } from 'eslint';
import { rule } from '../no-snakecase';

const tester = new RuleTester({
  parser: require.resolve('@typescript-eslint/parser'),
});

tester.run('no-snakecase', rule, {
  valid: [
    `const testVariable = 'test'`,
    `const TEST_VARIABLE = 'test'`,
    `const _testVariable = 'test'`,
  ],
  invalid: [
    {
      code: `const test_variable = 'test'`,
      errors: [
        {
          message: 'camelcaseで定義してください',
        },
      ],
    },
  ],
});
```

eslintパッケージが  [RuleTester ユーティリティ](https://eslint.org/docs/latest/developer-guide/nodejs-api#ruletester) を提供してくれているためテストは直感的に書けます

その際に今回はTSをparseできる必要があるためparserの設定も追加します

あとは見たままで特に説明は不要かな？

`yarn test` を実行するとpassすることが確認できます

```bash
PASS  src/rules/__tests__/camelcase.spec.ts
  camelcase
    valid
      ✓ const testVariable = 'test' (445 ms)
      ✓ const TEST_VARIABLE = 'test' (3 ms)
      ✓ const _testVariable = 'test' (1 ms)
    invalid
      ✓ const test_variable = 'test' (3 ms)

Test Suites: 1 passed, 1 total
Tests:       4 passed, 4 total
Snapshots:   0 total
Time:        2.964 s, estimated 4 s
Ran all test suites related to changed files.
```

## 4. 他のケースを考慮してロジックを追加する

上記で簡単なケースが出来ましたが、実際snakecaseの変数が定義されるケースは様々あります

以下本家のテストコードを見ると「snakecaseを禁止する」と言っても膨大なケースの考慮が必要なことがわかります

[eslint/camelcase.js at main · eslint/eslint](https://github.com/eslint/eslint/blob/main/tests/lib/rules/camelcase.js)

よくASTがいじるの難しいと言われる所以はこのあたりなのかなと思います

今回は追加のロジック追加として関数の引数のsnakecaseを禁止するルールを追加します

```ts
function testFunc(test_arg){} // error

function testFunc(testArg){} // pass
```

今回はTDD的にテストケースを先に書いてから実装していきます

```ts
// src/rules/__tests__/no-snakecase.spec.ts

tester.run('no-snakecase', rule, {
  valid: [
    `const testVariable = 'test'`,
    `const TEST_VARIABLE = 'test'`,
    `const _testVariable = 'test'`,
    `function testFunc(firstArg){}`, // 追加
    `function testFunc(firstArg, secondArg){}`, // 追加
  ],
  invalid: [
    {
      code: `const test_variable = 'test'`,
      errors: [
        {
          message: 'camelcaseで定義してください',
        },
      ],
    },
    // -- 以下のobjを追加 --
    {
      code: `function testFunc(first_arg){}`,
      errors: [
        {
          message: 'camelcaseで定義してください',
        },
      ],
    },
		{
      code: `function testFunc(first_arg, second_arg){}`,
      errors: [
        {
          message: 'camelcaseで定義してください',
        },
        {
          message: 'camelcaseで定義してください',
        },
      ],
    },
    // -- ここまで --
  ],
});
```

`yarn test src/rules/__tests__/no-snakecase.spec.ts --watch` を実行するとtestがfailすることが確認出来ます

では今回のASTをASTExploerで見ると以下のJSONが参照できます

```json
{
  "type": "Program",
  "body": [
    {
      "type": "FunctionDeclaration",
      "id": {
        "type": "Identifier",
        "name": "testFunc",
        "range": [
          9,
          17
        ]
      },
      "generator": false,
      "expression": false,
      "async": false,
      "params": [
        {
          "type": "Identifier",
          "name": "test_arg",
          "range": [
            19,
            27
          ]
        }
      ],
      "body": {
        "type": "BlockStatement",
        "body": [],
        "range": [
          29,
          31
        ]
      },
      "range": [
        0,
        31
      ]
    }
  ],
  "sourceType": "module",
  "range": [
    0,
    31
  ]
}
```

さっきの要領で見ると `FunctionDeclaration` というtypeの中の `params` 内の `Identifier` typeの `name` を参照できるとよさそうです

```tsx
return {
      VariableDeclarator: (node) => {
        context.getDeclaredVariables(node).forEach((variable) => {
          if (isSnakeCaseVariable(variable.name)) {
            context.report({
              message: 'camelcaseで定義してください',
              node,
            });
          }
        });
      },
    // -- 以下を追加 --
      FunctionDeclaration: (node) => {
        context.getDeclaredVariables(node).forEach((variable) => {
          variable.identifiers.forEach((identifier) => {
            if (isSnakeCaseVariable(identifier.name)) {
              context.report({
                message: 'camelcaseで定義してください',
                node,
              });
            }
          });
        });
      },
    // -- ここまで --
    };
```

するとテストがpassすることが確認出来ます

なお、 `lint -fix` すると自動でコードfixをしてくれる機能がありますが、問題あるコードをどうfixさせるかのロジックも書けます

[Working with Rules - ESLint - Pluggable JavaScript Linter](https://eslint.org/docs/latest/developer-guide/working-with-rules#applying-fixes)

## 5. 実際に使用する

実際にこのルールをプロダクトで使用するには

-   npm パッケージとしてpublishする
-   localruleとして同リポジトリ内にルールを作成する

の2つかなと思います

### **npm パッケージとしてpublishする**

ここはハンズオンだとちょっとアレなので今回は割愛しますが

`yarn build` で静的なjsにbuildした上で以下など参考にpublishしてください

なお、eslint pluginとしてpublishする際は `eslint-plugin-xxx` との命名規則があるためそれに従いましょう

[npm-publish | npm Docs](https://docs.npmjs.com/cli/v8/commands/npm-publish)

[npm publishする時の注意点 - Qiita](https://qiita.com/__mick/items/e92e3fc001994ca9dfaf)

ちなみに今回のhandsonの内容を公開したやつ ↓

[eslint-plugin-kskymst-handson-sample](https://www.npmjs.com/package/eslint-plugin-kskymst-handson-sample)

```ts
// .eslintrc.js
module.exports = {
    ...略
    plugins: ['kskymst-handson-sample'],
    rules: {
        'kskymst-handson-sample/no-snakecase': 'error',
    },
}
```

エラーの状態でlint回してみると

![eslint error result {"a":"585/133"}](//images.ctfassets.net/b354m49srzyn/6T7AHsQOymLLuXjTDxTiAk/eb44e7f68fcd1bda0aaa7c999b3a8f2f/eslint-error-result.png)

動いてますね

エディタ上でも確認出来ます

![lint result on editor {"a":"667/215"}](//images.ctfassets.net/b354m49srzyn/3zGFwWa38aMSMwSqjWlEqe/2bfd11ff4167c9b5ef88e26ab9fca370/lint-result-on-editor.png)

![lint result on editor 2 {"a":"556/220"}](//images.ctfassets.net/b354m49srzyn/7jmaRA0CUtDooWfyJJVJsb/f72af431671109e1d517593482fd5a30/lint-result-on-editor-2.png)

### localruleとして同リポジトリ内にルールを作成する

npmパッケージとして公開はせず、同リポジトリ内で使うカスタムルールの設定も出来ます

以下を参考

[Working with Rules - ESLint - Pluggable JavaScript Linter](https://eslint.org/docs/latest/developer-guide/working-with-rules#runtime-rules)

ハンズオンを以前行ったときの記録

ESLint plugin の作成


[Prerenderingを使った表示速度の改善 〜速く、一貫性のあるWebを目指して〜](https://developers.cyberagent.co.jp/blog/archives/37238) に Speculation Rules とあり、なんやそれとなったので調べてみた

結論としては　Resouce Hints　を投機的に設定できる仕様のこと

そもそも Resouce Hints は `preconnect` `preload` `prefetch` `prender` などの設定でユーザーが必要になるリソース、接続を先に済ましておくことでパフォーマンスの向上を狙うもの

ただ、

`<link rel="prefetch" href="//example.com/next-page.html" as="document" crossorigin="use-credentials">`

だったり

`<link rel="prerender" href="//example.com/next-page.html">` 

だったりと宣言的にリソースを記述する必要がある

## no state prefetch

2017年ごろリリースのchromeから prerender に対する仕様が変わっている
その時までのprerenderヒントは多くのメモリを使用していた為非推奨になり、事前にリソースのfetchはするが、JSの実行や事前レンダリングをしない [no-state prefetch](https://developer.chrome.com/blog/nostate-prefetch/) という仕様を採用することになった
※設定方法は今までと同じ

現在chrome以外のサポートもまだされてない為、実質　prerender　は本来の目的ではあまり使える状態ではない

![can i use resouce hints: prerender {"a":"662/262"}](//images.ctfassets.net/b354m49srzyn/1CHDmVr2P4ZAwczfVMOdR6/d177754719da43509bb0df6d51c48f4e/can_i_use.jpg)

## prerender の問題

以前までの prerender にはいくつかの課題、問題があった

- トリガー `<link rel="prerender">` を対象となるページ上のすべてのリンクに対して含める必要がある
- クロスオリジンが対象の場合プライバシーに関する懸念がでる可能性がある
- メディアの再生や許可プロンプトなどが実行されてしまいUIを混乱させる可能性がある

## Prerender2

こういった課題から、刷新の取り組みがされており、 [Prerender2](https://docs.google.com/document/d/1P2VKCLpmnNm_cRAjUeE-bqLL0bslL_zKqiNeCzNom_w/edit) という名前で刷新が進んでいる
`chrome://flags/#enable-prerender2` から有効にすることができる

![chrome setting prerender2 {"a":"670/98"}](//images.ctfassets.net/b354m49srzyn/6whX1I9KcQYurpcCZzdx4/b9f241ba4c336de2bf03f7a767249248/chrome_setting_prerender2.jpg)

## Speculation Rules API

Speculation Rules API を通じて、以下のように書くことができる

```html
<script type="speculationrules">
 {
    "prefetch": [
      {
        "source": "list",
        "urls": ["https://b.example.com/index.html"],
        "requires": ["anonymous-client-ip-when-cross-origin"]
      }
    ],
     "prerender": [
       {
         "source": "list",
         "urls": ["/page/2"],
         "score": 0.5
       },
       {
         "source": "document",
         "if_href_matches": ["https://*.wikipedia.org/**"],
         "if_not_selector_matches": [".restricted-section *"],
         "score": 0.1
       }
     ]
   }
</script>
```

リソースヒントとは違い、デバイスやネットワークの特性、ページ構造、ビューポート、カーソルの位置、ページでの過去のアクティビティなどに基づいて適用タイミングを判断し、どのページをプリレンダリングまたはプリフェッチするかを決定できる。
QuickLink や Guess.js によって実装されるような推測ロジックを、ブラウザの機能だけで賄うことができる（「実装される可能性がある。」とあるのでまだアレかも？）
UAが理解できない場合には無視される

### key

アクションを明示する。指定できるアクションは以下

- `prefetch`
- `prerender`
- `dns-prefetch`
- `preconnect`
- `prefetch_with_subresources`

### source

Rule が適用される URL をどういう形式で UA に伝えるかを示すためのフィールド

- list rule
  - 指定されたURLに対して、ユーザーが次にこれらのURLのいずれかに移動する可能性をスコアとして0.0~1.0で指定する。（デフォルトは0.5）
- document rule
  - URLに対して各種条件付きで制限することができる
    - `if_href_matches` -  リンクの URL がリスト内の pattern のいずれかに一致することを要求
    - `if_not_href_matches` - リンクの URL がリスト内のどの pattern にもマッチしない
    - `if_selector_matches` - link要素がリスト内のいずれかのセレクタにマッチする
    - `if_not_selector_matches` - link要素がリスト内のどのセレクタにマッチしない

## 対応状況

ちなみに対応状況としては Android Chrome はすでに対応されており、Desktop chromeはまだexperimentalな状態

![chromestatus prerender {"w":"400", "a":"426/274"}](//images.ctfassets.net/b354m49srzyn/2n6xIKyfgbpjE4RqaRnKTQ/ad9ba2e01425f847eed7fca7f4e3afd0/chromestatus_prernder.jpg)

ref: https://chromestatus.com/feature/5740655424831488

## prerendering されているかのチェック

https://web.dev/speculative-prerendering/#using-the-trial

現在のnetworkタブなどからは prerender によるリソースfetchの確認はできず、`chrome://process-internals` から確認ができる

試してみたが、prerenderされているはずのページでも `prerender` の文字は確認することはできず
記事投稿から時間経ってるので変わってるのかも

（代わりにprerenderを確認する術は分かってない）

## DEMO

https://web.dev/speculative-prerendering/#demo


Resouce Hints を投機的に設定できる仕様

Speculation Rules

ref: [Interaction to Next Paint (INP) - web.dev](https://web.dev/inp/)

## 概要

現在 3 つの Core Web Vitals としての指標があるが、Interaction to Next Paint (INP)の指標が実験的なメトリクスとして追加された

ページ上のユーザーのインタラクションを通してウェブ上での応答性を測定する（クリックなどのアクションから視覚的な要素が 1frame アウトプットされるまで）

- クリック、タップ、ドラッグ、キーボード操作
- ホバーやスクロールは無視される

## INP の計測

単一のインタラクションのレイテンシー計測は以下の 3 つの期間の合計値で計測される

1. 入力遅延（input delay）

ユーザーがページを操作してからイベントハンドラーが実行されるまでの時間

2. 処理時間（processing time）

関連するイベントハンドラーでコードを実行するのにかかる合計時間

3. 表示遅延（presentation delay）

イベントハンドラーの実行が終了してから、ブラウザーが次のフレームを表示するまでの時間

![interaction to next paint {"a":"650/195"}](//images.ctfassets.net/b354m49srzyn/9IK8LhBYB2m3fwSYPK8Hs/179fa37444cd9301676bf85794e2cd86/interaction_to_next_paint.jpg)

ページのインタラクション数に応じて判定基準が変わる

50 未満: 最も遅延が大きいインタラクションが判定対象
50 以上: ほとんどの場合は 98 パーセンタイルのインタラクションの遅延が判定対象

※[パーセントとパーセンタイルの違い](https://toukeigaku-jouhou.info/2018/03/31/percent-and-percentile/)

![INP metrics {"w":"500", "a":"565/183"}](//images.ctfassets.net/b354m49srzyn/5HfTkpbUkZwvh2S70S9Ob6/18af7a7d9c0fb8e792466f4eac9a92d2/INP_metrics.jpg)

ページ遷移後にインタラクションが発生しなかった場合には計測はされない  

## 計測

各種ツールで計測可能になっている

計測方法: https://developer.chrome.com/en/blog/inp-tools-2022/

![core web vitals result {"w":"500", "a":"845/447"}](//images.ctfassets.net/b354m49srzyn/44ZcR6weLGOctploMLaa1J/a3356101061765c417a7632ccab3dedf/core_web_vitals_result.png)

まだ実験的な機能なのでこの値が検索順位などに影響はしないが、今後は Core Web Vitals の 1 つの指標として加えられる日がくる

Interaction to Next Paint (INP)

Google IO 2022 の [State of CSS - web.dev](https://web.dev/state-of-css-2022/)  セッションから気になるところをまとめ

## ブラウザ互換性向上の取り組み

- 2019年からMozilla, Googleを中心として開発者の問題を理解するためのサーベイを開始した
  - [MDN DNA 2019, 2020](https://insights.developer.mozilla.org/)
- 2021年に集めたサーベイの結果から、上位の問題に対してブラウザの互換性向上に取り組む **Compat 2021** というPJが開始された 

### Compat 2021

ref: [Compat 2021: Eliminating five top compatibility pain points on the web](https://web.dev/compat2021/)

主要なブラウザベンダーとそのほかの関係者で構成されている

Compat PJでは複数の基準で改善項目を決めている

1. 機能の仕様状況。例えばFlexboxは全ページビューの75％で仕様されている
2. バグの数（Chromium, Gecko, WebKit）、Chromiumについてはそれらのバグがいくつstarを持っているか
3. サーベイの結果
4. [web-platform-tests](https://github.com/web-platform-tests/wpt#the-web-platform-tests-project) のテスト結果
5. Can I use の [Most searched features](https://caniuse.com/#:~:text=Most%20searched%20features)

その結果以下の5つの機能を絞り、2021年に修正を目指した。

1. sticky positioning
2. aspect-ratio sizing
3. flex layout
4. grid layout
5. transform positioning and animation

実際の進捗状況は[Compat2021のダッシュボード](https://wpt.fyi/compat2021?feature=summary&stable)で確認できる

### Interop 2022

- compat 2021 が既存のCSSプロパティの互換性及び安定性を向上させることが目的であったが、Interop 2022 と名付けられたこのPJでは新しいスタイリング方法を実装していく
- Compat 2021では参加していなかった、Appleが参加
- 以下の10の項目の提供を計画している

1. `@layer`
2. Color spaces and functions
3. Containment
4. `<dialog>`
5. Form compatibility
6. Scrolling
7. Subgrid
8. Typography
9. Viewport units
10. Web compat

- CSSの観点では上記から2022年と、2022以降に分けて新しいプロパティの追加（または既存の互換性向上）が予定されている
  - https://web.dev/state-of-css-2022/#table-of-contents

↓ 一部 Pick

## Inert

ref
https://web.dev/state-of-css-2022/#inert
https://developer.mozilla.org/ja/docs/Web/API/HTMLElement/inert
polyfill: https://github.com/wicg/inert

- DOMツリーの一部を不活性状態としてマークできる
- そのツリー内のフォーム要素、リンクなどのフォーカス可能な要素も不活性となり、フォーカスや各種イベントもされない。また支援技術によるフォーカスも当たらなくなる
- そのためDialogやスライドメニューなどフォーカストラップしたい際に複雑なJSの記述を使用せず実装できる

```html
<body>
  <div class="modal">
    <h2>Modal Title</h2>
    <p>...<p>
    <button>Save</button>
    <button>Discard</button>
  </div>
  <main inert>
    
  </main>
</body>
```

※[Dialog要素](https://developer.mozilla.org/ja/docs/Web/HTML/Element/dialog)のサポートも主要ブラウザでサポートされたのでモーダルの場合はこっち使った方がより楽かもしれない（まだよくわかってない)

## Viewport Unit

- 100vh などした時に画面縦幅 + アドレスバーの高さで微妙にスクロールできてしまう時があった
- dvh, lvh, svhが追加されそのあたりの解決ができる

![Viewport units {"w":"580", "a":"845/701"}](//images.ctfassets.net/b354m49srzyn/bTvkJS35Opbr5SSrFylYg/fdac167fc06cd51a77365cde52d6fd24/168715102-d924f065-f913-49f7-98f9-468bc36f7ea1.png)

ref: https://web.dev/state-of-css-2022/#viewport-units

## :has()

ref
  https://web.dev/state-of-css-2022/#:has()
  https://developer.mozilla.org/ja/docs/Web/CSS/:has

- 特定の子要素を持っているときに親要素に対してスタイルを当てられる

```html
<head>
  <style>
    .container:has(.fuga) {
      background: red;
    }
  </style>
</head>

<body>
  <div class="container">
    <p class="hoge">hoge</p>
  </div>
  <div class="container">
    <p class="fuga">fuga</p>
  </div>
</body>
```

![:has() Pseudo-class sample {"a":"573/83"}](//images.ctfassets.net/b354m49srzyn/flo7UQXrzPFnRbgJIz6Gj/cd9a3de419fbfda0094382eb61bfb853/168715084-aaafef17-8bc4-4eeb-9863-0f01662db33d.png)

Google IO 2022 の State of CSS セッションから気になるところをまとめ

State of CSS 2022


以前に社内向けに行ったアクセシビリティ勉強会の内容です
今回は全体概要を掴みます

## アジェンダ

- アクセシビリティとは
- ハンディキャップの種類
- デバイスを操作を実現する支援技術
- WCAGによる4つの原則
- 法的観点
- まとめ

## アクセシビリティとは

- そのまま訳すとaccess + able = アクセス可能
- いかなる能力、環境、状況にかかわらず、サービスやコンテンツを利用できるようにすること
- 高齢者や身体のハンディキャップをもつユーザーに対する意味合いだけではない
    - 「電車でイヤホンがない環境下で動画を見たい時に字幕のおかげで内容を把握できる」など
- OSレベルのアクセシビリティもあるが、STORES ECの私たちが行うことはWebアクセシビリティに分類される

### アクセシビリティとユーザビリティの違い

**アクセビリティ**

- そもそもユーザーが使えるかどうか
- 広く
- より多様なユーザー、どんな環境でも使えるを目指す

**ユーザビリティ**

- まずアクセシビリティが確保されていてユーザーが使える状態であるという前提の上で、さらにどれだけ使いやすいか、分かりやすいか
- 深く
- より見やすく、わかりやすい、高い満足度を目指す

![アクセシビリティとユーザビリティ {"w":"580", "a":"16/9"}](//images.ctfassets.net/b354m49srzyn/1Nn9tXT5FMbaIlgkPmrYO9/f3dd8a04e08bc6af50c1a3dce5076bc4/accesibility_and_userbility.jpg)

## ハンディキャップの種類

（ここから先の内容はWebアクセシビリティのスコープになります）

ハンディキャップには大きく以下に分けられる

1. 視覚障害
2. 聴覚障害
3. 運動障害
4. 認知障害
5. 発作、前庭障害

盲ろう（視力と聴力共に難をもつ）など上記の複数のハンディキャップを抱えている方もいます

### 1. 視覚障害

#### 種類

- 全盲
  - 視力が全くない
- ロービジョン
  - 弱視や停止力、視野狭窄
  - 周囲の明るさや疲労により症状が変化することも多い。
  - 見え方の違い →  [視覚障害とは──見えない・見えにくいってどんなこと？ | 社会福祉法人 京都ライトハウス](https://www.kyoto-lighthouse.or.jp/knowledge/blindness-lowvision/)

- 色覚異常
  - 色を認識する力が弱いことで、色の見え方が通常の人と違う状態
  - 先天的なものと後天的なものがある
	  - 見え方の違い →  [色覚対応について | Phenomena Blog](https://www.phenomena.co.jp/blog/2017/02/10/%E8%89%B2%E8%A6%9A%E5%AF%BE%E5%BF%9C%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6/)

#### 困り

- スクリーンリーダーなど支援技術に頼らないとWebページが読めない
- コントラストの低い色合いを使用しており情報を読み取れない
- 広い画面領域を使用するWebページが使い辛くなる

### 2. 聴覚障害

#### 種類

- 難聴
  - [難聴の程度](https://webaim.org/articles/auditory/auditorydisabilities#degrees)
    - 程度は様々で、補聴器である程度カバーできる場合もあれば、ほぼ聞こえず読唇術でのコミュニケーションが主となる場合もある
  - [難聴のカテゴリー](https://webaim.org/articles/auditory/auditorydisabilities#categories)
    - 感音難聴
      - 言葉など、音の認識が難しくなる。音の情報が正しく脳に正確に伝わらなくなる
      - 難聴の中でも90%が占める
      - 加齢によって衰退しやすく、65歳以上では3人に1人と呼ばれる
    - 高周波難聴
      - 女性や子供などの高い声が聴き取りづらくなる
    - 低周波難聴
      - 低い声が聞き取りづらくなる
    - 耳鳴り

#### 困り

- 音声コンテンツの場合、内容がわからない
- 動画においても字幕がなければ、内容を理解することはかなり難しい

### 3. 運動障害

#### 種類

- [外傷性傷害](https://webaim.org/articles/motor/motordisabilities#trauma)
  - 脊髄損傷
    - 手足の麻痺により、動かすことが困難、または全く動かすことができない
  - 手足の喪失または損傷
- [病気と先天性疾患](https://webaim.org/articles/motor/motordisabilities#diseases)
  - 脳性麻痺
    - 筋肉の緊張や痙攣
  - 多発性硬化症
    - 感触や温度の感覚が鈍くなる、逆に過敏になる。痛みやしびれ感
    - 手足に力が入りにくくなる。体の片側が動きにくい。ふらついて歩きにくい。
  - パーキンソン病
    - 制御不能な震えや筋肉の硬直を引き起こす。
  - etc...

#### 困り

- 四肢欠損の為、マウス、キーボードを使った操作が不可能
- 震えによって、マウスやキーボード操作での繊細な選択が難しい
- ドラッグ、スワイプなどが難しい場合がある

### 4. 認知障害 

記憶、問題解決、言語理解、視覚的理解に影響を与える

#### 種類

- 自閉症
  - 言葉の指示が理解できなかったり、じっとできない。また自分の思いがかなわないと感情が大崩れする
- ADHD（多動性症候群）
  - 物事に集中できずやり遂げられない。じっとできない。
- 失読症
  - 文字が読めなくなったり読みづらくなる
- etc...

#### 困り

- 複数のフォームのエラーメッセージが表示された際にユーザーはそのエラーの内容を忘れてしまう
- 記載している説明の理解が難しい

### 5. 発作、前庭障害

#### 種類

- 光過敏性てんかん
  - 秒間に数回の点滅（閃光）、点滅のコントラストなどによって脳が興奮し、てんかんを起こす恐れがある
  - [「スター・ウォーズ」最新作、光過敏性てんかんの発作引き起こす恐れ](https://www.cnn.co.jp/showbiz/35146610.html)
  - 97年の [ポケモンショック](https://ja.wikipedia.org/wiki/%E3%83%9D%E3%82%B1%E3%83%A2%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%82%AF) もよく知られている

- 前庭神経炎
  - 目や頭の位置を正常に保持するための「前庭系」に異常が生じ、首が傾いた状態のまま戻らない（斜頸）、旋回や眼振（目が揺れる）などの症状を示す疾患
  - 目眩や吐き気を引き起こす
  - 4/1秒以上のスクロールアニメーションがあったり、静止したテキストの下に動く画像があったりすると引き起こす可能性がある

#### 困り

これらはできるできないというレベルではなく、実際に発作を引き起こしてしまう為危険

### 人口割合

[2016年の厚生労働省の調査](https://www.mhlw.go.jp/toukei/list/dl/seikatsu_chousa_b_h28_01.pdf) によると
- 障害を持つ方の総数は936.6万人であり、人口の約7.4％に相当
    - 身体障害 - 436.0万人
    - 知的障害 - 108.2万人
    - 精神障害者 - 392.4万人

### 一時的な障害

アクセシビリティは上記のハンディキャップを持った人たちの為だけではありません。
普段は健全でも、事故により骨折をし両腕が使えなくなることもあります。
そうすると普段通りにwebを操作することは困難となります。

また、外出時にイヤホンを忘れて動画の音声が聞けないなど身近に体験しやすいこともあります。

## デバイスを操作を実現する支援技術

支援技術は日々発達しており様々なツールが発売されています。
以下以外にもハンディキャップに適した様々な支援技術が存在します。

### スクリーンリーダー

- 画面の読み上げ機能
- キーボードと共に使う場合が多い
- PCだけではなく、SPなどでも搭載されている
- ソフトに関しては有料無料含め様々
  - JAWS（Windows）
  - PC-Talker（Windows）
  - ZoomText（Mac & Windows）
  - Window-Eyes（Windows）
  - NVDA（Windows）
  - VoiceOver（Mac）
  - ナレーター（Windows 10 標準）
  - Talkback（Android 標準）
  - ChromeVox（Browser）
- 各ソフトにより標準以外でユーザビリティの面で機能面の違いがある
- マシンリーダブルなコードになっていない場合は文書構造が理解しにくい。クリック、選択ができないなど、サービスが使えない状態になってしまう
- シェアに関してはWebaimの [Screen Reader User Survey #8 Results（2019）](https://webaim.org/projects/screenreadersurvey8/) で調査結果が見れる
	  - [メインで使用しているスクリーンリーダー](https://webaim.org/projects/screenreadersurvey8/#primary)
	  - [モバイルで普段使うスクリーンリーダー](https://webaim.org/projects/screenreadersurvey8/#mobilescreenreaders)

### 拡大鏡

- 小さい文字の判別時に使用
- 道具がなくても、OS、ブラウザでズームを調節することで解決も可能
- ピンチでのズームができないなどの設定があるとユーザーは文字の判別の難易度が上がってしまう

### [シングルスイッチ](https://webaim.org/articles/motor/assistive#singleswitch)

- 四肢が動かせないなどでマウスやキーボードでの操作が難しい場合に使用される
- 例えば、頭や（足を使える場合は足など）でクリックを行う為に使用する
- 後述する視線入力装置と組み合わせて、クリックはこちらを使うなど組み合わせて使われることが多い

### [ヘッドワンド](https://webaim.org/articles/motor/assistive#headwand)

- 頭にタッチ画面を操作できるポインタを固定し、画面の操作を行う
- （今では少ないかもしれないが）タッチ画面ではない際はキーボードを叩いて操作する
- 狙ったタップがしにくいので、タップ範囲が狭いと操作がし辛くなってしまう

### [マウススティック](https://webaim.org/articles/motor/assistive#mouthstick)

- 口に加えて、画面のタップやキーボード操作を行う
- 狙ったタップがしにくいので、タップ範囲が狭いと操作がし辛くなってしまう

### 点字ディスプレイ

ex: [ブレイルメモスマート　Air16](https://www.amedia.co.jp/product/braille/display/BMSAir16.html)

- 点字での読み書きができる
- 単体で使いメモ機能に用いることが多い
- スクリーンリーダーと連携させて、スクリーンリーダーが読んでいる情報を点字で表示することができる
- 盲ろうのユーザー（視覚と聴力両方にハンデを持つ方）でも利用ができる
- [動作している様子](https://youtu.be/vPFM5mD4-v8?t=225)

### 視線入力装置

ex: [視線入力 マイトビ－I-16](https://www.creact.co.jp/item/welfare/tobii-eyetrackers/mytobii-i15-wide/i15)
ex: [トビーPCEye5](https://www.creact.co.jp/item/welfare/tobii-eyetrackers/pceye5/pceye5-top)

- 視線のみでPCやタブレットの操作を可能にする
- 対象に一定時間注目することでクリックできる
- [マイトビー P10でwindowsを操作](https://www.youtube.com/watch?v=rGyDTKxkJgs&t=208s)

## WCAGによる4つの原則

様々な状況に対してじゃあ私たちは何をどう対応したら良いのか？という疑問が生まれてくると思います。
そこで [WCAG （Web Content Accessibility Guidelines）](https://waic.jp/docs/WCAG20/Overview.html) というウェブアクセシビリティに関するガイドラインを使用します。

そのWCAGの達成基準として [4つの原則](https://waic.jp/docs/WCAG20/Overview.html#guidelines) があり、12のガイドライン、から構築されています。
12のガイドラインはさらに A~AAA のレベルの詳細項目で構成されています

セマンティックなHTMLを意識すれば解決することもあれば、特別な実装が必要になる項目もある。また、デザインで解決する項目などがあります。

- [知覚可能（Perceivable）](https://waic.jp/docs/WCAG20/Overview.html#perceivable)
  - 情報及びユーザインタフェース コンポーネントは、利用者が知覚できる方法で利用者に提示可能でなければならない
  - ex: 画像の説明が読み上げられること、フォームとラベルが関連づけられていること
- [操作可能（Operable）](https://waic.jp/docs/WCAG20/Overview.html#operable)
  - ユーザインタフェース コンポーネント及びナビゲーションは操作可能でなければならない
  - ex: キーボードを使って操作できること、1秒に3回以上点滅・チラつきが発生しないようにすること
- [理解可能（Understandable）](https://waic.jp/docs/WCAG20/Overview.html#understandable)
  - 情報及びユーザインタフェースの操作は理解可能でなければならない
  - ex: エラーメッセージがわかりやすい箇所にあること、ページの言語設定（ `<html lang="ja">`）は適切に設定すること
- [堅牢 (Robust)](https://waic.jp/docs/WCAG20/Overview.html#robust)
  - コンテンツは、支援技術を含む様々なユーザエージェントが確実に解釈できるように十分に堅牢 (robust) でなければならない
  - ex: 各要素に設定するID属性はページ内で重複していない、正しいタグ、またはrole属性を使えていること

各Webサービスでもこういったガイドラインを作成し、公開しているサービスもいくつかあります。
アクセシビリティ方針を作成し何をどこまで対応するかがサービスごとに異なります。
また、WCAGのガイドラインを見ても記事が膨大且つ難解です。各社のガイドラインにはわかりやすくまとめられているので、理解に進むかと思います。

- [Ameba](https://a11y-guidelines.ameba.design/)
- [freee](https://a11y-guidelines.freee.co.jp/)

## 法的観点

### 障害者差別解消法と東京都障害者差別解消条例

現在の法観点において「障害者差別解消法」という法律が2016年から施行されており、以下の2点が求められる

- 不当な差別的取扱いの禁止
    - 障害を理由として、正当な理由なく、サービスの提供を拒否したり、制限したり、条件を付けたりするような行為。
    - 行政機関、民間事業者ともに禁止
- 合理的配慮の提供
    - 障がいのある方が日常生活や社会生活で受けるさまざまな制限をもたらす原因となる社会的障壁を取り除くために、障がいのある方に対し、個別の状況に応じて行われる配慮。
    - 行政機関は義務、民間事業者は努力義務

今の私たちにとっては「合理的配慮の提供」がアクセシビリティ対応に近いかと思います

 また「東京都障害者差別解消条例」という条例が2018年に施行されており、こちらでは民間事業者の「合理的配慮の提供」に関しては **義務** となっています

障害者差別解消法の改正案 が今年3月に国会に提出され、民間事業者の「合理的配慮の提供」に関して**義務**になる可能性が見えています（現在審議中）
そうするとWebアクセシビリティへの取り組みが当たりまえとなる時代も近いかもしれません

ちなみにアメリカでは法律で義務付けられており提訴件数も増えているとのこと

[Webアクセシビリティ提訴件数、米国では昨年の2.8倍に。法律で義務づけられる海外の現状［CSUNレポート］](https://webtan.impress.co.jp/e/2019/07/03/32924)

## まとめ

- 実際に実装する時には画面の向こう側のユーザーの使用をより広くイメージしながら開発を進めることができるようになった
- アクセシビリティの計画、実行に関してはエンジニア、デザイナーはもちろん、PM陣などチームでの共通認識をもって（作って）進めていくことが大事
- アクセシビリティへの取り組みが当たり前になる時代に少しづつ近づいてきている

以前に社内向けに行ったアクセシビリティ勉強会の内容で a11y の概要編

アクセシビリティとは、ハンディキャップの種類、支援技術、4つの原則

デザインパターン - GoF

## 凝集度（cohesion）

凝集度（cohesion）とはクラス、メソッド内など単一モジュール内の要素間の関連性についての尺度のことを指す

以下のレベルで定義でき、レベルが高いほど堅牢性、信頼性、再利用性、可読性の点で良いとされる

単一責任原則（他含め、SOLID原則自体）を理解する上で、凝集度は知っておくとさらに理解が深まり、今のコードがどの程度のものなのかの物差しにもできる

**7つのレベル**

*-- 低い凝集度 --*

レベル1：偶発的凝集（暗号的凝集）
レベル2：論理的凝集

*-- 中程度の凝集度 --*

レベル3：時間的凝集（一時的凝集）
レベル4：手順的凝集（手続き的凝集）

*-- 高い凝集度 --*

レベル5：通信的凝集
レベル6：逐次的凝集
レベル7：機能的凝集

いわゆる「凝集度が高い = 強度が高い」「凝集度が低い = 強度が低い」となる
凝集性が高いと

- モジュールの独立性が高く
- 修正しやすく
- コードを理解しやすい

また凝集度の意識があることで、単一責任原則が当てはめられない場合にもその中でベストな手法を見つけやすくなったりもする

### レベル1: 偶発的凝集（暗号的凝集）

関連性のない実装が並べられただけの状態
なぜそこにそのメソッドがあるのか理由が見つからない

```js
cosnt userUtil = () => { // 何をやっているのかわからない
  const user = getData();
  changeOrder(user.name); // オーダーに関する処理
  increment(); // 何をインクリメントするのか？
}
```

### レベル2: 論理的凝集

特定のフラグを用いて if や switch などで呼び出す処理を場合分けしている状態
内包される命令群の関連性は弱く、モジュール強度は弱くなる

パラメーターの取り扱いでミスを誘いやすい

```js
const registerUser = (user) => {
    if(user.getCountry() === 'japan') {
        // 国内ユーザーの登録処理
        return;
    }
    // 海外ユーザーの登録処理
}
```

![論理的凝集 {"w":"400","a":"6/4"}](//images.ctfassets.net/b354m49srzyn/1ClKSxPpaxuQyBHAB9cQzs/9520bf72992465a889588da97f4b66cc/cohesion_lev2_01.jpg)

しかし、局所的に命令を変更させる使い方などでメリットを発揮することもあるため、そういった使い方の時には有効に働く

![論理的凝集 {"w":"400","a":"600/439"}](//images.ctfassets.net/b354m49srzyn/5Erjsqt2usx4BZTmXTztzj/b7bcd0076673ec4163b55b60a8f0a3bd/cohesion_lev2_02.jpg)

### レベル3：時間的凝集（一時的凝集）

初期化処理やエラー処理など、あるタイミングで実行する関数の中に幾つかの機能が含まれている状態
機能間にあまり強い関連性はなく、実行の順序を変更しても動作する
再利用性を求めない

```js
const initialize = () => {
  initConfig(); // 設定の初期化
  initData(); // データの初期化
  initLogger(); //  ログの初期化
}
```

### レベル4：手順的凝集（手続き的凝集）

扱うデータが異なり、実行順序に関連性がある
処理の流れをそのまま詰め込んだようなモジュール
機能が増えるごとに関数が大きくなる

```js
const updateFile = (file) =>  {
    checkUserPlan(); // ユーザーに関するチェック
    checkPermission(); // 権限チェック
    writeFile(file);   //  ファイル書き込み
}
```

![手順的凝集 {"w":"400","a":"600/327"}](//images.ctfassets.net/b354m49srzyn/5SWvG66YPAmWqgxFutFQpl/bd293d5214640ef67da6fcad25a59867/cohesion_lev4.jpg)

### レベル5：通信的凝集

特定のデータの処理をする機能の集まりで**処理の実行順序は関係がない**

```js
const changeImageProfile = (data) => {
  changeImageName(data);
  changeImageMeta(data);
  changeImageRatio(data);
}
```

![通信的凝集 {"w":"400","a":"600/327"}](//images.ctfassets.net/b354m49srzyn/0jgB7X8x4Zn0wJYwY7cRX/30fe03b4b715c7f6093318c8d45257e2/cohesion_lev5.jpg)

### レベル6：逐次的凝集

特的のデータを扱う処理の集まりで**順番に関係がある**
ある部分の出力が別の部分の入力となるような部分を集めたモジュール

```js
const minimizeFile() {
    const file = getFile(); // 出力
    const minimizedFile = minimize(file)
    writeFile(minimizedFile) // 入力
}
```

![逐次的凝集 {"w":"400","a":"600/327"}](//images.ctfassets.net/b354m49srzyn/3ySSvRADN1a0La6gbHsyux/c10e84a0531b5f5628676d87d48110a4/cohesion_lev6.jpg)

### レベル7：機能的凝集

単一の目的しか持たない
保守性、テスト容易性から見ると最良の状態
できるだけ機能的凝集を目指して作るが、全ての関数を機能的凝集にすることはできないし、必ずしも適切とは言えない

```js
const calcRectangleArea = (width, height) => {
  return width * height;
}
```

![機能的凝集 {"w":"400","a":"600/327"}](//images.ctfassets.net/b354m49srzyn/BIJevTFxBZod43RRnjmkS/e767888c11c31eb112d13dd22a244c7a/cohesion_lev7.jpg)

### プラクティス

モジュール独立性を高めるために高めるために、できるだけ `7.機能的強度`を目指し、内容によっては `6. 逐次的凝集`、`5. 通信的凝集` もケースに応じて使用わけしつつ、独立性を高めたモジュールを作成していく
もし、凝集度が低いモジュールがあった際には、内部の処理を凝集度の高いモジュールに切り出す

もちろん、initialize時の時間的凝集など必然的に発生してしまうものもある。
凝集度の低いモジュールを使わないではなく、なるべく減らしていく考えで進めた方が良さそうに感じる

## 結合度（Coupling）

結合度（Coupling）とはモジュール同士の関係の密接さを表す指標
結合度（依存度）が高いと依存先の修正の影響を受けやすくなってしまう
その為、結合度は低い方が良いとされる

こちらは6段階でのレベル分けがされ、レベルが高いほど疎結合であり、良いモジュールとされます

疎結合の判定にはモジュール間でデータがどのように受け渡しされているかに着目して行う

**6つのレベル**

レベル1：内容結合
レベル2：共通結合
レベル3：外部結合
レベル4：制御結合
レベル5：スタンプ結合
レベル6：データ結合

### レベル1: 内容結合

あるモジュールと他のモジュールが一部（データの変化や命令）を共有するようなモジュール結合の仕方を指す
他モジュールの外部宣言されていないデータを直接参照したり、命令の一部を共有したりするような状況

```java
public Class Printer {
    public static void print() {
        System.out.println(Counter.number) // Couter内部の値を直接参照している
    }
}

public class Counter {
   public static int number = 0;
   public static void increment() {
        number ++;
    }
}
```

### レベル2: 共通結合

グローバルに定義したデータ（グローバル変数）を幾つかのモジュールが共同使用するような結合の仕方を指す
影響範囲がわかりづらく、あるモジュールで変更を加えたら、同じデータを参照している他のモジュールでバグが発生したりする
そのため、コードの読解を非常に難しくし、共通行のデータを通じていろいろなモジュールと繋がってしまうため、再利用性も落ちる

```js
let data = 'banana';

const updateA() {
    data = 'grape'
}

cosnt updateB() {
    data = 'ramen'
}
```

### レベル3：外部結合

外部宣言（public宣言された変数も含む）したデータを共有したモジュール間の結合の仕方を指す
例えばライブラリやIOデバイスへの接続手段を複数のモジュールで共有している状態

```js
cosnt getFilterPost = (date) => {
    const currentDate = day.js().format('YYYY-MM-DD'); // 外部ライブラリに依存してしまっている。他の日付操作ライブラリに変えたいとなったら？
    const date = dayjs(date).format('YYYY-MM-DD');
    posts.filter(post => dayjs(post.date).format('YYYY-MM-DD') === currentDate)
}
```

### レベル4：制御結合

パラメーターの1つとしてスイッチ変数を渡し、呼び出されるモジュールがその時に行う機能を指示します。
呼び出し側は呼び出されるモジュールの中身（AとBの場合それぞれの処理の中身）を知っている必要があり、結合度が高くなります
先ほど凝集度の話にもあった `レベル2.論理的凝集` になってしまう

```js
const registerUser = (user) => {
    if(user.getCountry() === 'japan') {
        // 国内ユーザーの登録処理
        return;
    }
    // 海外ユーザーの登録処理
}
```

### レベル5：スタンプ結合

モジュールに引数としてクラスやオブジェクトを渡しており、その一部しか使われないケースを指す
不必要なデータも含んだデータ構造ごと受け渡ししているため、呼び出し側から何が使用されているのか理解できず、データ構造が変わっただけでエラーとなってしまい結合度が強くなってしまいます

```js
cosnt findUserEmail(user) {
    return EmailService.findByUserId(user.id);
}
```

### レベル6：データ結合

モジュールで使うデータだけを、数字や文字列などの、プリミティブな値の引数でやりとりする
使う側がそのモジュールが内部でどういった処理をしているのかを知る必要は少なくなる
テスト容易性も高い

```js
const getUserItems = (userId, itemType) = {
    query = new ResorceQuery();
    query.addUserFilter(userId);
    query.addItemTypeFilter(itemType);
    return itemRepository.findByQuery(query);
}
```

### プラクティス

データの受け渡しはできるだけプリミティブな引数で行う
できるだけグローバルな変数にデータを置かない。その場でしか必要としないデータはローカル変数に置く

## まとめ
- モジュール内部の話：凝集度
- モジュール同士の関係性の話：結合度
- これらの指標を知ることで、今自分が書いているコードがどの程度良いコードなのかを客観的に知ることができる
- また、リファクタリングの余地を図る一つの指標にもなる
- とはいえ、早すぎるタイミングで抽象化しすぎるのも個人的には良くないと思っている（変数名考えるコストも高まるし。個人的にはKISSの法則が好き。）ので、どういう程度に付き合っていくべきかはとても難しく経験が必要だなと感じる


kosukeyamashita.dev

Blog