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 是 PHP 的⼀个依赖管理⼯具。它允许你申明项⽬所依赖的代码库，它会在你的项⽬中为你安装他们。
这是Composer中⽂官⽹⾃⼰的简介。
我试图从使⽤经验上来阐述⼀下这句话。
它允许你申明项⽬所依赖的代码库 就是说当你想⽤什么代码不再需要⾃⼰复制了，⽽是通过声明的⽅式来告诉Composer就好了，就像去餐厅吃饭⼀样，你不⽤教厨师怎么做，更不⽤⾃⼰做，也不⽤⾃⼰端盘⼦⾃⼰吃，⽽是告诉服务员，你要吃什么，告诉它就好了，当然，你不能告诉他我今天胃不舒服，给我做点⽅便消化清淡⼀点的菜，反正我从来不这么点菜，总得告诉他们你到底要吃什么菜，具体的菜名。这就是和之前在搜索引擎⾥代码的区别，你不能通过关键词告诉Composer，⽽是要告诉它你要的代码库的名字，WTF？我哪⾥知道代码的名字，谁也不可能知道别⼈代码的名字，除⾮有个地⽅包含了所有的代码⽽且提供了搜索的功能让我们到他们并知道他们的名字，就是⼲这个的。我们再也不⽤去各个搜索引擎⾥凭运⽓了，在这⾥搜索关键词不会出现⼴告，不会出现莆⽥也不会出现JD。
它会在你的项⽬中为你安装他们: 告诉了Composer以后，Composer⾃然会帮我们把菜端上来，这是⼀件任何⼈都可以理解的事情，我们想要的代码不知道在哪台服务器⾥放着，但是Composer会帮我们下载到本地。可是这⾥还有⼀个问题，下载下来以后怎么⽤，我们知道PHP⾥想⽤⼀个⽂件必须得include或require，Composer下载下来以后，这盘菜怎么吃，需要⾃⼰准备碗筷吗？还好还好，还有⼀个好东西，这个玩意它不⽣产代码，不提供任何实际问题的解决⽅案。他唯⼀做的事情就是BB， 那他BB⼀些什么呢？就像我上⾯说的那样，因为⼀些基础⼯具（⽐如Composer）的缺失，PHP开发很
难有⼀些标准，⽐如编码规范，⽐如⽬录结构，⽐如如何⾃动加载类，⽐如如何打log，⽐如如何使⽤缓存，这样就会导致什么呢？不同的公司、不同的PHP程序员就会开始⼋仙过海各显神通，当然这对开发来讲短时间到也没什么，可是长久来看，这是会增加开发成本、维护成本的，当我们换⼀家公司、接⼿⼀个项⽬我们要从头开始理解代码，甚⾄在⼀个团队⾥我们都会因为没有标准⽽增加沟通成本。所以PHP-FIG就做了这样的事：制定标准。他制定的标准有：
1. 编码规范 (psr-1psr-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"
}
],
"repositories": [
{
"type": "composer",
"url": "package.fmw"
}
],
目前行的php开发工具有
"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官⽅提供的⼯具就可以发挥作⽤了。
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": "packages.dev",
"repositories": [
{"type": "vcs", "url": "git.dev/maxincai/package1.git"},
{"type": "vcs", "url": "git.dev/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我们可以将业务逻辑、通⽤函数、逻辑拆分成不同的包，再也不需要做拷贝代码的蠢事了。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。