Fork: 0
hasegawa / TIASShot
Transfer to URL with SHA Find file
Newer
Older
TIASShot / docs / PROGRESS.md
Rinto Hasegawa rintoHasegawa (Rinto Hasegawa) on 7 Jun 6 KB [add] エラーハンドリング方針（GUIDE_09）を作成
Raw Blame History

開発進捗ログ

  •  環境整備（テンプレート同期・docs 番号修正） (2026-06-06): プログラミングテンプレートを初回同期（エージェント/コマンド/GUIDE_05 等を取り込み）し、docs カテゴリ番号を命名規則（GUIDE_03）に整合（PLAN→03 / SPEC→04 / TECH→05）。リモートをセルフホスト Git から GitHub（rintoHasegawa/TIASshot, Private）へ移行。

  •  CameraBase のリファクタリング（責務分離 Phase 1〜4） (2026-06-06): 肥大化していた CameraBase の責務を分離。Cameras/・UI/（Phase1）、色補正→ColorCorrection/ColorCorrector（Phase2）、チャート検出→ChartDetection/ChartDetector（Phase3）、ファイル I/O・サウンド→Utils/IoUtil（Phase4）。

    • 動機: CameraBase にカメラ制御・チャート検出・色補正・ファイル I/O・サウンドが集中していた。
    • 方針: 挙動は一切変えない（PLAN_01）。各フェーズで計算/検出/I-O ロジックが元コードと文字単位で一致することを確認し、ビルドは全フェーズ 0 エラー 0 警告。
    • 設計判断（PLAN_01 当初案からの変更）: 派生クラス（IScam/Lucam）と共有する状態に結合するメンバーは分離先に移さず CameraBase に残した。具体的には UpdateRate/GetRatio（ゲイン補正）、SetSaveFolder/WriteInfo/SetInfo（_saveFolder/_ShotInfo 経由）。後者 2 つは純粋ロジックのみ IoUtil へ移し、CameraBase 側は薄いラッパーとした。
    • 回帰検証: リファクタ前に実機で基準データ（_基準データ_refactor前/、特に TCC_RGB.csv）を取得して保管。実機の再校正は物理入力が変わり数値が一致しないため、回帰は「同一入力での計算一致」＋「コードの文字単位一致」で担保した。

  •  CameraBase リファクタリング Phase 5（IScam/Lucam の重複処理を集約） (2026-06-07): Phase 1〜4 後も派生クラスに残っていたプレビュー/校正フローと撮影ループの重複を、CameraBase のテンプレートメソッドに集約。カメラ固有のゲイン反映・フレーム取得・撮影前後処理のみ抽象メソッドで派生クラスに残した。

    • 方針: 挙動は一切変えない。自動テスト不可（ハードウェア/ネイティブ/WinForms 密結合）のため、ビルド 0/0 ＋ diff の処理順序目視一致 ＋ 実機撮影確認で担保。
    • 設計判断: IScam の撮影前後処理（Sink 切替・最初のフレーム捨て）は Lucam と実行順序が異なるため共通骨格に取り込まず派生側に残した（順序維持を優先）。
    • 失敗パターン: 校正収束時のデバッグログを撮影情報記録とまとめて CalcTcc の後に移したことで元の「ログ→CalcTcc→記録」順がずれた → テストで検出し、CalcTcc 前に呼ぶ専用フックへ分離して厳密な順序一致を回復。

  •  PLAN_02 優先度1: _shots のスレッドセーフ化（連続撮影クラッシュ修正） (2026-06-07): 連続撮影で4枚以上取得するとたまにクラッシュする不具合を修正。根本原因は _shots（List<Mat>）を撮影スレッドと保存スレッドで無保護に共有していたこと（容量拡張時のリサイズ競合・TOCTOU）。

    • 設計判断: ConcurrentQueue 単体ではなく BlockingCollection<Mat> を採用し生産者-消費者パイプライン化。GetConsumingEnumerable/CompleteAdding で Thread.Sleep ポーリング待機を排除。保存連番は独立カウンタで従来順序を維持。
    • 堅牢化: 撮影ループを try/finally で包み、例外時も CompleteAdding() を必ず呼んで消費者（保存スレッド）の永久ブロックを防止（例外はそのまま伝播。ユーザー向けエラー表示・撮影中断は優先度3 で別途）。
    • 回帰検証: 自動テスト不可（ハードウェア依存）のため、ビルド 0/0 ＋ 実機（校正・連続撮影・複数回・連番一致）確認 ＋ 設計レビューで担保。

  •  テスト方針（GUIDE_08）整備 (2026-06-07): 立ち上げフローの規約整備フェーズが未着手だったため、品質管理の土台としてテスト方針を策定。ハードウェア結合層（カメラ/UI/スレッド）と純粋ロジック層を分け、後者を NUnit で自動テスト、前者をビルド＋手動＋実機回帰で担保する方針。

    • 動機: /implement のテストフェーズが毎回「テスト不可」で終わっていたが、実態は純粋ロジック層（ColorCorrector 等）にテストプロジェクトを立てていなかっただけ、という認識のズレを是正。
    • 後段: テストプロジェクト（TIASshot.Tests, NUnit / x64 / .NET Framework 4.8）の立ち上げと ColorCorrector・Config・IoUtil 等の初期テスト作成（次ステップ）。

  •  エラーハンドリング方針（GUIDE_09）整備 (2026-06-07): 既存の実装パターン（ErrorMsg＋bool 返却・MessageBox・Debug.WriteLine・ShowMessage）を土台に，エラーの分類（起動時致命／処理中の回復可能／プログラミングエラー）・処理方法・ログ方針を軽量に標準化。

    • 動機: PLAN_02 優先度3（撮影中の例外をクラッシュさせずエラー表示・中断する修正）の前に方針を確定し，場当たり実装を避けるため。
    • 設計判断: ログは Debug.WriteLine のみとし永続ログファイルは作らない（撮影現場での解析が必要になったら別途見直す）。空 catch 禁止・例外時のスレッド同期資源の finally 終端を明文化。
    • 残: GUIDE_06 コーディング規約・GUIDE_07 ディレクトリ構造規則は未整備のまま（既存の de-facto 確立により優先度低）。