Composer 与 php 在项目中结合使用

当系统有不同的web应用，但是需要共用很多代码怎么办
当系统需要一个扩展功能而这个扩展功能网上刚好有人提供了怎么用
PHP代码如何升级，降级，回滚
如何分配任务，如何让多个工程师一起进行开发任务

在我接触PHP时，那时候刚发布V5.3.5。从语言层面，我不认为PHP有过于明显的缺陷，我们在有丰富面向web的函数库的基础上，还有了类、SPL、匿名函数、etc。这些特性（一点都不“特”好吧）足够支撑一个大型项目的编码需求。

PHP5.3

可是，真当我们实际开发的时候，真的想用PHP写代码的时候，却经常会碰到一些抓狂的问题，这些问题和PHP倒是没太多的关系。可是还是让人很头疼的。我们想写一个网站的时候，我们可能会需要一个验证码，可是大部分的情况下，我不会自己想去写一个验证码。网上有那么一大把的验证码类，我自然想直接用。可是当我想直接用，我要做的有：

1. 去搜索引擎搜索，然后看每一个结果有没有合适的代码，可以给我用。
2. 我找到了一个类，这时候我需要把这个类引入我的项目，放在哪个目录？怎么autoload？它有没有依赖什么扩展？它会不会需要使用在比我现在更高版本的PHP上？这都是我要解决的问题。
3. 如果我要解决2说的所有问题，那么我为什么不直接写一个？
4. f**k it

就算用我自己的代码，当我 有多个web应用（电脑端、wap端 、api接口很正常吧），我当然希望它们不在一个项目（目录）里活稀泥，会增加我查看指定文件的难度，从而也增大我的维护成本。可是当我把这些web应用都分开以后，有那么多的通用的代码（model、logic、auth。。。），这些代码我应该如何处理，我修改了一个web应用的一个小逻辑，我还要去其他应用修改，要么我记不住，要么再小的一个改动也会变的让人想砸电脑、辞职、出去散心。

好吧，我把这些代码进行拆分，通过autoload来互相使用，这样还可以让更多的人参与开发，可线上的情况那么复杂，万一有哪段代码出问题了，万一有哪个web应用比较特殊，新的代码对它来说不适用。维护起来也是个问题，接手了这样一个依赖于很多其他项目的web应用，也许稍微改一下代码都会有很多麻烦，因为那些autoload的代码也很难让人有很直观的知道这个web应用到底用了哪些其他项目的哪些代码。

可是面对PHP，我又不想破罐子破摔啊，毕竟写起来那么方便。我还不想脱坑。但是上述问题不解决，反正我个人认为写PHP还是一件挺崩溃的事情。我们来看其他语言是怎么解决这个问题的。JAVA天然的包机制让它可以用maven，node的npm，连比PHP还老的Perl都有cpan。难道PHP不应该有一个包管理机制吗？

还好这些问题没有陪伴我的PHP时光太久，因为很快，PHP有了Composer，天亮了。

Composer 是 PHP 的一个依赖管理工具。它允许你申明项目所依赖的代码库，它会在你的项目中为你安装他们。

这是Composer中文官网自己的简介。

我试图从使用经验上来阐述一下这句话。
它允许你申明项目所依赖的代码库 就是说当你想用什么代码不再需要自己复制了，而是通过声明的方式来告诉Composer就好了，就像去餐厅吃饭一样，你不用教厨师怎么做，更不用自己做，也不用自己端盘子自己吃，而是告诉服务员，你要吃什么，告诉它就好了，当然，你不能告诉他我今天胃不舒服，给我做点方便消化清淡一点的菜，反正我从来不这么点菜，总得告诉他们你到底要吃什么菜，具体的菜名。这就是和之前在搜索引擎里找代码的区别，你不能通过关键词告诉Composer，而是要告诉它你要的代码库的名字，WTF？我哪里知道代码的名字，谁也不可能知道别人代码的名字，除非有个地方包含了所有的代码而且提供了搜索的功能让我们找到他们并知道他们的名字，packagist.org就是干这个的。我们再也不用去各个搜索引擎里凭运气找了，在这里搜索关键词不会出现广告，不会出现莆田也不会出现JD。
它会在你的项目中为你安装他们: 告诉了Composer以后，Composer自然会帮我们把菜端上来，这是一件任何人都可以理解的事情，我们想要的代码不知道在哪台服务器里放着，但是Composer会帮我们下载到本地。可是这里还有一个问题，下载下来以后怎么用，我们知道PHP里想用一个文件必须得include或require，Composer下载下来以后，这盘菜怎么吃，需要自己准备碗筷吗？还好还好，还有一个好东西PHP-FIG,这个玩意它不生产代码，不提供任何实际问题的解决方案。他唯一做的事情就是BB， 那他BB一些什么呢？就像我上面说的那样，因为一些基础工具（比如Composer）的缺失，PHP开发很难有一些标准，比如编码规范，比如目录结构，比如如何自动加载类，比如如何打log，比如如何使用缓存，这样就会导致什么呢？不同的公司、不同的PHP程序员就会开始八仙过海各显神通，当然这对开发来讲短时间到也没什么，可是长久来看，这是会增加开发成本、维护成本的，当我们换一家公司、接手一个项目我们要从头开始理解代码，甚至在一个团队里我们都会因为没有标准而增加沟通成本。所以PHP-FIG就做了这样的事：制定标准。他制定的标准有：

1. 编码规范 (psr-1 psr-2)
2. 自动加载规范(psr-4)
3. 一些通用接口 log(psr-3) cache(psr-6) http(psr-7)

这些标准在官网上都有详细的描述。我们这里要讨论的是psr-4。我在这里按照我自己的理解和使用经验稍微阐述一下：psr-4的自动加载基于文件夹和命名空间，我们需要指明一个根目录对应一个根命名空间，在这个基础上，我们可以通过除去根命名空间以外的命名空间和类名来在根文件夹下找到这个PHP文件并加载

#根文件夹 lib
#根命名空间 model

#file lib/A.php

namespace model;

class A {

}

#file lib/entity/B.php

namespace mode\entity;

class B{

}

#file demo.php

$a = new \model\A();

$b = new \model\entity\B();

Composer就实现了可以根据指明标准（如psr-4）和映射关系(如代码中的lib->model)来生成自动加载类的功能。事实上Composer提供了这些标准：

1. files 指明PHP文件路径的方式，这种方式会在每次请求时都要载入这些文件，适合一些通用函数的PHP文件
2. Classmap 比files智能一些，可以指明一个文件夹或一个文件来进行自动加载，缺点是即使是指明了一个文件夹，这个文件夹下增加了一个文件都需要Composer重新生成一次autoload文件，适合一些不能使用psr-4的类或类库，比如一个第三方接口的client，这个client可能在psr-4规则出现之前就有了，那么我们还是希望用Composer进行管理就可以使用这种方式
3. psr-0 psr-4的前身，以前落伍了，就当我没说过
4. psr-4 就像我上面介绍的，这种方式增加一个或多个文件也不需要重新生成autoload文件，因为它是按照命名空间和文件夹的映射关系来加载的。

那么Composer实现了这个有什么好处呢？

1. 我们自己不需要写什么autoload文件了，同时这个标准也很好理解接受，维护和学习代码的成本也降低了
2. 只要我们需要的第三方库也是使用Composer来处理自动加载的，我们只需要require这个包，那么加载这个第三方库的代码Composer也会处理，我们有了一个超强的autoload文件

所以，我们要做的就是学习和Composer打交道然后开始享受全球开发者的代码了。

就像上面描述的,Composer就像一个机器猫，你要什么它就给什么，那么交互的方式就类似于SQL语句那样，告诉它你要什么然后它给你结果。所以我们要做的就是描述需求，也就是当产品经理，好过瘾。

{
    "name": "fmw/test",
    "description": "fmw test",
    "authors": [
        {
            "name": "zzc",
            "email": "[email protected]"
        }
    ],
    "repositories": [
        {
            "type": "composer",
            "url": "http://package.fmw.com"
        }
    ],
    "version":"1.0.106",
    "require": {
        "fmw/other-layer":"1.*",
        "fmw/common":"1.*"
    },
    "require-dev":{
        "php-console/php-console": "^3.1",
        "phpdocumentor/phpdocumentor": "2.*"
    },
    "autoload":{
        "psr-4":{
            "model\\":"src/"
        }
    }
}

以上代码是一个我用过的composer配置文件，可以看出这是一个标准的json。我们来看一下这段json的每个key：

1. name和description是你给这个php项目起的名字，当这个项目仅仅是一个web项目，这两个其实不是很重要，但是这个项目其实是一个向外发布的代码库，就很关键了，name需要独一无二，description需要一句话来描述这个包的作用。
2. authors就是相当于宣布一下主权，可以有多个
3. repositories相当于你需要下载的代码库所在的仓库，默认会有一个全局的仓库，具体是什么就不在这里说了，上面的某个网址有介绍，在这里添加一个是因为如果你有个私人的仓库（有些代码不太适合放在公开的仓库吧），则可以在这里声明
4. version是版本号，这个是跨时代的功能啊，有了这个，PHP程序员也可以刷版本号了啊！
5. require则是上面阐述了很多的功能，解决了我说的那些痛点，通过“name”:"version"声明，可以有多个，require以后使用composer install命令composer会下载代码并自动加载
6. require-dev用法一致，但是功能不同，是用来声明一些在开发时候才用到的包，比如测试、文档等等
7. autoload 上面有介绍，就不废话

上面工作做完以后，执行composer install我们可以看到和composer.json同级的文件夹下生成了一个vendor文件夹，我们新建一个php文件引入vendor下的autoload.php文件就可以使用包和我们自己声明的autoload的php文件了

#index.php

include './vendor/autoload.php';

到这里，我们就算会用了composer，至于如何使用composer的功能就不拾人牙慧了，但是还有一些问题想讨论一下。

比如有些代码不太适合放在公开的仓库，但是我们还是希望包的形式来使用，毕竟这样的话，一个公司内部就很容易分工了，每一个PHP程序员维护若干个包，多方便，所以建立一个内部的代码仓库是很重要的。这时候Composer官方提供的工具satis就可以发挥作用了。

Simple static Composer repository generator

这是它的介绍，一个简单的Composer仓库生成器。使用它的步骤如下：

1. 在合适的目录执行 php composer.phar create-project composer/satis --stability=dev --keep-vcs(前提是你已经按照Composer)
2. 新建一个satis.json 实例如下

   {
    "name": "My Repository",
    "homepage": "http://packages.dev.com",
    "repositories": [
        {"type": "vcs", "url": "http://git.dev.com/maxincai/package1.git"},
        {"type": "vcs", "url": "http://git.dev.com/maxincai/package1.git"},
    ],
    "require": {
        "maxincai/package1": "*",
        "maxincai/package2": "*",
    }
   }

3. 执行 php bin/satis build satis.json public/(public就是所有包的存放目录)
4. 将public目录作为一个web服务对外发布就好了
5. 使用的时候只需要在repositories多加一项（就像我在上面的composer.json做的那样），然后引入包就好了

关于Composer，上面就是我目前要说的了，通过Composer我们可以将业务逻辑、通用函数、逻辑拆分成不同的包，再也不需要做拷贝代码的蠢事了。

http://www.cnblogs.com/maxincai/p/5308284.html
http://www.php-fig.org
https://github.com/composer/satis