楔子
我其實不是 mobile developer。但在某個機緣下，我需要做一個 mobile app。
這個 app 是專案的一部分。
需求其實不複雜，但有兩個條件很明確：
- 語言要簡單
- 可以同時發佈 iOS 和 Android
於是我開始找 mobile framework。
當時評估了一段時間之後，我最後選了 Corona SDK。
一個已經消失的 Framework
如果你現在沒有聽過這個名字，其實很正常。
維護 Corona SDK 的公司後來倒閉了，專案開源，改名為 Solar2D。
對很多人來說，它其實已經算是一個歷史技術了。
更有趣的是，Corona SDK 的定位其實非常明確：
它是一個 2D 遊戲引擎。
而我用它寫了一個工具型 mobile app。
從技術定位來看，這其實不是一個典型的使用方式。
從工程角度看，這不是最佳選擇
如果從工程角度分析，這個技術選擇其實有不少問題：
- 用一個 2D 遊戲引擎 來寫工具型 App
- 掉進 vendor lock-in 的風險
- Ecosystem 規模其實不算大
- Framework 完全由單一公司維護
如果今天有人把這些條件列出來，多半會得到一個建議：
也許應該找一個更主流的 solution。
但專案其實很單純
專案的現實其實沒有那麼複雜。
我的客戶不在意：
- Framework 是什麼
- 程式碼是不是漂亮
- Ecosystem 大不大
他們只在意一件事情：
有沒有一個可以運作的 App。
而 Corona SDK 確實讓我很快做出了一個跨平台的 mobile app。
從專案角度看，這是正確選擇
所以如果從工程觀點看，
我可能選了一個不是最標準的工具。
但如果從專案觀點看：
這個選擇其實完全正確。
因為那個 mobile app 讓我完成了整個專案。
任務完成。
一個時間差的小插曲
很多年之後，我某天看到消息：
維護 Corona SDK 的公司倒了。
專案改名成 Solar2D，變成一個開源專案。
我第一個反應其實不是震驚，而是：
好險，專案已經結案了。
一個很簡單的工程結論
回頭看這件事情，我反而覺得它說明了一個很簡單的道理。
技術選擇不一定是為了找到「最好的工具」，
很多時候只是為了完成一個專案。
有些專案需要：
- 長期維護
- 穩定的 ecosystem
- 可持續的架構
但有些專案的目標其實更單純：
在有限時間內完成任務。
如果任務完成了，那個技術選擇其實就已經成功了。
即使那個 framework 後來消失了。
後記
這個專案已經結束很多年了。
我甚至不確定現在還能不能編譯成功。
但我也沒有打算去試。
對那個專案來說，
任務早就完成了。