【要約】PukiWikiをPHPからC# / ASP.NET Coreへ置き換えた話 [Qiita_Trend] | Summary by TechDistill
> Source: Qiita_Trend
Execute Primary Source
// Problem
開発者は、長年運用してきたPukiWikiの将来的な保守性に不安を感じた。PHPのバージョン更新やセキュリティ対応への追従が困難になる懸念があるためだ。具体的には、以下の課題に直面していた。
- ・PHP実行環境の更新に伴う、依存関係やセキュリティ対応の負担。
- ・既存のWikiコンテンツ（ファイル資産）を失わずに基盤を刷新する必要性。
- ・全機能を一度に作り直すことによる、移行リスクの増大。
// Approach
開発者は、コンテンツと実行基盤を分離する設計を採用した。既存のファイル資産をそのまま入力・保存資産として扱う方針である。具体的な手順は以下の通りだ。
- ・Markdown形式の仕様書を先行作成し、GitHub Copilotを活用して実装方針を定義。
- ・IWikiStorageによるファイルアクセスと、IWikiRendererによる表示責務の分離。
- ・allow-list方式を用いた、安全なHTMLレンダリングの実装。
- ・ストレージ、サービス、レンダラー、UIの順で段階的に機能を拡張。
// Result
開発者は、既存のWikiデータを書き換えることなく、モダンな.NET環境での動作を実現した。プロトタイプを通じて、以下の成果を得ている。
- ・.NET 10 / ASP.NET Core環境への実行基盤の移行。
- ・記法解釈とページ取得の分離による、高い保守性の確保。
- ・任意のPHP実行を排除した、安全なレンダリング境界の確立。
- ・今後の課題として、プラグイン互換性や編集・認証機能の整備を明確化した。
Senior Engineer Insight
> レガシー資産の移行において、データ変換を避け、既存のファイル構造を「外部ストレージ」として扱う設計は極めて合理的だ。これにより移行リスクを最小化できる。ただし、プラグインの挙動を完全に再現しようとすると、コードの複雑性が爆発する。本記事のように「allow-listによる制限」を前提とした、実利的な互換性の定義こそが、現場での現実的な落とし所となるだろう。