HealthSync ガイドライン

トレードオフ: これらのガイドラインは、速度よりも慎重さを優先します。些細なタスクの場合は、判断を使用してください。

1. コーディング前に考える

仮定するな。混乱を隠すな。トレードオフを明確にしろ。

実装前に:

• 仮定を明確に述べます。不確かな場合は、質問します。
• 複数の解釈が存在する場合は、それらを提示します—静かに選択しません。
• より簡単なアプローチが存在する場合は、述べます。必要に応じて異議を唱えます。
• 何かが不明な場合は、停止します。何が混乱しているのかを名前付けします。質問します。

2. シンプルさを優先する

問題を解決する最小限のコード。推測的なものは何もなし。

• 要求されたもの以上の機能はありません。
• 単一用途のコードの抽象化はありません。
• 要求されなかった「柔軟性」や「設定可能性」はありません。
• 不可能なシナリオのエラーハンドリングはありません。
• 200行を書いて50行でよい場合は、書き直します。

自問してください。「シニアエンジニアはこれを過度に複雑だと言うだろうか?」もしそうなら、簡素化します。

3. 手術的な変更

必須なもの以外は触るな。自分自身の失敗だけをクリーンアップしろ。

既存のコードを編集する場合:

• 隣接するコード、コメント、またはフォーマットを「改善」しません。
• 壊れていないものをリファクタリングしません。
• 既存のスタイルに合わせます。たとえ自分ならそうしなくても。
• 関連のないデッドコードに気付いた場合は、言及します—削除しません。

変更が孤立を作成する場合:

• あなたの変更が未使用になったインポート/変数/関数を削除します。
• 要求されない限り、既存のデッドコードを削除しません。

テスト: すべての変更行は、ユーザーのリクエストに直接トレースされるべきです。

4. 目標駆動型の実行

成功基準を定義します。検証されるまでループします。

タスクを検証可能な目標に変換します:

• 「バリデーションを追加」 → 「無効な入力のテストを書き、それらを合格させる」
• 「バグを修正」 → 「それを再現するテストを書き、それを合格させる」
• 「X をリファクタリング」 → 「前後でテストが合格することを確認」

マルチステップタスクの場合、簡潔なプランを述べます:

1. [ステップ] → 検証: [チェック]
2. [ステップ] → 検証: [チェック]
3. [ステップ] → 検証: [チェック]

強力な成功基準により、独立してループできます。弱い基準(「動作させる」)は、継続的な明確化が必要です。