Japanese Translation:

この文書は、単純さを優先し、健全なアーキテクチャと基本的なパフォーマンス知識に注力することを通じて、高品質で保守可能なソフトウェアを構築することに焦点を当てたエンジニアリングリーダーおよびプログラマー向けの厳選された読書リストを提供しています。この哲学の中心には、「複雑さは悪い」という原則（または YAGNI 原則：You Ain't Gonna Need It）に沿って不必要な複雑性を拒否する姿勢と、オブジェクト型のプロパティをエンコードすることによりランタイムでバリデーションするのではなく、データ入力を「解析し、検証しない」という重要な指針があります。

主要な推奨事項には、「Grug Brained Developer」とスティーブ・イエッグの『Google Platforms Rant』といった特定のエッセイが含まれており、これらはチーム組織、アクセシビリティ、サービスの公開を向上させながら一般的な落とし穴を回避する手法を提供します。ガイドは、オブジェクトリレーショナルマッパー（ORM）に盲目的に依存することを警告し、OpenAI が Postgres で直面した最近のスケーリング課題を顕著な例として挙げています。開発者は、非同期関数内でブロック呼び出しを防ぎ効率を確保するために生成された SQL コードを手動でレビューするように促されており、「asyncio の概念的概要」やボブ・ニストロムによる『What Color is your Function?』などのリソースが活用されています。さらに、この文書では命令型のバックエンドロジックと、フロントエンドコンポーネントに求められる純粋な宣言的な性質を区別しています。HATEOAS という高度なパターンを採用してステート管理を行うことや、標準的なページネーションではなく「結果のページネーション（Paging Through Results）」を利用することは、システムのパフォーマンスをさらに高めることができます。最後に、

useMemo

のようなフックの誤用を避けることが強調されています。最終的には、これらの実践を実施することで堅牢なコードベースを実現し、混乱を減らし、バックエンドロジックとフロントエンドステート管理の双方において危険なアンチパターンを回避できるようエンジニアリングチームを強化できます。

カル氏必読リスト：エンジニアリングリーダーによる良質なソフトウェアの視座

エンジニアリングリーダーとしてチームに共有する「必読リスト」です。過去の経験から得た知恵を活用して、現在の課題を解決するためのヒントを得ていただければ幸いです。異なる意見をお持ちの方も自由ですが、どこか価値ある教訓を見つけられることを願っています。

※ 技術的な内容のため、プログラマーとして向き合ってください。私が愛用している記事には ★（星印） をつけています。

📜 コーディング慣習

⭐ The Grug Brained Developer
- 新米からベテランまで誰にでもお勧めする唯一の記事です。
- 核心メッセージ: 「複雑さは悪しきもの」。
The Wrong Abstraction（誤った抽象化）
- コード重複を目に見て統合しようとするのは危険な場合があります。
- オブジェクト指向のファクタリングにおいて、あえて分離すべき状況を理解するために必読です。
- 自動化工具による「単一の真実源」作りを盲目的に追うのではなく、文脈に応じて判断する重要性を説いています。
Complexity Budget（複雑性予算）
- プロジェクトの複雑性が限界を超えると、進捗が急激に止まります。
- この現象を理解し、複雑性の増加を長期間先送りするための戦略について論じています。
Locality of Behavior（振る舞いの局所性）
- 「関心の分離」追求や「コード再利用」のために多数のヘルパー関数を作ると、全体像が失われます。
- トレードオフを理解する: その単一ユニットだけを眺めた際にも、コードの振る舞いが直感的に明白であることを最優先すべきです。
YAGNI（You Ain't Gonna Need It／必要になるはずがない）
- 将来の推測に基づき機能を実装するのは基本的に悪いアイデアです。
- 必要な時だけ実装することが原則です。
Parse, Don't Validate（パースせよ、検証するな）
- データの性質を保証したいなら、タイプ定義自体にその性質をエンコードしてください。
- ```
assertion
```
  のような実行時エラーではなく、コンパイル時にタイプエラーとして早期発見できます。

🛠️ プラットフォーム構築

⭐ Steve Yegge's Google Platforms Rant
- アクセシビリティやソフトウェア組織の設立など、非常に優れた内容が満載です。
- 「すべての企業が Bezos マンデート（絶対服従）を強制すべきか」という点については推奨しませんが、自分のサービス機能を他チームにプログラム公開する際は慎重に検討する必要があります。
- 読んだだけでも楽しい一読の価値があります。

🌐 フロントエンド

⭐ HATEOAS
- 従来の状態（State）管理（React の
```
useState
```
  など）とは異なり、HTML に直接状態とアクションを含めるアプローチです。
- ユーザーが実行可能な行動を HTML から導き出す方が合理的な場合が多いです。
- REST API の本来の概念に近く、現代の多くの「REST」実装がこれを無視している現状への指摘でもあります。
Components and Hooks must be pure（コンポーネントとフックは純粋であるべき）
- React で直面する最大の問題は、バックエンド特有の命令型アプローチです（過度な状態管理や副作用）。
- フロントエンドは宣言的アプローチを取るべきです。「何を欲しいか」を伝え、「どうやるか」を指示しない。
- 現代 React は関数型プログラミングスタイルを採用しており、不必要な箇所では副作用を避け、必要ならフックを使用します。
Understanding useMemo and useCallback
- ```
useMemo
```
  と
```
useCallback
```
  の誤用が最も多いフックです（人間もエージェントも同様）。
- これらが実際に必要な場面と使い方のガイドラインを提供しています。
Hypermedia Systems - Components of a Hypermedia System
- HTML を基盤とするモデルを深く理解することは、優れたフロントエンド開発の鍵です。
- HTML を単なるレガシーなマークアップ言語として見ず、ブラウザのデザインを最大限に活用するための助けになります。

💾 データベース

⭐ The Vietnam of Computer Science
- 認定された「ORM 嫌い」としての推奨記事です。
- ORM は新規プロジェクトで誘惑的ですが、すぐにパフォーマンス問題や混乱を引き起こします（例：OpenAI の Postgres スケーリング記事）。
- ORM 生成の SQL を慎重にレビューし、期待通りの動作を保証する必要性を説いています。
Wikipedia - The Object-Relational Impedence Mismatch（オブジェクトリレーショナル不整合）
- ORM 批判への補足です。
- より技術的で簡潔な解説であり、要点のみを知りたい場合に最適です。
Introduction to PostGIS - Geography
- マップベースの可視化ツール開発において必須知識です。
- PostGIS の基礎となるデータタイプは geography
  です。
Postgres Docs Chapter 14 - Performance Tips
- データベースが低速化し始めた際に読むべき記事です。
- ```
EXPLAIN
```
  と
```
EXPLAIN ANALYZE
```
  を使うことは、デバッガーを使うことと同程度に重要です。
Paging Through Results
- 大量データのページネーションにおいて、単純な
```
LIMIT
```
  +
```
OFFSET
```
  は高番号のページで劇的に遅くなります。
- この問題と代替案についての優れた解説です。

🔄 非同期プログラミング

A Conceptual Overview of asyncio
- 単に書き方を覚えても理解が追いつかず、ブロッキング呼び出しなどのミスを犯しやすいです。
- ```
asyncio
```
  の内部メカニズムを理解し、最も適切に使用する方法を学べる優れたドキュメントです。
What Color is your Function?
- 非同期プログラミングシステムが根本的な欠陥を持つことを示しています。
- これらの制限はスキル不足ではなく本質的な問題であることを理解するのに役立ちます。言語を変える他に対処策はありません。

🔤 エンコーディング

The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
- キャリアの早い段階で読むべきです。
- インターネット上のデータを誤ってパースするのを防ぎ、数百時間のトラブルを防ぎます。

📚 書籍推薦

これらは私の思考に深く影響を与えた本です。

The Design of Everyday Things（アマゾン）
- デザインとは「美しいものを作る」ではなく、ユーザーのニーズを先回りして満たすことです。
- 矛盾が生じる場合は、機能性（ニーズの充足）を優先してください。
- 冒頭の「ノルマンドア（Norman Doors）」の例がその皮肉をよく表しています。
Designing Data-Intensive Applications（オライリー / アマゾン）
- データシステムの本質を深く理解させるための優れた入門書です。
- 数億人のユーザーがいる場合でも、何を最適化するべきか考える力を養います。
- 特に 第 7 章（トランザクション） と 第 10 章（バッチ処理） は必読です。
Crafting Interpreters（無料・オンライン）
- 楽しく、励ましのあるインタプリタ構築の入門書です。
- シンプルさのために Java、パフォーマンスのために C を使いつつ段階的に学びます。
- 脳をより活発に使うために、自分の好きな言語でインタプリタを実装するのが最も効果的です（著者は Rust を使用）。
Category Theory for Programmers（無料・オンライン / ハードカバー）
- 少し硬核ですが、カテゴリー理論への最高の入門書です。
- 「ファンクター」「モナド」などの概念を使いこなすことで、より良い関数型コードを書けます。
- 厳密さを求める場合は、形式的定義については Google で補足確認してください。
The Mythical Man-Month（アマゾン）
- 1975 年刊で今も非常に relevan t です（2024 年現在）。
- AI ツールが普及した現代でも、特に「システム設計における貴族制と民主主義」などの章はより現実に即しています。
- プロジェクトを管理し成功させたい方必読です。

カルルの必読リスト