探索PHP构造项目之路之中止复制粘贴

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

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

但是，真当咱们实际开发的时候，真的想用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": "2272713550@qq.com"
        }
    ],
    "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