作者：吳祐賓
▋選擇 Classic ASP 來解決問題，不是瘋狂的叛逆，而是妥協的藝術
當面對一個微小需求：「使用者要在系統看到圖片」
而你那 2000 年開發的 Win32 系統既改不動，也不能改
一般人會有幾個選項：
1.說做不到，放棄
2.另外寫一個系統
選 1 的人很正常，領多少錢做多少事，老闆的薪水沒付到這個專業項目
選 2 的人超級認真，是一名做實事的員工，只是對應到「微小需求」的開發時間，聰明的老闆怎麼想都不認為是好的選項
身為一名專業的工程師，當然能不做就不做...我是說做不到的工作就給外包做
我選 3.外部連結或下載 來解決此問題，原因是：
1.繞過歷史包袱：避免於舊技術搏鬥、修改系統所引發的系統性風險 (好像繞口令)
2.成本效益最佳化：「使用者要在系統看到圖片」這句話的重點不是「在系統」，而是「看到圖片」，使用 OS 層的瀏覽器來開圖是成本最低、開發時間最短的方案
▋「成本最低、開發時間最短」的方案，你怎麼選？
利用瀏覽器開，可使用本機檔案開啟或另寫網頁圖片顯示功能
由於「本機檔案開啟」需要修改程式，不被許可，於是只能採用網頁圖片顯示
看到這裡，聰明的你應該會想到：
1.Python
2.Node.js
3.Deno
4.PHP
這些選項除了 4 之外，其它都是現代網頁開發的主流 (是，JSP 已成古代語了)
Python 絕對是開發時間最短的選項，豐富的三方資源，簡單直白的程式寫碼風格，都是上上之選
然而，除了開發環境複雜，開發除錯服務緩慢，網站服務還得設定反向代理（Reverse proxy），嗯，還是輕輕放下
Node.js / Deno 這兩個都是我目前的主要工具，豐富的 JS、三方資源，但為了實現小功能而承擔 node_modules 無底黑洞和使用反向代理等步驟，是我不考慮的原因
PHP，持續更新、活躍於現今的網頁開發市場，採 FastCGI，使 PHP 在穩定、執行效率更上一層樓，還是 NAS 的基本配備
但我的環境是 IIS + MSSQL 啊！PHP 的跨 NAS 機制對我來說吸引力不高，而 PHP 在 NAS 下要連 MSSQL 也是困難重重，點到 PHP 的技能樹對我的加分並不多
▋Classic ASP 位於程式鄙視鏈最底端，是它無用還是後門太多？
Classic ASP，目前版本 3.0（2000年2月17日，距今至少 25 年前）
它還活著，Windows Server 2025 版，還是有內建 Classic asp 3.0
看到微軟廢棄了這麼多產品，IE6 都走入歷史了，Classic asp 居然還活著，證明 Classic asp 才是真正的歷史包袱
早些年，我也是臨危受命來解救公司內 asp 網站被殖入木馬的問題，所以對攻擊手法也是略懂略懂，不外乎就是被當 SQL 和 HTML 的測試場：
1. SQL 注入 (SQL injection)
2. XSS 注入 (Cross-Site Scripting，又稱跨站腳本攻擊)
綜合這些經驗，另外還有一個冷知識，asp 支援 JS ECMAScript 標準！就是 ECMA 3 (2000年標準) 舊了點
但它還是 JavaScript，在 JS 經驗上也能延續，哪怕 asp 是程式鄙視鍵的最底層，都不影響我使用 Classic asp 的決定
▋所謂的全端工程師，就是能在面對突如其來的需求下，仍能給出合宜的解方
透過這些分析可以知道，一名全端工程師，掌握一門可以前後端通透的技術外，巧妙的「技術選型」也是全端工程師必點的技能
使用 Classic asp，只是在我的場合下，能採用的最佳解，它可能不適合你，但上述的思路與大局觀，在任何場合都能適用
成為全端工程師，就是要持續的青春期叛逆