使用 Composer 管理项目依赖

我个人入行以来,最早接触软件包的概念,是从 Java 开始的,在学校学习 Java,所有的 Java 代码,都默认在一个软件包里面。如果要使用某个现成的功能,就要 import 一个软件包,就可以使用那个软件包里的所有代码了。然后,又在操作系统层面接触了包管理器,那是最初使用 Linux 的时候,那时候,最先使用的是 RedHat,非付费版本的 RedHat 没有包管理器,只能自己解决类库依赖,简直就是地狱。直到遇到了 Ubuntu 的 apt-get,简直瞬间来到了天堂。

后来,我成为了一个程序员,我使用的是 作为工作的开发语言,但是,这个语言里没有包管理的概念的, 代码,都是一个项目一个项目的,能用的类库是比较少的,最多有些网上能找到的东一榔头,西一棒槌的代码片段。所幸,那个时代,也没有接触到所谓的大规模软件开发。直到进入到大公司,发现大家都在刀耕火种,代码复用,就是把一些代码组织到一个文件夹里,然后单独设立一个 SVN 库,最好的复用,就是做到了用 SVN 的 external 特性来引入一个代码。

但是,随着 GitHub 这样的网站火爆发展,开源代码前所未有地爆发,大量的软件包涌现出来,而整个软件研发世界,也更倾向于使用更规范和自动化的形式去复用代码,node 因为旗下的 npm 而大行其道,简直就是杀手级的应用,所以,PHP 从 Symfony 社区开始,出现了 这个杀手级的应用服务。

而 PHP 语言,也整体都升到了 5.x 以上,namespace 特性已经全面普及,而 PHP-FIG 民间标准化组织的成立和 PSR 标准的普及,也已经到了成熟的阶段。我想,现在是时候全面使用 Composer 这类的工具来管理项目依赖和依托于这种工具来完成代码的复用了。

这是一种全新的思维模式。通过依赖配置文件,使用自动化工具来下载代码,使用自动加载来使用代码。不再是老的,在代码目录里放个取名为 lib 的文件夹,把代码放进去,用子文件夹管理。

使用单独的 Git 版本库来管理被复用的 lib 代码,设立单独项目库,这样的成本是极低的,通过规范的项目式管理,来管理每一个内聚的软件包,每个 release 都带有各自的版本号。

每一个项目单独配置依赖文件,对版本的依赖的是逐个项目指定的,而不是放在系统级的 include 目录。避免因为一个 lib 的版本升级,搞挂整个服务器上部署的所有项目。

所有,这些,程序员需要学习的,就是 Composer 的正确使用方法和语义化版本的原理和实施方案。我感觉,这是时代的潮流,虽然现在来说这个话,显得很滑稽,因为 Composer 早已流行了数年。但是,我仍然庆幸自己已经认识到了这一点。即便是 PHP 软件的研发,也已经全面进入了一个工业化时代,整个行业都变得更加的自动化和规范化,现在,一个 PHP 程序员,可能只需要写很少很少的代码,就可以实现一个功能丰富得匪夷所思的软件。而能够实现这一切,Composer 居功至伟。

纵使 Composer 仍然有很多的缺点,我实际使用中确实发现,其缺点相当多,比如,软件包的质量良莠不齐,比如,依赖配置文件,一般对软件的版本依赖都是活动的,就是依赖的实际是一个软件的版本范围,当执行升级指令的时候,可能因为依赖的变动而导致整个应用的崩溃。而 Composer 这样的组件,明显的一种设计思想,就是打破比较保守的软件开发思路,可能将软件开发者推上一个版本更新的极致道路,只有一款软件有人维护,那么不单软件代码,甚至其依赖的所有类库代码都会不断被更新到最新的版本,这在过去保守的软件开发观念看来,简直不可思议。而时代要求我们现在这么做。

此外,比较困扰中国用户的就是,网络的封闭性问题,比如 GitHub 和 packigist 等网站的联通性和流量带宽都十份让人忧愁。所以,我想,肯定会出现更好的技术解决方案,来代替这个东西,但是这种思想应该是潮流和趋势无误了,可以全面推进去部署和执行了。