Development

“When should you make a design document? ... If the change is large/cross-cutting, eg. will be spread over multiple PRs”

Writing forces clarity of thought. Think through major technical challenges before writing code.

Design docs are lightweight planning documents written before implementing code to solicit feedback, derive alignment, and create documentation.

それは、コードをminifyしたときに this.name の内容も一緒に変化してしまうからです。 最初に示したコード例のように名前を文字列リテラルとして明示することで、minifyされずにエラー名を保持することができます。強い難読化の必要がなければ、エラー名はそのまま保持するほうがよいでしょう。

npx @eslint/migrate-config .eslintrc.json

Make sure you upgrade to at least Node.js v18.18.0 when using ESLint v9.0.0.

Four new rules have been enabled in eslint:recommended:

Flat config. If you are using flat config, you can run npx eslint or eslint (if globally installed) and ESLint will assume you want to lint the current directory. Effectively, passing no patterns is equivalent to passing . .

The mutationKey role is to link a mutation with a default option already configured or to identify a mutation to share its state like loading, error, or data across components.

React 19 では、トランジション内で非同期関数を使用することで、送信中状態、エラー、フォーム、楽観的更新を自動的に処理するためのサポートが追加されます。

一方、こうした経験が無い人の中には、変更容易性は余計なもの、面倒なもの、過剰なものとして捉えるケースがある。これは致し方ない面もある。私自身も書籍などで見聞きしていたものが、実体験を伴った（痛みを経験した）ことでその重要性に気付いたという経験が何度もある。こうした変更容易性の重要性が分からない状態で原則を駆使すると、ともすれば形だけ適用してピントを外したものにもなりかねない。例えば、クリーンアーキテクチャを採用したのに、ただ手数が増えるばかりで効果が実感できないというようなことが起こり得る。

副次的な変更に影響を受ける箇所は限定的にしておくことで、その影響範囲を小さくできる。これはレイヤ分けしなくてもクラス設計の工夫で十分に対応できる。例えば、外部ライブラリをアプリケーション全体で広く使うのではなく、それを内包したクラスを実装し、アプリケーションではその内包したクラスを利用するという方法だ。

外部変更容易性を向上させるには、クラスの組み合わせを変えられるポイントを作っておき、状況に応じてそこに必要なクラスを差し替えられるようにしておく。例えば、DI（依存性注入）やOCP（オープンクローズド原則）、さらに GoF のデザインパターンにこういった例がある。この方法は有効である場面はある一方、方法によってはあらかじめ変更できる箇所を予測して実装しておく必要があり、構成としてもやや複雑になるという面がある。

「Easier To Change」（変更をしやすくする）。これがETC原則です。 (略) 我々が知る限り、この世の中のあらゆる設計原則はETC原則を特殊化したものとなっています。

一方、内部変更容易性を向上させるには、クラスやモジュールの内部実装を変更しやすい状態にしておく。有効なもの一つに情報隠蔽がある。

どういった状態が理解しやすいものかというのは読む人にも依存する。そ