PHPビルトインサーバーのコードで改善できそうなこと

README.md

PHPビルトインサーバーのコードで改善できそうなこと

1. 命名規則の揺れ・プリフィックス統一の徹底

---

• normalize_vpath, append_http_status_line, add_response_header など、
  php_cli_server_ プレフィックスが抜けている関数のリネーミング

• 命名で“責務の曖昧さ”や“歴史的な継ぎ目”が発生している箇所を整理

• 「命名の揺れが密集する箇所」は設計の継ぎ目や負債になりやすい
  → どの層の責務か、明確にしたうえで一括リネームまたはファイル分割を検討

---

2. “グラデーション”部分の責務調査・明確化

• cli_header_value_dtor、get_last_error、status_comp など
  責務が分かりづらい関数群の「どこから呼ばれているか」「どの層に属すべきか」調査

• 設計ドキュメントやコメントで「グラデーション部分」と明示し、今後のリファクタ候補に

---

3. HTTPリクエスト/レスポンスの“対称性”の再設計

---

• 「request」に偏ったAPI設計・構造体命名の見直し

• response系の構造体や関数を新設し、
  リクエストと対称なAPI・データ構造を意識する

• チャンク・バッファ・送信処理も**「レスポンスオブジェクト」経由に寄せていく**

---

4. 関数の粒度と「ストーリーテラー関数」の導入

---

• 細粒度な低レベルAPI（append系、バッファ系）ばかりで、
  大まかな処理の流れを示す関数がないため、
  「ハイレベルな流れ関数」を明示的に用意（例: php_cli_server_handle_request）

• コメントやドキュメントでも大まかな流れや各関数の役割を記述

---

5. 名前空間（プリフィックス）の分裂部位の整理

---

• php_cli_server_ と sapi_cli_server_ の責務分担の明文化

• “橋渡し/グラデーション”層の仮置きや中間ファイル分割（bridge.c, interface.c等）

• ファイル先頭やドキュメントで「どの層がどこまで責任を持つか」まとめる

---

6. 「分類不能」や違和感ある関数の設計/整理候補化

---

• AIや人間が分類不能な関数名・処理は「リネーム/役割分割/廃止」の候補

• 責務が曖昧なまま残存することは今後の技術負債になるため、
  いったんまとめて「設計改善Todoリスト」を作るとよい

---

7. イベントループ/IO層の独立・抽象化

---

• イベントループやポーリング、FD管理関数群を別ファイル化・役割明確化

• 将来的なlibuvやTLS対応にも拡張しやすくする

---

8. API粒度・命名・責務レベルの設計ドキュメント化

---

• コードリファクタと並行して「役割と責務」のミニマップを作っておく

• OSSや後継者向けにも有効

---

追加調査の推奨アクション

• 命名揺れ箇所・分類不能関数の「呼び出し元調査」（grepやIDEジャンプで洗い出し）

• レスポンス系の「カプセル化」不足がどこから来ているかの流れをコード追跡

• “ストーリーテラー”となるハイレベル関数の現有有無をコードサーチ

---

改善できそうなこと要約

1. 命名と責務分担の統一／名寄せ

2. “継ぎ目”やグラデーション部の調査・明示化

3. request/responseペアAPIの再設計・response側カプセル化

4. 処理全体の大まかな流れ関数を追加

5. 名前空間・ファイル配置の整理と分割

6. 分類不能／違和感関数の整理・廃止候補化

7. IO・イベントループ層の独立強化

8. 設計ドキュメントやコメント整備