要不要用 framework? 這是個頭痛的問題
我是個老派的 programmer,從早期的組合語言、C/C++ 學起 (其實這也沒甚麼了不起,以前能用的電腦語言選項並不多),寫程式有一個重要的依據,是要儘可能的了解語言轉成機器碼之後 CPU 的運作模式,這樣才能牢牢地掌握住實際的執行流程,也才能真真切切找到臭蟲發生的原因和時機。我到現在偶而還是會看一看gcc 所產生的 asm 內容,也確認我腦中的模擬是對的,
我想現在寫網際網路程式的人應該是非常少人會這樣做,原因也很簡單,現在的操作環境已經複雜到沒有那麼多的時間和精力去追蹤整個發展所會用到所有元件的底層。這個情況從開始有 Win32 programming 就開始累積複雜度,到了 web programming ,你還聽過有人用 C/C++ 來建置嗎?
取而代之的是各樣的 application frameworks,給你一個框架,只要把肉填進去就可以拿來運轉了,多誘人阿。
但是用得更深入一點,其實開始有點毛毛的。第一,這些 framework 都有蠻強的假設,但不是語法上的,而是 API 的相互 dependency,不按規矩來,就會踏到地雷,而且發展環境不會給你線索,非逼的人去 trace,或是到 stakeoverflow 上去搜去問不可。
第二,很多時候我只是要用其中的一樣功能而已,但是因為整個 framework 是環環相扣的,很難只將其中的一部分拿出來。我手邊的案子就是個好例子: 我只是要用到某個 framework 中呼叫微服務的部分,卻必須將整個非同步機制納進來,而那是我程式其他部分完全用不到的東西。不得已,只好自己手刻寫一個子集合。
最後,雖然這些 framework 都有很多人維護,我相信品質都有一定的水準;但是如果萬一不幸臭蟲真的在 framework 裡面,我實在沒有把握能抓得出來。必須老實說,這一段時間使用 open source package 及 framework 的經驗中,或多或少都碰到過這樣的問題,一旦碰上了,都花上比預期還多許多的力氣。
我的心得: 除非有把握發揮八成以上的特性和優點,我想還是不會去碰 framework 之類的東西。不過這是老派的心得,只代表自己,不會去推薦給別人。