カールが選ぶ必読記事

カールが推奨する必読書 エンジニアリングリーダーとして、私はしばしばチームに記事を送り、それを冗談で「必読書」と呼んでいます。私の目標は、私たちと同じような課題に直面したであろう他のプログラマーの知恵の一部を消化するのを助けることです。多くの要望により、興味のある他の皆さんのために、このリストをここに掲載します！ ほとんどの記事がこのリストにあるのは、私が良いソフトウェアを作成する方法について重要または洞察に富むと考える点を述べているからです。ここにあるいくつかの点は、特定の事柄（例えば、ORMは悪であり、フロントエンドはシンプルであるべきだ）に関する私の意見を補強します。あなたは同意しないかもしれません！しかし、たとえ反対の意見を持つことになったとしても、少なくとも記事から何か価値あるものを得られることを願っています。 これらの記事は技術的なものであり、プログラマーでない場合は興味を持たないでしょう。このリストは少し圧倒されるかもしれませんが、お気に入りの記事には星印を付け、それぞれの記事がなぜ重要だと考えるかの簡単な要約も書いています。 コーディングプラクティス ⭐ グルッグ脳開発者 新米プログラマーにも経験豊富なプログラマーにも、もし1つの記事しか推薦できないとしたら、これです。複雑さは悪です。 間違った抽象化 コードの重複を見て、すぐにそれをどこかに統合して排除しようとする誘惑に駆られることがあります。このエッセイは、2014年のオブジェクト指向コードのファクタリングに関する講演を基にしており、これが適切でない状況について論じています。あらゆる場所に「単一の真実の情報源」を作成することに動機付けられたコーディングエージェントに対して効果的に反論するためには、これを理解する必要があります。 複雑性予算 プロジェクトが複雑になりすぎると、進捗は非常に突然止まるように見えます。このエッセイは、この現象を理解し、可能な限り長くそれを回避しようとすることについてです。 振る舞いの局所性 プログラマー（およびコーディングエージェント）は、しばしば関心の分離（SoC）を達成しようとしたり、多数のヘルパー関数を作成してコードの再利用を排除しようとしたりします。これと、その単一のユニットだけを見たときにコードの振る舞いを可能な限り明白にする原則である「振る舞いの局所性」との間にはトレードオフがあります。 ヤグニ（YAGNI - 必要になるまでやらない） 将来を見越して投機的な機能を作成することは、基本的に常に悪い考えです。 検証ではなくパース これは理解するのに少し手間がかかりますが、基本的な考え方は、データの特定のプロパティを保証したいのであれば、そのプロパティをオブジェクトの型に直接エンコードすべきだということです。これにより、アサーションを壊すコードの変更は、実行時エラーではなく、コンパイル時に型エラーとしてスローされます。 プラットフォーム ⭐ スティーブ・イエガーのGoogleプラットフォーム論 ここには、特にアクセシビリティとソフトウェア組織のセットアップに関して、非常に多くの良い内容が含まれています。すべての企業がBezosの命令を強制することを推奨するわけではありませんが、サービスの特徴をプログラム可能な方法で他のチームに公開できるかどうかを批判的に考えるべきです。読むだけでも楽しいです。 フロントエンド ⭐ HATEOAS Webアプリケーションでは、状態はしばしばフロントエンドのマークアップとバックエンドの両方から分離されてエンコードおよび保存されます（例: ReactのuseState）。多くの場合、状態とユーザーが許可するアクションを、ユーザーに提供されるHTMLから直接保存および派生させる方が理にかなっています。これは、REST APIの元の概念と密接に関連しています（ほとんどの現代の「REST」APIは実際にはRESTの制約に従っていません）。私も自分のサイトでHATEOASについて簡単に書いています。 コンポーネントとフックは純粋であるべきです バックエンドコードからReactのコードを書くように移行する際に私がよく見る最大の問題は、命令型でフロントエンドを書こうとすることです。つまり、コンピュータに一行一行何をすべきかを指示しようとします。これは通常、オブジェクト指向プログラミングで一般的な状態と副作用の過剰な使用を伴います。代わりに、フロントエンドは宣言的であるべきです。つまり、コンピュータに何が欲しいかを伝えるべきです。これをサポートするために、（現代の）Reactは関数型プログラミングスタイルを中心に設計されています。すべてのコンポーネントは関数であり、状態と副作用は本当に必要な場合を除いて避けられ、その場合はフックが必要です。Reactのドキュメント全体を読むことをお勧めしますが、1つに集中したい場合はこれが最適です。 useMemoとuseCallbackの理解 useMemoとuseCallbackは、Reactで最も誤用されているフック（useEffectの次に）であり、エージェントも人間もいたるところにそれらを投入したがります。この記事は、それらが実際に必要とされる場所のガイドです。 ハイパーメディアシステム - ハイパーメディアシステムの構成要素 良いフロントエンドを書きたいのであれば、HTMLが基づいているモデルを理解することは非常に価値があります。これは、素晴らしい本の素晴らしい章であり、HTMLを「ますます完全にJavaScriptベースのWebアプリケーションでユーザーインターフェースを構築するために不本意ながら使用しなければならない、扱いにくいレガシーマークアップ言語」と見なすのではなく、ブラウザのデザインを最大限に活用するのに役立ちます。 データベース ⭐ コンピュータサイエンスのベトナム戦争 私はORM（Object-Relational Mapper）を否定する専門家です。新しいプロジェクトでは魅力的ですが、すぐにパフォーマンスの問題や混乱を引き起こし始めると考えています。例として、Postgresのスケーリングに関するOpenAIの記事をご覧ください。これらの問題のあるクエリの多くは、オブジェクトリレーショナルマッピングフレームワーク（ORM）によって生成されるため、それらが生成するSQLを注意深くレビューし、期待どおりに動作することを確認することが重要です。これは私が読んだ中で最高の反ORMエッセイであり、長文ですが、強くお勧めします。 Wikipedia - オブジェクトリレーショナルインピーダンスミスマッチ 私の反ORM運動のさらなる弾薬です。これはより技術的ですが、より簡潔なので、箇条書きだけを探している場合はこれを読むと良いでしょう。 PostGIS入門 - 地理 PostGIS（および地理空間データベース）は、慣れるのに少し時間がかかります。地図ベースのデータビジュアライザーを構築する際に、扱っている新しいデータ型を理解することは良いことです。PostGISは優れたデータベースであり、その基盤となるデータ型は地理です。 Postgresドキュメント 第14章 - パフォーマンスのヒント データベースが遅くなり始めたときに読んでおくと良い記事です。EXPLAINとEXPLAIN ANALYZEの使い方を知ることは、デバッガーの使い方を知ることと同等だと私は考えています。 Paging Through Results ほとんどの人は、ページネーションシステムを構築する際にLIMITとOFFSETを使用します。大量のデータをページングする場合、これらは遅くなります（特に高番号のページを読み込む場合）。これは、この問題に対処するための他のオプションの優れた概要です。私も自分のサイトでこのことについて話しています。 非同期プログラミング asyncioの概念的概要 多くの人は、非同期プログラミングにいきなり放り込まれ、何が起こっているのかを本当には理解せず、進めながら学習します。これはしばしば、非同期関数内でブロッキング呼び出しを行うような、非常に基本的なasyncioのミスにつながります。これはドキュメントからの良い記事であり、asyncioが内部で何をしているのかをより明確にし、それによってそれを最良の方法で使用する方法を教えてくれるはずです。 あなたの関数は何色ですか？ ボブ・ニストロムは私のお気に入りのプログラミング作家の1人です。これは、非同期プログラミングシステムが根本的な欠陥を抱えていることが多い例です。できることはあまりありません（別の言語を使用する以外は）が、これにより、遭遇する非同期プログラミングの制限の一部は、スキルの問題ではなく根本的なものであることが少なくともわかるでしょう。 エンコーディング ソフトウェア開発者が絶対に、絶対に知っておくべきUnicodeと文字セットのすべて（言い訳はしない！） キャリアの早い段階でこれを読んでいれば、インターネットから収集されたデータを不正確に解析するのに何百時間も節約できたでしょう。 書籍 これらの本は、私がプログラミング、デザイン、ソフトウェアプロジェクトの管理について感じていることを形作ってきました。 デザインの原理（The Design of Everyday Things）(Amazon) 多くの人は「デザイン」とは見た目を美しくすることだと考えているようです。実際、デザインとはユーザーのニーズを予測し、製品がそれらのニーズを可能な限り満たすようにすることです。多くの場合、デザインのこの第二の意味は第一の意味と相反しますが、そのような場合には第二を選択すべきです。初期の「ノーマン・ド