在低耦合抽換函式庫

之前作專題要用到地圖的 js api， 專題的 code 寫得很嚴謹， 刻意降低程式的耦合度；果然收到效果了！ 把地圖的 api 從 google 換成 leaflet 竟然只花了我不到五分鐘在改 code！

專題是一個網路相簿，可以上傳照片， 把照片顯示在拍攝時的座標， 所以需要一個地圖來放相片。 本來是貪圖方便，用以前學過的 google map 做個原型， 想說以後再看要改政府的 TGOS 還是 open street map。 TGOS 是老師建議的，而身為開源人、維基人 當然要用群眾協作的 open street map 啦！

使用 leaflet 與 osm

但其實還花了半小時以上在爬文， 爬 osm wiki、比較各函式庫、讀 leaflet 的文件。 我是想把地圖從 google map 的 api 換成 open street map 的， 就找到 leaflet 和 open layer 兩個函式庫。 在 open layer 一直找不到叫出 info window 的功能， 就決定用 leaflet。

之前在寫的時候就很小心，物件都宣告好幾層， 外部的函式庫絕不在核心程式直接使用， 一定先包裝一次。 這樣要換函式庫就把新的 重新包裝出和原本一樣的介面， 其它部份的程式完全不用動。

物件疊床架屋

但其它部份就沒這麼順利了， 總覺得核心程式碼好醜。 自己真得不太會寫這種大型程式， 不太會切割一些功能到底是要分配到哪個物件。 核心內的耦合也很糟糕， 改一段 code 都只能實際跑才知道有沒有 bug， 已經不太知道自己在幹麻了。

另一個函式庫 piexif 也是不怎麼漂亮， 要不是只有找到她支援讀寫 exif 還真不想用。 她只能操作 binary string！ 但 web 的標準是使用 blob 或 buffer array 讀寫二進位資料。

只有地圖的 api 本來就只專職顯示， 不太需要和其它物件互動， 只要被其它物件呼叫就好了， 所以比較好剝離。

大型程式的開發

看過一些經驗談，寫程式真得需要一些經驗， （尤其是大型程式。） 最好從讀 code、改 code 開始， 有一些眉角只能靠經驗的累積的。 我的 第一個 js 程式 也是寫得亂七八糟，後來就放生了。 自己的部落格系統也是重構了好幾次。

也許我不適合寫程式， 我喜歡簡單的腳本，解決日常的問題； 不是開發大型的軟體，需要長時間機械式地投入。 我重新審視了自己的目標， 不是成為一個程式設計師； 我是一個 linux user，懂一些腳本、 安裝軟體、call library 就夠了 :)