紙上得來終覺淺，絕知此事要躬行。

陸游

接下來讓我們依照上篇文章提供的 4 個方法，透過實戰了解如何選出合適的套件吧！

目標：需要一個能取得專案環境變數的套件

以軟體開發來說，我們會把散佈在各個檔案，且在不同環境需要調整或是保密的參數，集合到一個檔案裡面，這樣專案就能在不同的環境中快速遷移（ex：資料庫帳密、ip、網址…）。

這個檔案我們稱它為環境檔（.env），以 Node.js 專案來說，可以透過套件讀取環境檔的參數。

如果我們在 npm 網站 上，以「env」為搜尋條件會得到如下結果：

從左上角我們可以看到總共找到了 20 個套件，但哪個才符合我們需求呢？

從活躍度來判斷

我們需要的功能會往往有很多的套件可以完成，但儘管搜尋到的套件很多，但通常符合需求的都在前幾個；這裡我們將前兩個套件（env、dotenv）用活躍度來比較。

透過上表我們可以得知「dotenv」是更有保障的套件。

確認 Issues 狀況

既然「dotenv」獲得壓倒性優勢，我們就來看看他的「Issues」的狀況。

點進去後，我們可以看到他「Open issues 與 Closed issues 的比例」低於 10%，算是相當穩定的套件；且右上角的 Star 數量高達 16k，有人氣的套件也是一種品質保證。

閱讀文件

在「dotenv」的 README 文件上，它明確說明自己有讀取「.env」檔案的功能，並給出詳細的使用範例。

試用範例程式碼

在試用 Sample Code 前筆者再提醒一下，如果使用上遇到問題，可以到 Issues 的地方看看；過去我就曾遇過同一款套件，在不同框架下的使用方式略有不同，最後在 Issues 裡面參考他人的方案才順利解決。

筆者這邊也依照文件試用給大家看。

從上圖中，可以看到套件確實有印出我們需要的環境變數，可以初步判定它是一個合格的套件！

關於如何選出合適套件的系列文到這邊就告個段落嚕～希望大家日後在開發上都可以找到合適的套件。

如果你還不清楚套件對工程師的重要性，可以先參考這篇文章。

套件之所以會有這麼多，是因為不管大神還是新手都可以發布套件，這造成套件本身的良莠不齊，不過我們可以透過文中提供的「方法」，初步判斷套件是否符合需求，以及品質是否穩定。

本篇文章以npm 套件舉例。

套件活躍度

筆者會從 3 個面向綜合考量套件活躍度：

1. 套件最後發布時間( Last publish)：太久沒更新的套件請謹慎選用。
2. 每週下載次數(Weekly Downloads)：下載人數多的套件穩定性通常較高，至少遇到問題時比較有人一起討論。
3. 版本(Version)：一般來說 1.0.0 以前的版本會有穩定性上的疑慮，盡可能避免使用。

套件 Issues 處理狀況

除了活躍度外，該套件「open issues 與 closed issues 的比例」也是重要指標；如果 open issues 的比例超過 20%，筆者良心建議你要點進去看看別人遇到了哪些問題。

太新的套件可能不穩定、太舊的套件可能沒人維護。

閱讀文件確認是否符合需求

有些套件光看名稱好像是自己想要的，實際用下來卻發現缺東缺西，為了避免這類的問題發生，導入套件前請先詳閱文件。

盡量不要選文件讓人難以理解的套件。

先試用範例程式碼（sample code）

有些簡介把套件的功能吹捧的超強，但這個套件到底能否導入專案，要先試用範例程式才知道。常見問題如下：

• 與專案的 Node.js 版本不合：因為 Node.js 版本更新速度極快，而有些套件的功能是相依於 Node.js 版本的；如果專案有歷史背景難以升級，就只能先去看套件的 release note，祈禱套件過去有發佈與專案 Node.js 相合的版本。與此同時，也一同評估將專案 Node.js 升版的必要性。
• 說明文件根本是錯的：因為套件通常是開源免費的，所以提供的文件不一定都是對的，如果你一直執行失敗，可以先到 open issues 看看有沒有難兄難弟。

相信文中所提到的 4 個方法，可以很大程度幫大家避雷了，如果您有其他選套件的好方法，也歡迎留言分享。

在下篇文章中，筆者會舉出實際案例，幫助大家學以致用。

有些人在面對需求時，不喜歡直接使用市面上功能完善的套件，反而執著於每個功能都要從零開始手工打造；如果手工打造的品質穩定也就算了，但通常最後寫出來的 Bug 比市面上套件還要多很多⋯

人類的進步，大部分是繼承前人的知識繼續發展，就像是你需要了解怎麼使用電腦，但不需要自己買材料親手做出一台電腦。

就拿前端來舉例，假使今天要開發一個後台管理系統，如果堅持不使用框架，選擇用最純粹的 HTML、JavaScript、CSS 來開發，不但要花更多時間，最後做出來的成品還可能比用框架速成的結果更差。

你可以把框架想像成，由各種常見＆穩定套件組合起來的大禮包，使用者依照框架的規範進行開發。

那套件具體有哪些優點呢？以下是筆者感受最深的幾點：

1. 能夠快速評估專案功能的可行性。
2. 可以更準確預估每個功能完成的時間。
3. 節省大量重頭開始寫功能的時間。
4. 可以專心撰寫自己的程式邏輯。
5. 因為部分功能透過套件處理，所以需要維護的程式也減少了。

在了解套件對我們工作的幫助後，接下來要思考的問題是「如何評估＆導入套件」。

以筆者過去的經驗來說，有 95% 以上的套件，我只會看它的官方文檔來了解如何使用，基本上不太會去看這份套件的原始碼，會去看它怎麼寫的套件通常不是因為它寫的太好，而是因為它寫的太爛，因為 Bug 影響到功能，導致開發人員需要去修正，甚至去評估是否有其他替代方案。

我們導入框架＆套件是為了節省開發時間，但如果為了解決它的 Bug 反而花了更多時間（甚至無法解決），那就真的得不償失了。

為了減少這樣的悲劇發生，在後續的文章中，筆者會分享幾個選擇套件時要注意的重點，並搭配實戰案例，讓大家在開發的道路上盡可能不要踩雷。