從一個專案案例說起

最近在開發一款郵件營銷產品，在原型開發階段用最原始的curl方式呼叫第三方平臺介面，用以快速理解對方各種驗證方式及引數作用，後來準備改用平臺提供的SDK開發包，發現引入了新的困惑。

沒有引入SDK前，寫一個郵件傳送服務只需要一個檔案和這麼些程式碼：

$ch = curl_init();curl_setopt($ch, CURLOPT_URL, 'https://api.mailgun.net/v3/mail.kunquer.com/messages');curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0);curl_setopt($ch, CURLOPT_HEADER, 0);curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);curl_setopt($ch, CURLOPT_POST, 1);curl_setopt($ch, CURLOPT_POSTFIELDS, http_build_query([ 'to' => 'client <[email protected]>', 'from' => 'Kunquer <[email protected]>', 'subject' => 'Hello there', 'text' => 'This is from Kunquer']));curl_setopt($ch, CURLOPT_USERPWD, 'api:<APP_KEY>');$response = curl_exec($ch);$result = json_decode($response);curl_close($ch);

使用平臺SDK包，需要使用Composer下載，參照安裝步驟，

composer require mailgun/mailgun-php kriswallsmith/buzz nyholm/psr7

執行上面命令後，你將會被下載這麼些類庫檔案到專案目錄中：

最後你只需要呼叫SDK封裝好的方法：

require 'vendor/autoload.php';use Mailgun\\Mailgun;$mg = Mailgun::create('<<APP KEY>>', 'https://api.mailgun.net/'); $mg->messages()->send('mail.kunquer.com', [ 'from' => '[email protected]', 'to' => '[email protected]', 'subject' => 'Hello there!', 'text' => 'This is from kunquer']);

可是你看見了嗎，你的專案多了個vendor目錄，目錄下塞滿了更多的第三方類庫，然而你並不知道這些類庫有什麼作用，但是又不能刪除。這在多人團隊開發中，某天當你pull一下程式碼庫，發現滿屏的更新檔案如潮水般向你奔湧而來，你腦子裡的反應是不是：臥槽，誰特麼這麼猛又搞大動作啦！

“Composer是現代PHP的基石”

Composer擁護者如是說，現代高階程式語言，依賴管理工具是必不可少的。“Composer解決了專案的依賴關係，且實現了自動載入。開發人員只需要幾個命令列，就能獲取其他開發者的包，PHP開發工作因此變得如同堆積木，可以根據業務的需求，快速方便地拆解組合程式碼。”

因為本人有著重度極簡主義中毒傾向，專案中引用的簡單解決方案能自己實現就絕不用第三方類庫，很多時候第三方類庫都在做所謂的通用廣泛的工作，明明我們碰到的就是那麼一丟小問題，為此引入幾十甚至幾百個檔案到專案中，造成專案檔案規模的急速膨脹，從而越來越臃腫不堪。前有Nodejs的npm，後有PHP的Composer，為了解決依賴關係反而更依賴於依賴了。Composer生態下的類庫包的通病是為解決一個問題而過分依賴於更多的包，這種鏈式依賴讓你的專案變得像麻花一樣。我們知道，外部依賴關係越複雜，出錯率就越高，而一旦碰到了問題，調式起來就是噩夢。

在零引入Composer的專案中並不存在所謂的依賴關係，當你引入更多的Composer生態工具後，依賴便有了溫床。在我看來，Composer更多的是解決了類庫檔案的自動載入，而自動載入的實現用PHP去寫也並沒有那麼神祕不可言，配合專案檔案路徑規範和spl_auto_register便能實現。

實現一個自動載入機制<?php// Autoloader.phpnamespace Yls\\Core;/** * Yls\\Core\\Autoloader * 自動載入類 * * @author focrs <[email protected]> * @copyright 2019 Kunquer, Co.,Ltd * @package Yls * @see http://www.php-fig.org/psr/psr-4/ * @link https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-4-autoloader-examples.md */class Autoloader { // 名稱空間對映 self:: $namespace = [ 'Vendor' => './Vendor', 'App' => './Vendor/App', 'Privilege' =>'./Library/Privilege', 'PHPQRCode' => './Library/Qrcode/PHPQRCode', ], /** * 根據類名載入對應類檔案 * @param string $class 類全名 * @return boolean */ public static function Load($class) { static $namespaces = null; if(is_null($namespaces)) { $namespaces = self::$namespace; // 對namespace名字進行排序，路徑最長的排前面，優先匹配 uksort($namespaces, function($a, $b) { return substr_count($a, '\\\\') < substr_count($b, '\\\\'); }); } $segments = explode('\\\\', $class); $c = array_pop($segments); while(count($segments)) { $n = implode('\\\\', $segments); if(isset($namespaces[$n])) { require $namespaces[$n].'/'.$c.'.php'; return true; } $c = array_pop($segments).'/'.$c; } }}// 載入自動載入類require 'Autoloader.php';// 註冊類自動載入機制spl_autoload_register(['\\Yls\\Core\\Autoloader', 'Load']);如何信任第三方開發包？

最近在npm生態體系裡發生了一件幾乎讓整個javascript生態系統陷入混亂：一個名為“is-promise”的庫因為更新引起的bug讓數百萬個依賴於此庫的專案受到影響。在更早的2018 年 11 月，npm下載量超過 200 萬的 package 被注入了惡意程式碼，黑客利用該惡意程式碼訪問熱門 JavaScript 庫，目標是 copay（開源比特幣錢包）及其衍生產品的使用者，以此竊取使用者的數字貨幣。迄今為止，npm社群管理者對此毫無解決辦法，只能考慮為 JS 本身新增一個更好的標準庫，以減少 one-liner 包的數量。發生在npm身上的問題，在以後的Composer上也一定會出現。

寫在後面

雖然有著安全和信任問題，但隨著更多大廠擁抱Composer生態，作為開發者也只能向這個生態靠齊，不能因噎廢食。但如我標題所表達的，如非必要，減少Composer使用的次數。畢竟千里之堤，容易毀於蟻穴。當一個系統引入不確定性越多，你對它的掌控性就越弱，它崩潰的可能性也就越高。

給你程式碼｜往期回顧：