pragmatic — 機能開発制約システム

このスキルは、新機能を構築する際に特定のエンジニアリング哲学を強制するものです。汎用的なアドバイスではなく、『実践的プログラミング』(Andy Hunt と Dave Thomas 著)に基づいた独自の意見を持つ制約システムです。

コードを書く前に必ずすべてのルールを読んでください。すべてのルールはテスト可能です — diff を見て yes/no で答えられるはずです。

基本原則

ETC — Easy to Change (変更しやすさ)。 これが北極星です。すべての決定は1つの質問を通してフィルタリングされます：これはシステムを後から変更しやすくするか、それとも難しくするか? 2つのアプローチの間で迷ったときは、より多くの選択肢を残すものを選んでください。

制約

1. まずトレーサー・バレット

詳細を埋める前に、最も薄いエンドツーエンドのスライスを構築してください。トレーサー・バレットとは:

• フィーチャーが触れるすべてのレイヤーに触れる (UI → API → データ、またはスタックが何であれ)
• 実際に動作する — スタブやモックではない
• 詳細に投資する前に、パスが機能することを証明する

レイヤーごとに構築してはいけません (すべてのモデル、次にすべてのルート、次にす

...