【要約】Public Alphaを公開したあと、何をもって『直った』とするのか――RPRの実機不具合から考える [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
RPRのPublic Alpha公開後、開発者はWindows実機特有の不具合に直面した。CI環境では検知できない、環境依存の挙動が原因であった。
- ・不具合内容: PowerShellで生成したBOM付きUTF-8 JSONの読み込み失敗。
- ・エラー内容:
JSONDecodeError: Unexpected UTF-8 BOMが発生。 - ・技術的課題: 修正が最小限であっても、既存の正常な環境を破壊するリスクがあること。
- ・検証の限界: Linux CIの合格が、必ずしもWindows実機の正常動作を保証しないこと。
// Approach
開発者は、不具合の修正を単なる作業ではなく、一連の「責任経路」として捉えた。修正の確実性を担保するため、以下の多層的な検証ステップを導入した。
- ・最小修正:
encoding="utf-8"をencoding="utf-8-sig"へ変更。 - ・回帰テスト: Plain UTF-8とBOM付きの両方でテストを実施。
- ・実機検証: 最初に失敗したWindows環境へ修正版を戻し、再確認。
- ・全体検証: リリース候補（RC）全体のRuntime、Package、Demo等を検証。
- ・状態の分離: 「修正済み」「検証済み」「公開済み」を明確に区別して管理。
// Result
このプロセスにより、不具合の修正と、リリース判断の根拠が明確化された。
- ・不具合解消: RPR 0.1.0a5においてWindowsのBOM対応を完了。
- ・検証精度の向上: 検証器（Browser test）の不備と製品の欠陥を切り分け可能に。
- ・信頼性の確保: 修正、回帰テスト、実機確認、全体検証を分離し、公開の権限を管理。
- ・運用の高度化: リリース判断の状態遷移を定義し、証拠の整合性を保持。
Senior Engineer Insight
> 修正の「正しさ」と、リリースの「権限」を分離する視点は極めて実践的だ。大規模システムでは、CIの合格がユーザー環境での動作を保証しない。検証器自体の不備を切り分けるプロセスは、デバッグの迷走を防ぐ。単なる「直った」を状態遷移として分解する文化は、信頼性の高いシステム運用に不可欠である。