【要約】フォントを1段階大きくしたら、字幕の「2024」が「20」と「24」に割れた [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者が字幕自動生成スクリプトの運用中に、フォントサイズ変更に伴う表示崩れに直面した。以前の事故対策が不完全であったため、レイアウトの変化によってバグが表面化した。
- ・フォントサイズ拡大と文字数制限の変更により、行の折り返し位置が変化した。
- ・以前実装した「カンマ区切り数値」を保護する正規表現が、西暦などの「ベタの数字」をカバーできていなかった。
- ・特定の事故パターンのみを想定したガードが、潜在的なバグを隠蔽していた。
// Approach
開発者は、正規表現の定義を「特定の数値形式」から「数字の連続性」という抽象度の高いものへ修正した。これにより、あらゆる数字の分断を防ぐ設計へと変更した。
- ・既存の正規表現
\d{1,3}(?:,\d{3})+を拡張した。 - ・
\d{1,3}(?:,\d{3})+|\d{2,}とし、2桁以上の連続する数字も改行禁止対象に含めた。 - ・AIエージェントによるコードレビューを活用し、大量の差分から微細な分断を検知した。
// Result
正規表現の修正により、西暦やパーセント表記などの数字が分断される問題が解消された。単なる修正に留まらず、設計思想の改善に至っている。
- ・「見た事故の形」ではなく「守りたい性質」をガード条件に据える重要性を再認識した。
- ・パラメータ変更がレイアウトロジック全体に及ぼす影響を考慮する教訓を得た。
- ・テスト設計においても、具体的な事象ではなく「守るべき性質」を検証対象とすべきだと結論付けた。
Senior Engineer Insight
> 本件は「部分最適が全体最適を阻む」典型例である。特定の事故への対処は、本質的な問題の解決には至らない。実戦では、ガード条件を設計する際、実装レベルのパターンではなく、ドメインにおける「不変条件」を定義すべきだ。また、UIに関わるパラメータ変更は、単なる数値変更ではなく、システム全体の境界条件を書き換える「破壊的変更」と捉えるべきである。