開発環境・開発ルール - smileygames/dipper GitHub Wiki

本ドキュメントは、このプロジェクトに関わる人が

共通の前提・判断基準を共有するための開発ルールをまとめたものである。

作者自身も迷わず開発を続けること、 および将来の参加者がプロジェクトを理解しやすいことを目的としている。

開発環境

基本構成（作者の場合）

  • Windows + VSCode
  • WSL2（Ubuntu）
  • GitHub（VSCode の Git 機能を使用）
  • 実機テスト環境：AlmaLinux 9 / AlmaLinux 10

この構成を選んでいる理由

  • Bash スクリプトは「実機で動くか」がすべて
  • CI や仮想環境はあくまで補助
  • VSCode + WSL は「壊しながら直す」作業に向いている

dipper は理論よりも「現実の挙動」を重視するため、 最終確認は常に実機で行う。

GitHub 運用ルール（簡易）

  1. Issue を作成
  2. Issue から作業ブランチを作成
  3. ローカルで修正
  4. VSCode 上でシミュレーション的にデバッグ
  5. 問題なければ作業ブランチにコミット
  6. テスト用実機（AlmaLinux10）で軽く運用テスト
  7. main にマージ
  8. リリース作成
  9. 本番環境実機（AlmaLinux9）で運用テスト
  10. 安定したら安定版扱い

このフローは必須ルールではなく、 「迷わず作業するための推奨手順」とする。

※ 性質が同一の作業については、 1 Issue / 1 サブブランチでまとめて進める場合がある。

設計・コーディングの考え方

  • 技術的に正しすぎる設計は不要。判りやすい処理にする事を優先
  • 不要になったものは削除する
  • 命名・責務分離・コメントを重視
  • 特に「センスのいい名前」を大事にする
  • GitHub Actions（bats）を整備中
  • 品質保証および最終判断は、実機ログと実運用の結果を基準とする

コミットメッセージ運用ルール

  • コミットメッセージは日本語で記述する
  • 後から何を変更したか分かる内容にする
  • 説明はわかりやすく簡潔に。重要なのは変更内容を記録として残すこと
  • Issue 番号は文末に付与する

【推奨書式】

1行目（タイトル）： 変更内容が分かる要約 + Issue番号（文末）

2行目： （空行）

3行目以降（詳細）：

  • なぜ変更したか
  • 何を変更したか
  • 影響範囲（あれば）

テストに対する考え方

  • 現在はホワイトボックステストを主とする
  • テストはコードの挙動を忠実に追うことを目的とし、仕様の是非は判断しない
  • 今、実際に動いている挙動を正解とし、テストは善悪を裁かず事実を保存する（歴史のスナップショット）
  • 仕様として正しいかの判断は、コードレビュー時に行う
  • ブラックボックステストは、プログラム仕様書整備後に検討する
  • 最終的な品質判断は、実機ログと実運用の結果を基準とする

この開発ルールと設計方針は、 作者自身が 迷わず・疲弊せず・長く付き合う ためのものである。

ChatGPT による文章生成を積極的に活用しているが、 最終的な判断・取捨選択・責任はすべて人間（作者・参加者）が持つ。

dipper は、ツールである前に 作者の思考と経験の記録でもある。

⚠️ **GitHub.com Fallback** ⚠️