如何揀library而不中伏
2021-05-12
在世上大多數的技術行業,工作之箇中技術都往往是行業機密,因為這關乎商業利益,斷不會隨便公開予大眾。例如著名廚師的食譜、半導體的生產技術、礦產開採技術等等,誠然在今日互聯網世代,這些技術之相關知識很多時亦可在網上窺得端倪,但往往只是在表面輕輕帶過,箇中奧妙,都不足為外人道。在這一點Programmer則與其他行業不太相同,因為有開源軟件(Open source software)之存在。對世上數千萬Programmer 而言,閱讀、使用、參考其他Programmer的工作是很稀鬆平常的事,即使是世界級Programmer所編寫之程式碼,也很容易在Github 等網站閱讀得到,基本上不存在知識壁疊。很大部份日常Programming常用之程式庫(Programming library),正是以開源的方式,在社群之中共享,在各種技術行業之中,這是一個相當獨特的技術生態。
NPM Wombat Reference
就以筆者最熟悉的Npm packages
為例,NPM
上2019年就有超過一百萬個packages,每月總下載次數達500億次,因此可以肯定地說,不論一個軟件工程師是如此出類拔萃,使用他人所寫的程式庫乃是不可避免。
既然使用他人所寫之程式如此必要,我們更應有一套行之有效的方法,去判斷一個library是否適合手頭上之專案,否則當專案太依賴該library之後,造成與程式庫間之依賴耦合(Dependency Coupling),到時想再改回來,就已經恨錯難返了。
既然活用他人之程式這樣重要,那有何原則可以判斷應該如何挑選library呢?筆者在下筆這篇文章之前,都在網絡上搜尋過類似文章,發覺這個重要問題,竟然很少人談及過,筆者就斗膽在此分享一些個人經驗,希望可以幫到正在閱讀的你。
筆者看來,揀選library 可遵從以下五大原則,並將一一以例子詳加解釋:
- 受歡迎程度 (Popularity)
- 開發活躍程度 (Project activeness)
- 質素高下及文檔齊全程度 (Code Quality and Documentation)
- 許可證及使用成本 (License and cost)
- 多平台支援程度 (Multi-platform support)
程式庫是否受歡迎呢?
正所謂「西瓜靠大邊」,大多數開發者使用的程式庫必然有其優勝之處,其中一個好例子是Twitter Bootstrap
。Twitter Bootstrap
自2011推出而來,一直大受歡迎經常,是Github上最多星星(Stars)的頭數位。開發者在揀選CSS
框架的時候,Twitter Bootstrap
每每是首選,正因有大量開發者使用,更保證了不論有任何問題、任何漏洞,你都能夠輕易在網上找到解決方法,因為類似問題通常早已為數目龐大的用戶測試得非常通透。
Bootstrap
在介紹裏也開宗明義,說是The Most popular HTML, CSS, JavaScript framework...
,強調The most popular
,其中原理,就是「盛名之下無虛事」,都已經是最受歡迎了,質素當然有保證吧,不然大家都轉會了。
比較之下,Bootstrap
的其他競爭對手則顯然無法以受歡迎作招徠: 例如近年很受歡迎的Tailwind
,就以Utility-first
的哲學來與Bootstrap
的Component-first
哲學來作分野。
另一競爭對手Bulma
則以簡單易用作招徠,例如強調just works
、No CSS Knowledge required
。也是為了與Bootstrap
作明顯分野。
因為這些程式庫都須要回答一個很重要的問題,就是為何我有Bootstrap不用,要用這個程式庫呢?,可見僅僅是受多人歡迎,已使一個程式庫獲揀選之機會大增。
程式庫開發者有活躍開發嗎?
只是受歡迎並不足夠,程式庫永遠都在變化,不會一成不變,所有程式庫必須不斷推出新版本,以提供新功能、修補問題、改善開發者體驗(Developer Experience)。假如有一個很受歡迎的程式庫,在過去一年都接近完全無任何開發活動(No active development)的話,筆者認為是一個很大的警號(Red Flag)。
一個好例子就是JQuery UI
,在現今單頁面應用框架如React
、Vue
、Angular
興起之前,JQuery UI
曾經是一個相當廣泛使用的程式庫,因為JQuery UI
提供了不少可以直接使用的部件(Widget)。但走到JQuery UI
的github,你會發覺JQuery UI
對上一個穩定版本已是2016年9月推出,已有超過4年無新版本推出,即使在香港從事軟件開發的公司中,依然有在使用JQuery UI
的痕跡,也掩蓋不了JQuery UI
已經「死亡」的命運。
相較之下,React Material UI
的對上一個穩定推出版本是4.11.4
,距離本文寫作日期僅是13日之差,塾優塾劣,一目了然。
軟件活躍開發,代表新概念、新想法會得到採用,使用之開發者工作效率自然更高。
程式庫開發者是否着重軟件質素及文檔?
筆者自己平常做軟件開發,對軟件的要求自然不只是「能運行」就可以,軟件質素(Software Quality)及軟件文檔(Software Documentation)也是必須考慮的問題。對應用要採用的程式庫要求也相類似,要選用軟件質素夠高的程式庫。一個量度軟件質素的方式,就是用自動測試覆蓋度(Automated Test Coverage)。我們常常在軟件的Github 看見一個Badge
,寫著Coverage 95%
的意思,就是代表自動測試已覆蓋了九成五程式碼。所以這其實是一個代表程式庫高質素之「勳章」呢!
文檔(Documentation)是另一個很重要的因素,程式庫(Library)與普通應用軟件(Application Software)不同,文檔的高下往往直接影響程式庫的成敗。Facebook的React
是最受歡迎的單頁面應用框架,筆者認為文檔清晰簡潔是一大原因,即使是初學者,亦容易上手。
相較之下,另一個單頁面應用框架Ember.js
的文檔則複雜得多,更在同一頁面內有版本1
、2
、3
之別,即使是前端開發老手,也很容易覺得混淆。何謂Ember Data
呢?2.X
的版本又有一個概念名為Controller
?Ember Object
又是甚麼呢? 有興趣者多看幾頁已頭昏腦脹,又怎會在自己的專案採用呢?
在單頁面應用之競爭之中,React
受歡迎程度遠勝Ember.js
,也不言而喻。
程式庫是否開源?
世上絕大多數常用之程式庫,都是開源軟件(Open source software),因此也是用開源許可證(Open source licenses)發行,也有少數程式庫會有收費功能(Premium Features),但不是主流做法。對軟件開發者而言,開源軟件之最大好處,就是容許開發者直接閱讀程式碼,幫助程式庫除錯、改善功能、擴充文檔。對專案管理人(Project Manager) 而言,使用一個開源程式庫也有好處,就是縱使程式庫原作者荒廢了,只要有足夠技術人手,大可以自行繼續維持,不必怕失去軟件支援的困境,因此開源程式庫獲廣泛認為是未雨綢繆的選擇。
相反,閉源/商業程式庫則自帶這個「停止支援」的風險。一個閉源的軟件停止支援,所有與之相關的軟件都需重寫(Revamp)。大家記得的話,數年前Windows XP
「壽終正寢」的時候,連銀行櫃員機也面臨安全風險了。因此,使用閉源軟件,本身就有軟件未來無法繼續使用的風險。
程式庫是否支援多平台?
筆者是長期的Linux
使用者,對應用是否支援多平台非常重視。筆者認為一個優質之程式庫,必然是支援多平台(Multi-Platform)的。開發者往往各有喜好,根據2020 StackOverflow
全球開發者統計,三大操作平台Windows
、MacOS
、Linux
都備受開發者喜愛,分別有45%
、27.5%
、26.6%
的開發者使用。
一個只在Windows
可用的程式庫,就失去 53%
的開發者青徠,一個只在Mac
可用的程式庫,更是失去73%
的開發者份額。很多程式庫因此都是三大平台一併支援,以「大包圍」的策略盡量拓展使用者基礎。
例如人工智能框架Tensorflow
,就同時支援Windows
、Mac
、Linux
三個平台。
除了操作系統之外,一個能夠在不同程式語言中使用的程式庫,也是多平台支援的表現。例如Microsoft
推出的瀏覽器自動化工具Playwright
,就能夠在JavaScript
、TypeScript
、Python
、Java
、C#
多種語言中使用,比之前的Puppeteer
只能在JavaScript
/Typescript
使用,又是更勝一籌了。
總結
開源的程式庫在網上數以萬計,要選擇好,殊不容易,以上都是筆者的一些心得,大多數時間都可以選到一個不錯的程式庫,也不太容易與本文所言一樣「中伏」了,編程起上來就事半功倍。 不知大家又有何原則去選擇程式庫呢?
Comments
Read More
專家級新手
2019-03-19
今次要介紹的,是一個非常常見之現象,不論你是學寫程式、學做甜品、學寫文章,又或是練習球技、體能訓練等,都會經常窺見其身影。 想像一下:你的朋友問你:「你的駕駛技巧好嗎?比較起其他司機來說如何?」如果你本身有駕駛執照,但是不常常駕車,大概你會回答:「中規中矩吧,平均水平」;經常駕駛的人,因為經驗豐富,會覺得自己是中上甚至良好之水平。然而,這個想法人人都有,卻與現實完全相悖:因為任何羣體之中,必然有一半個體在中位數(Median)以下,而一項經典的調查發現,八成的司機都認為自己的駕駛水平在平均之上,這明顯代表在駕駛技術的世界上,大部份人都有自視過高的問題,也代表其實大多數司機,無法準確判斷駕駛技術之高下。
軟件工程師成長手冊
2019-04-29
筆者經常都强調軟件工程師有高下之分,不論技術或是解難能力都可以隨時日改善,亦曾大力鞭撻專家級初學者的無知,對軟件開發造成破壞。 初出茅蘆的軟件工程師及編程初學者想要改善自己技術,在茁壯成長的話,對自己技術層面有一個準確評價是至關重要,以免墮入「識少少,扮代表」的認知偏差。
學好手勢 == 學好Coding
2019-08-21
編程老手與編程新手在工作時,不論效率、思維方向、甚至打字速度都截然不同,不過在學習編程的道路上,有一個方面常被忽略,就是編程手勢(Coding Practice),有豐富實戰經驗的工程師,通常培養了良好的編程手勢,工作時,自然錯誤較少,也因為除錯得少,省略了不少寶貴的時間,整體結果也蔚然不同。
SQL首部曲:NoSQL? No! SQL!
2019-10-08
由本篇開始,接連四篇都是與SQL有關的文章,會想寫SQL的原因,是因為SQL在現今軟件開發及數據科學佔有舉足輕重之地位,卻總是在背後默默無名,從未見得到像其他新興技術之關注,有見及此,筆者決定介紹SQL之特點,順便破除一些對使用SQL上常有的誤解。