接手 4000 個 PHP 檔的那天

Client Background

Challenges

1. [01]

   接手 4000 個 PHP 檔,多版歷史文件散落在不同資料夾,版本混亂、無唯一真實源

2. [02]

   沒測試覆蓋、沒 git history,變更影響範圍難以評估

3. [03]

   Bootstrap 3 → 5 升級涉及全站樣式 / 元件 / breakpoint 系統

4. [04]

   IIS + PHP FastCGI 環境特殊,部署細節跟主流 LAMP 教學不同

5. [05]

   既有 cron / autoMailSend / webhook 不能停,維護期間業務不可中斷

6. [06]

   多年累積的 SQL 注入風險(inline string concatenation),要逐步降級

7. [07]

   hot fix 與 dead code 混雜,改 A 影響 B 是日常

8. [08]

   客戶不接受 downtime,所有升級都得 hot-deploy

Solution

1. [01]

   程式碼地圖

   用 grep + serena MCP(語意化 AST 工具)梳理 4000 檔的相互依賴,標出活躍區塊與死碼,做出可視化模組圖,新進工程師有對照參考

2. [02]

   漸進式 Bootstrap 5 升級

   不做全站 big-bang 重構,改用 module-by-module 滾動升級;WEBERP_Bootstrap5/ 子目錄做 sandbox,逐個頁面遷移後再切換

3. [03]

   IIS + PHP FastCGI 調校

   handler mapping 對應 *.php → C:php8php-cgi.exe,php.ini 套件啟用、FastCGI Settings 調整 PHP_FCGI_MAX_REQUESTS,從零文件到可重複部署的 web.config 模板

4. [04]

   cron 重構

   把散落的 PHP CLI 排程腳本(autoMailSend / DC 出貨 / Excel→PDF 自動轉換)整合到單一排程器,排程設定後台化,失敗有 log

5. [05]

   安全性回填

   prepared statement 改寫舊 inline SQL、所有表單加 CSRF token、Session 強制超時、敏感頁面權限重新審視

6. [06]

   部署管線

   引入 git(原本沒)、staging 與 production 環境分離、release note 制度,客戶可自助發版

Results

• 4000檔

  4000 檔程式碼地圖 + 模組依賴圖完成,新進工程師有對照可循

• [02]

  Bootstrap 3 → 5 漸進升級全站完成,過程零停機

• [03]

  cron / autoMailSend / DC / Excel→PDF 整合到單一排程,失敗自動重發 + log

• [04]

  SQL 注入風險全面降級,prepared statement 覆蓋核心表單頁

• [05]

  客戶可在 staging 自驗收後一鍵 push 到 production,不需聯絡工程師

Use Cases

• 工程師

  接手第 1 週,從「README 0 行」到「模組依賴圖」

  打開 4000 個 PHP 檔毫無頭緒。先用 grep 統計 include / require 關係,再用 serena MCP 做語意化掃描,標出每支檔被誰呼叫、呼叫誰。第 5 天得到第一版模組依賴圖,第 7 天標出 30+ 支死碼可清。從此每次改檔不再像打地鼠。

• 客戶

  從「排工程師 2 週」到「dev → staging → production 1 天」

  過去客戶想加一個欄位、改一張報表,得排隊等工程師。現在他們在 dev 環境自己改、staging 試 SIT、確認沒問題就 push 到 production。整段流程從 2 週縮到 1 天內,工程師只在卡關時介入。

Data Model