alihan/cognitive-load
1
0
Fork 0
mirror of https://github.com/zakirullin/cognitive-load.git synced 2025-10-09 13:42:36 +03:00
Code Issues Packages Projects Releases Wiki Activity

Improve clarity and readability of Japanese translation in README.ja.mdRefactor: Improve Japanese translation clarity

Browse Source 
This commit improves the clarity and readability of the Japanese translation in README.ja.md. It addresses issues with indirectness and cognitive load, making the content easier to understand.
This commit is contained in:
Akihito Koriyama
2025-09-01 23:53:42 +09:00
parent 06a8391ed4
commit 4965fac6e1
1 changed files with 34 additions and 34 deletions
Download Patch File Download Diff File Expand all files Collapse all files

68
README.ja.md
View File

@@ -5,18 +5,18 @@
*これは生きた文書であり、最終更新は**2025年8月**です。あなたの貢献を歓迎します！*
## はじめに
世の中には多くのバズワードやベストプラクティスがありますが、そのほとんどがうまくいっていません。私たちにはもっと根本的な、間違いようのないものが必要です。
世の中には多くのバズワードやベストプラクティスがありますが、そのほとんどがうまくいっていません。私たちにはもっと根本的な、誤りようのないものが必要です。
コードを読んでいて混乱を感じることがあります。混乱は時間とお金を消費します。混乱の原因は高い*認知負荷*にあります。これは決して抽象的な概念ではなく、**人間の根本的な制約**なのです。想像上のものではなく、実際に存在し、私たちはそれを感じることができます。
コードを読んでいて混乱を感じることがあります。混乱は時間とお金を消費します。混乱の原因は高い*認知負荷*にあります。これは決して抽象論ではなく、**人間の根本的制約**なのです。私たちはそれを実感できます。
コードを書くよりもコードを読んで理解することに費やす時間のほうがはるかに長いため、私たちは常に、過度の認知負荷をコードに埋め込んでいないかを自問すべきです。
## 認知負荷
> 認知負荷とは、開発者がタスクを完了するために考える必要がある量のことです。
コードを読むとき、変数の値、制御フローロジック、呼び出しシーケンスなどを頭に入れます。平均的な人はワーキングメモリに約[4つのチャンク](https://github.com/zakirullin/cognitive-load/issues/16)を保持できます。認知負荷がこの閾値に達すると、物事を理解するのがはるかに困難になります。
コードを読むとき、変数の値、制御フローロジック、呼び出しシーケンスなどを頭に保持します。平均的な人はワーキングメモリに約[4つのチャンク](https://github.com/zakirullin/cognitive-load/issues/16)を保持できます。認知負荷がこの閾値を超えると、理解が一気に難しくなります。
*完全に馴染みのないプロジェクトにバグ修正を依頼されたとしましょう。とても賢い開発者が貢献していたと聞かされました。多くの洗練されたアーキテクチャ、おしゃれなライブラリ、最新のテクノロジーが使われていました。つまり、**著者は私たちに高い認知負荷を作り出していた**のです。*
> 完全に馴染みのないプロジェクトにバグ修正を依頼されたとしましょう。とても賢い開発者が貢献していたと聞かされました。多くの洗練されたアーキテクチャ、おしゃれなライブラリ、最新のテクノロジーが使われていました。つまり、**著者は私たちに高い認知負荷を作り出していた**のです。
<div align="center">
<img src="/img/cognitiveloadv6.png" alt="認知負荷" width="750">
@@ -30,15 +30,15 @@
</details>
## 認知負荷の種類
**内発的** - タスクの本来の難易度によって引き起こされます。これは削減できず、ソフトウェア開発の核心にあるものです。
**内在的** - タスクの本来の難易度によって引き起こされます。これは削減できず、ソフトウェア開発の核心にあるものです。
**外発的** - 情報の提示方法によって作り出されます。タスクに直接関係しない要因、例えば賢い開発者のクセのようなもので引き起こされます。大幅に削減可能です。私たちはこの種の認知負荷に焦点を当てます。
**外在的** - 情報の提示方法によって作り出されます。タスクに直接関係しない要因、例えば賢い開発者のクセのようなもので引き起こされます。大幅に削減可能です。私たちはこの種の認知負荷に焦点を当てます。
<div align="center">
<img src="/img/smartauthorv14thanksmari.png" alt="内発的 vs 外発的" width="600">
<img src="/img/smartauthorv14thanksmari.png" alt="内在的 vs 外在的" width="600">
</div>
外発的認知負荷の具体的で実践的な例にすぐに飛び込みましょう。
外在的認知負荷の具体的で実践的な例にすぐに飛び込みましょう。
---
@@ -53,7 +53,7 @@
```go
if val > someConstant // 🧠+
&& (condition2 || condition3) // 🧠+++、前の条件が真で、c2かc3のいずれかが真である必要性
&& (condition4 && !condition5) { // 🤯、この時点で混乱します
&& (condition4 && !condition5) { // 🤯、この時点で理解が破綻しがち
...
}
```
@@ -91,7 +91,7 @@ if !isSecure
stuff // 🧠+
```
ハッピーパスだけに集中でき、ワーキングメモリをあらゆる前提条件から解放します。
ハッピーパス（正常系）だけに集中でき、ワーキングメモリをあらゆる前提条件から解放します。
## 継承の悪夢
管理者ユーザーのためにいくつかの変更を依頼されました：`🧠`
@@ -105,7 +105,7 @@ stuff // 🧠+
ああ、待って、`AdminController`を継承する`SuperuserController`があります。`AdminController`を変更することで継承クラスで問題が起こる可能性があるので、まず`SuperuserController`を調べましょう：`🤯`
継承よりコンポジションを好みましょう。詳細には触れません - [十分な資料](https://www.youtube.com/watch?v=hxGOiiR9ZKg)があります。
継承よりコンポジション（委譲）を好みましょう。詳細は割愛します。 - 参考資料は[こちら](https://www.youtube.com/watch?v=hxGOiiR9ZKg)が充実しています。
## 小さなメソッド、クラス、モジュールが多すぎる
> この文脈では、メソッド、クラス、モジュールは交換可能です
@@ -119,7 +119,7 @@ stuff // 🧠+
<img src="/img/deepmodulev8.png" alt="深いモジュール" width="700">
</div>
浅いモジュールが多すぎると、プロジェクトを理解するのが困難になる可能性があります。**各モジュールの責任を頭に置くだけでなく、それらすべてのインタラクションも把握する必要があります**。浅いモジュールの目的を理解するために、まずすべての関連モジュールの機能を調べる必要があります。そのような浅いコンポーネント間をジャンプするのは精神的に疲れます。<a target="_blank" href="https://blog.separateconcerns.com/2023-09-11-linear-code.html">線形思考</a>は私たち人間にとってより自然です。
浅いモジュールが多すぎると、プロジェクトを理解するのが困難になる可能性があります。**各モジュールの責任を頭に置くだけでなく、それらすべてのインタラクションも把握する必要があります**。浅いモジュールの目的を理解するために、まずすべての関連モジュールの機能を調べる必要があります。そのような浅いコンポーネント間をジャンプするのは精神的に疲れます。人間は<a target="_blank" href="https://blog.separateconcerns.com/2023-09-11-linear-code.html">線形に読む</a>のが自然です。
> 情報隠蔽は最重要であり、浅いモジュールでは複雑性をそれほど隠せません。
@@ -139,11 +139,11 @@ lseek(fd, offset, referencePosition)
close(fd)
```
このインターフェースの現代的な実装は**数十万行のコード**を持ちます。多くの複雑性がフードの下に隠されています。しかし、シンプルなインターフェースのおかげで使いやすいのです。
このインターフェースの現代的な実装は**数十万行のコード**を持ちます。多くの複雑性が内部に隠蔽されています。しかし、シンプルなインターフェースのおかげで使いやすいのです。
> この深いモジュールの例は、John K. Ousterhoutの[A Philosophy of Software Design](https://web.stanford.edu/~ouster/cgi-bin/book.php)から取られました。この本はソフトウェア開発における複雑性の本質をカバーするだけでなく、Parnasの影響力のある論文[On the Criteria To Be Used in Decomposing Systems into Modules](https://www.win.tue.nl/~wstomv/edu/2ip30/references/criteria_for_modularization.pdf)の最高の解釈も提供します。どちらも必読です。関連読み物：[A Philosophy of Software Design vs Clean Code](https://github.com/johnousterhout/aposd-vs-clean-code)、[It's probably time to stop recommending Clean Code](https://qntm.org/clean)、[Small Functions considered Harmful](https://copyconstruct.medium.com/small-functions-considered-harmful-91035d316c29)。
P.S. 責任が多すぎる肥大化したGodオブジェクトを支持していると思われるなら、それは間違いです。
P.S. 責任が多すぎる肥大化したGodオブジェクト（神オブジェクト）を支持していると思われるなら、それは間違いです。
## 一つのことに責任を持つ
あまりにもしばしば、曖昧な「モジュールは一つの、そして唯一の一つのことに責任を持つべき」原則に従って、多くの浅いモジュールを作ることになります。このぼんやりとした「一つのこと」とは何でしょうか？オブジェクトをインスタンス化することは一つのことでしょうか？だから[MetricsProviderFactoryFactory](https://minds.md/benji/frameworks)は問題ないように見えます。**そのようなクラスの名前とインターフェースは、実装全体よりも精神的に負荷が大きくなる傾向があります。それはどのような抽象化でしょうか？** 何かが間違っています。
@@ -157,13 +157,13 @@ P.S. 責任が多すぎる肥大化したGodオブジェクトを支持してい
しかし今でも、この規則は害を与える可能性があります。この原則は個人の数だけ異なる方法で理解される可能性があります。より良いアプローチは、それがどのくらいの認知負荷を作り出すかを見ることです。一箇所での変更が異なるビジネス領域間で連鎖反応を引き起こす可能性があることを覚えておくのは、精神的に負荷が大きいです。それだけのことで、学ぶべき難しい用語はありません。
## 浅いマイクロサービスが多すぎる
この浅い-深いモジュール原則はスケールに依存せず、マイクロサービスアーキテクチャにも適用できます。浅いマイクロサービスが多すぎても良いことはありません - 業界は多少「マクロサービス」、つまりそれほど浅くない（=深い）サービスに向かっています。最悪で修正が困難な現象の一つは、いわゆる分散モノリスで、これはしばしばこの過度に粒度の細かい浅い分離の結果です。
この浅い-深いモジュール原則はスケールに依存せず、マイクロサービスアーキテクチャにも適用できます。浅いマイクロサービスが多すぎるのは良くありません - 業界は多少「マクロサービス」、つまりそれほど浅くない（=深い）サービスに向かっています。最悪で修正が困難な現象の一つは、いわゆる分散モノリスで、これはしばしばこの過度に粒度の細かい浅い分離の結果です。
かつて、5人の開発者チームが17個（！）のマイクロサービスを導入したスタートアップをコンサルティングしました。彼らは10ヶ月スケジュールが遅れていて、パブリックリリースには程遠い状態でした。新しい要件のたびに4つ以上のマイクロサービスでの変更が必要でした。そのような分散システムで問題を再現しデバッグするには膨大な時間がかかりました。市場投入時間と認知負荷の両方が許容できないほど高かったのです。`🤯`
これは新しいシステムの不確実性に対する正しいアプローチでしょうか？最初に正しい論理的境界を引き出すことは非常に困難です。重要なのは、情報が最も多い時点まで責任を持って待てるだけ決定を遅らせることです。最初にネットワーク層を導入することで、最初から設計決定を元に戻すのを困難にしています。チームの唯一の正当化は：「FAANG企業がマイクロサービスアーキテクチャが効果的であることを証明した」でした。**夢を覚まして現実を見ましょう。**
これは新しいシステムの不確実性に対する正しいアプローチでしょうか？最初に正しい論理的境界を引き出すことは非常に困難です。重要なのは、情報が最も多い時点まで責任を持って待てるだけ決定を遅らせることです。最初にネットワーク層を導入することで、最初から設計決定を元に戻すのを困難にしています。チームの唯一の正当化は：「FAANG企業がマイクロサービスアーキテクチャが効果的であることを証明した」でした。**現実に立ち返りましょう。**
[Tanenbaum-Torvalds討論](https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate)では、Linuxのモノリシック設計が欠陥があり時代遅れであり、代わりにマイクロカーネルアーキテクチャを使うべきだと主張されました。確かに、マイクロカーネル設計は「理論的で美的な」観点から優れているように見えました。実用的な側面では - 30年経った今、マイクロカーネルベースのGNU Hurdはまだ開発中で、モノリシックなLinuxがどこにでもあります。このページはLinuxで動いており、あなたのスマートティーポットもLinuxで動いています。モノリシックなLinuxで。
[Tanenbaum-Torvalds討論](https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate)では、Linuxのモノリシック設計が欠陥があり時代遅れであり、代わりにマイクロカーネルアーキテクチャを使うべきだと主張されました。確かに、マイクロカーネル設計は「理論的で美的な」観点から優れているように見えました。実用的な側面では――30年経った今、マイクロカーネルベースのGNU Hurdはまだ開発中で、モノリシックなLinuxが至る所で使われています。このページはLinuxで動いており、あなたのスマートティーポットもLinuxで動いています。モノリシックなLinuxで。
本当に分離されたモジュールを持つ良く作られたモノリスは、多くのマイクロサービスよりもはるかに柔軟であることが多いです。また、維持するのに必要な認知的努力もはるかに少なくなります。開発チームのスケーリングなど、別々のデプロイメントの必要性が重要になった場合にのみ、モジュール間、将来のマイクロサービス間にネットワーク層を追加することを検討すべきです。
@@ -189,7 +189,7 @@ P.S. 責任が多すぎる肥大化したGodオブジェクトを支持してい
自明な型のためのスペースを割り当て、そこに一連のバイトを<code>memcpy</code>するだけでは、追加の努力なしにはオブジェクトの生存期間を開始できません。これはC++20以前の場合でした。C++20で修正されましたが、言語の認知負荷は増加しただけです。<br><br>
物事が修正されても認知負荷は常に増加しています。私はプロとして、何が修正されたか、いつ修正されたか、以前はどうだったかを知っている必要があります。確かに、C++はレガシーサポートが得意で、それはあなたが<b>そのレガシーに直面する</b>ことも意味します。例えば、先月同僚がC++03でのある動作について尋ねました。<code>🤯</code><br><br>
初期化の方法は20通りありました。統一初期化構文が追加されました。今は21通りの初期化方法があります。ところで、初期化リストからコンストラクタを選択する規則を覚えていますか？情報の損失が最小の暗黙変換についてのもので、<i>しかし値が静的に分かっている場合は</i>、それから... <code>🤯</code><br><br>
<b>この増加した認知負荷は、手元のビジネスタスクによるものではありません。それはドメインの本質的な複雑性ではありません。歴史的な理由で存在しているだけです</b>（<i>外発的認知負荷</i>）。<br><br>
<b>この増加した認知負荷は、手元のビジネスタスクによるものではありません。それはドメインの本質的な複雑性ではありません。歴史的な理由で存在しているだけです</b>（<i>外在的認知負荷</i>）。<br><br>
私はいくつかのルールを決める必要がありました。例えば、そのコード行が明らかでなく、標準を覚えなければならない場合は、そのように書かないほうが良いです。ちなみに、標準は約1500ページの長さです。<br><br>
<b>決してC++を非難しようとしているのではありません。</b>私はこの言語を愛しています。ただ、今は疲れているのです。<br><br>
<p><a href="https://0xd34df00d.me" target="_blank">0xd34df00d</a>に執筆していただき、ありがとうございます。</p>
@@ -197,20 +197,20 @@ P.S. 責任が多すぎる肥大化したGodオブジェクトを支持してい
## ビジネスロジックとHTTPステータスコード
バックエンドで以下を返します：
`401` 期限切れjwtトークンの場合
`401` 期限切れJWTトークンの場合
`403` アクセス権限不足の場合
`418` 禁止されたユーザーの場合
`418` 利用停止中のユーザーの場合
フロントエンドのエンジニアは、バックエンドAPIを使用してログイン機能を実装します。彼らは一時的に以下の認知負荷を脳内で作成する必要があります：
`401`は期限切れjwtトークンの場合 // `🧠+`、一時的に覚えておく
フロントエンドのエンジニアは、バックエンドAPIを使用してログイン機能を実装します。彼らは一時的に以下の認知負荷を頭の中に保持しなければなりません：
`401`は期限切れJWTトークンの場合 // `🧠+`、一時的に覚えておく
`403`はアクセス権限不足の場合 // `🧠++`
`418`は禁止されたユーザーの場合 // `🧠+++`
`418`は利用停止中のユーザーの場合 // `🧠+++`
フロントエンド開発者は（願わくば）彼らの側で何らかの`数値ステータス -> 意味`辞書を導入し、後続の貢献者世代がこのマッピングを脳内で再作成する必要がないようにするでしょう。
フロントエンド開発者は（願わくば）彼らの側で何らかの`数値ステータス → 意味`辞書を導入し、後続の貢献者世代がこのマッピングを頭の中で再構築する必要がないようにするでしょう。
それからQAエンジニアが登場します：
「やあ、`403`ステータスを受け取ったけど、これは期限切れトークンなの、それともアクセス権限不足なの？」
**QAエンジニアは、バックエンドのエンジニアがかつて作成した認知負荷を再作成しなければならないので、すぐにテストに飛び込むことができません。**
**QAエンジニアは、バックエンドのエンジニアがかつて作成した認知負荷を再構築しなければならないので、すぐにテストに飛び込むことができません。**
なぜこのカスタムマッピングをワーキングメモリに保持するのでしょうか？ビジネス詳細をHTTP転送プロトコルから抽象化し、レスポンスボディに自己記述的なコードを直接返すほうが良いです：
```json
@@ -224,7 +224,7 @@ QA側の認知負荷：`🧠`
同じ規則があらゆる数値ステータス（データベースやその他の場所）に適用されます - **自己記述的な文字列を好みましょう**。メモリを最適化するための640Kコンピューターの時代ではありません。
> 人々は`401`と`403`の間で議論し、自分の心的モデルに基づいて決定を下すのに時間を費やします。新しい開発者が入ってきて、その思考プロセスを再作成する必要があります。コードの「なぜ」（ADR）を文書化して、新参者が下された決定を理解できるようにしているかもしれません。しかし結局のところ、それは全く意味をなしません。エラーをユーザー関連またはサーバー関連に分離することはできますが、それ以外は物事がぼやけています。
> 人々は`401`と`403`の間で議論し、自分の心的モデルに基づいて決定を下すのに時間を費やします。新しい開発者が入ってきて、その思考プロセスを再構築する必要があります。コードの「なぜ」（ADR）を文書化して、新参者が下された決定を理解できるようにしているかもしれません。しかし結局のところ、それは全く意味をなしません。エラーをユーザー関連またはサーバー関連に分離することはできますが、それ以外は物事がぼやけています。
P.S. 「認証」と「認可」を区別するのはしばしば精神的に負荷が大きいです。認知負荷を減らすために、[「ログイン」と「権限」](https://ntietz.com/blog/lets-say-instead-of-auth/)のようなより簡単な用語を使うことができます。
@@ -242,7 +242,7 @@ Rob Pikeはかつて言いました：
車輪を再発明しないことに強く惑わされ、私たち自身で簡単に書けるような小さな関数を使うために大きくて重いライブラリをインポートしがちです。
**すべての依存関係はあなたのコードです。** インポートされたライブラリの10以上のレベルのスタックトレースを通して何が悪かったかを把握する（*物事は悪化するから*）のは苦痛です。
**すべての依存関係は実質的に「あなたのコード」です。** インポートされたライブラリの10以上のレベルのスタックトレースを通して何が悪かったかを把握する（*物事は悪化するから*）のは苦痛です。
## フレームワークとの密結合
フレームワークには多くの「魔法」があります。フレームワークに過度に依存することで、**すべての今後の開発者にその「魔法」を最初に学ばせることを強制します**。それには数ヶ月かかることがあります。フレームワークによって数日でMVPを起動できますが、長期的にはそれらは不要な複雑性と認知負荷を追加する傾向があります。
@@ -251,7 +251,7 @@ Rob Pikeはかつて言いました：
**決してすべてをゼロから発明することを提唱しているのではありません！**
私たちは多少フレームワークに依存しない方法でコードを書くことができます。ビジネスロジックはフレームワーク内に存在すべきではありません。むしろ、フレームワークのコンポーネントを使用すべきです。フレームワークをコアロジックの外側に置きます。フレームワークをライブラリのような方法で使用します。これにより、新しい貢献者はまずフレームワーク関連の複雑性の残骸を通過する必要なしに、初日から価値を追加できるようになります。
私たちは多少フレームワークに依存しない方法でコードを書くことができます。ビジネスロジックはフレームワーク内に存在すべきではありません。むしろ、フレームワークのコンポーネントを使用すべきです。フレームワークをコアロジックの外側に置きます。フレームワークをライブラリのような方法で使用します。これにより、新しい貢献者はまずフレームワーク関連の複雑性の層をかいくぐる必要なしに、初日から価値を追加できるようになります。
> [Why I Hate Frameworks](https://minds.md/benji/frameworks)
@@ -260,9 +260,9 @@ Rob Pikeはかつて言いました：
私自身、何年もヘキサゴナル/オニオンアーキテクチャの情熱的な提唱者でした。あちこちで使用し、他のチームにも勧めました。プロジェクトの複雑性が上がり、ファイル数だけでも倍増しました。多くのグルーコードを書いているように感じました。絶え間なく変化する要件に対して、複数の抽象化レイヤーにわたって変更を行う必要があり、結局それはすべて面倒になりました。`🤯`
抽象化は複雑性を隠すことになっていますが、ここではただ[間接性](https://fhur.me/posts/2024/thats-not-an-abstraction)を追加しているだけです。何が悪くて何が欠けているかを把握するために、呼び出しから呼び出しへとジャンプしなければならないのは、問題を迅速に解決する上で重要でありながら、負担が大きいです。このアーキテクチャのレイヤー分離では、障害が発生するポイントにたどり着くために指数関数的に余分で、しばしばばらばらなトレースが必要です。そのようなトレースはそれぞれ、私たちの限られたワーキングメモリのスペースを占有します。`🤯`
抽象化は複雑性を隠すことになっていますが、ここではただ[間接性](https://fhur.me/posts/2024/thats-not-an-abstraction)を追加しているだけです。何が悪くて何が欠けているかを把握するために、呼び出しから呼び出しへとジャンプしなければならないのは、問題を迅速に解決する上で重要でありながら、負担が大きいです。このアーキテクチャのレイヤー分離では、障害が発生するポイントにたどり着くために余計な手間が指数関数的に増え、トレースも断片的になりがちです。そのようなトレースはそれぞれ、私たちの限られたワーキングメモリのスペースを占有します。`🤯`
このアーキテクチャは最初は直感的に理にかなっているように見えましたが、プロジェクトに適用しようとするたびに、良いことよりもはるかに害をなしました。最終的に、古き良き依存性逆転原則を支持して、すべてを諦めました。**学ぶべきポートやアダプター、不要な水平抽象化、外発的認知負荷、それらは必要ありません**
このアーキテクチャは最初は直感的に理にかなっているように見えましたが、プロジェクトに適用しようとするたびに、良いことよりもはるかに害をなしました。最終的に、古き良き依存関係逆転原則(DIP)を支持して、すべてを諦めました。**学ぶべきポートやアダプター、不要な水平抽象化、外在的認知負荷、それらは必要ありません**
<details>
<summary><b>コーディング原則と経験</b></summary>
@@ -281,7 +281,7 @@ Rob Pikeはかつて言いました：
**では、そのようなレイヤードアーキテクチャの高い認知負荷の代価を支払うのはなぜでしょうか、それが将来報われないのであれば？** さらに、ほとんどの場合、いくつかのコアコンポーネントを置き換えるその未来は決して起こりません。
これらのアーキテクチャは基本的ではなく、より基本的な原則の主観的で偏った結果にすぎません。なぜそれらの主観的な解釈に依存するのでしょうか？代わりに基本的な規則に従いましょう：依存性逆転原則、単一の真実の源、認知負荷、情報隠蔽。私たちのビジネスロジックは、データベース、UI、フレームワークなどの低レベルモジュールに依存すべきではありません。インフラストラクチャを心配することなくコアロジックのテストを書けるべきで、それだけです。[議論](https://github.com/zakirullin/cognitive-load/discussions/24)。
これらのアーキテクチャは基本的ではなく、より基本的な原則の主観的で偏った結果にすぎません。なぜそれらの主観的な解釈に依存するのでしょうか？代わりに基本的な規則に従いましょう：依存関係逆転原則、単一の真実の源、認知負荷、情報隠蔽。私たちのビジネスロジックは、データベース、UI、フレームワークなどの低レベルモジュールに依存すべきではありません。インフラストラクチャを心配することなくコアロジックのテストを書けるべきで、それだけです。[議論](https://github.com/zakirullin/cognitive-load/discussions/24)。
アーキテクチャのために抽象化レイヤーを追加してはいけません。実用的な理由で正当化される拡張ポイントが必要なときにそれらを追加しましょう。
@@ -296,7 +296,7 @@ Rob Pikeはかつて言いました：
ユビキタス言語、ドメイン、境界づけられたコンテキスト、集約、イベントストーミングはすべて問題空間に関するものです。それらはドメインについての洞察を学び、境界を抽出するのを助けることを意図しています。DDDは開発者、ドメインエキスパート、ビジネス関係者が単一の統一された言語を使って効果的にコミュニケーションを取ることを可能にします。DDDのこれらの問題空間の側面に焦点を当てる代わりに、私たちは特定のフォルダ構造、サービス、リポジトリ、その他のソリューション空間技術を強調する傾向があります。
私たちがDDDを解釈する方法が独特で主観的である可能性があります。そして、この理解の上にコードを構築する場合、つまり、多くの外発的認知負荷を作り出す場合 - 将来の開発者は運命づけられています。`🤯`
私たちがDDDを解釈する方法が独特で主観的である可能性があります。そして、この理解の上にコードを構築する場合、つまり、多くの外在的認知負荷を作り出す場合 - 将来の開発者は運命づけられています。`🤯`
Team Topologiesは、認知負荷をチーム間で分割するのに役立つはるかに良い、理解しやすいフレームワークを提供します。エンジニアはTeam Topologiesについて学んだ後、多少似たような心的モデルを開発する傾向があります。一方、DDDは10人の異なる読者に対して10の異なる心的モデルを作り出すように見えます。共通の基盤になる代わりに、不要な議論の戦場になります。
@@ -339,7 +339,7 @@ Team Topologiesは、認知負荷をチーム間で分割するのに役立つ
## 結論
ちょっと想像してみてください。もし第2章で推論したことが実は正しくなかったとしたらどうなるでしょう？ その場合、いま否定した結論だけでなく、これまで正しいと受け入れてきた前章の結論までも、正しくないかもしれません。🤯
実感できますか？ 意味を理解するために記事のあちこちを行き来しなければならず（＝浅いモジュール！）、しかも全体としてとても分かりにくい段落になっています。私たちは、あなたの頭に余計な認知負荷をつくり出してしまったのです。**同僚にこのようなことをしてはいけません。**
実感できますか？ 意味を理解するために記事のあちこちを行き来しなければならず（＝浅いモジュール！）、しかも、全体としてとても分かりにくい段落になっています。私たちは、あなたの頭に余計な認知負荷をつくり出してしまったのです。**同僚にこのようなことをしてはいけません。**
<div align="center">
<img src="/img/smartauthorv14thanksmari.png" alt="賢い著者" width="600">
@@ -360,7 +360,7 @@ Team Topologiesは、認知負荷をチーム間で分割するのに役立つ
<p><strong><a href="https://x.com/elonmusk/status/1872346903792566655" target="_blank">Elon Musk</a></strong><br>真実だ。</p>
<p><strong><a href="https://www.linkedin.com/feed/update/urn:li:activity:7277757844970520576/" target="_blank">Addy Osmani</a></strong> <i>(Chrome、世界で最も複雑なソフトウェアシステム)</i><br>賢い開発者が最新の設計パターンとマイクロサービスを使って印象的なアーキテクチャを作成した無数のプロジェクトを見てきました。しかし、新しいチームメンバーが変更を加えようとしたとき、すべてがどのように組み合わさるかを理解するのに何週間も費やしました。認知負荷がとても高く、生産性が急落し、バグが倍増しました。</p>
<p>皮肉なことに？これらの複雑性を誘発するパターンの多くは「クリーンコード」の名の下に実装されていました。</p>
<p>本当に重要なのは、不要な認知的負担を減らすことです。時には多くの浅いモジュールではなく、より少ない深いモジュールを意味することもあります。時には小さな関数に分割するのではなく、関連するロジックを一緒に保つことを意味することもあります。</p>
<p>本当に重要なのは、不要な認知負荷を減らすことです。時には多くの浅いモジュールではなく、より少ない深いモジュールを意味することもあります。時には小さな関数に分割するのではなく、関連するロジックを一緒に保つことを意味することもあります。</p>
<p>そして時には賢いものよりも退屈で素直な解決策を選ぶことを意味します。最高のコードは最もエレガントで洗練されたものではありません - 将来の開発者（あなた自身を含む）が迅速に理解できるコードです。</p>
<p>あなたの記事は、ブラウザ開発で私たちが直面する課題と本当に共鳴します。認知負荷について言った多くのポイントと完璧に一致する、現代のブラウザが最も複雑なソフトウェアシステムの一つであることについて、あなたは絶対に正しいです。</p>
<p>Chromiumでこれを処理しようとする一つの方法は、慎重なコンポーネント分離とサブシステム間（レンダリング、ネットワーキング、JavaScript実行など）の明確に定義されたインターフェースです。Unix I/Oでの深いモジュールの例と似ています - 比較的シンプルなインターフェースの背後にある強力な機能を目指しています。例えば、私たちのレンダリングパイプラインは信じられないほどの複雑性（レイアウト、合成、GPUアクセラレーション）を処理しますが、開発者は明確な抽象化レイヤーを通してそれと相互作用できます。</p>