작곡가를 빠르게 배울 수 있어요!
- 藏色散人앞으로
- 2020-07-04 13:21:152892검색
다음 튜토리얼 칼럼인 composer에서는 작곡가를 배우는 방법을 소개하겠습니다. 도움이 필요한 친구들에게 도움이 되길 바랍니다!
시스템에 서로 다른 웹 애플리케이션이 있지만 많은 코드를 공유해야 할 때 해야 할 일
시스템에 확장 기능이 필요하고 누군가가 인터넷에 접속만 할 때 해야 할 일 우연히 사용법을 알려주게 되었어요
PHP 코드 업그레이드, 다운그레이드, 롤백
작업 분배 방법, 여러 엔지니어가 함께 개발 작업을 하게 하는 방법
저는 V5.3.5가 나온 2011년에 PHP를 접하게 되었습니다. 방금 출시되었습니다. 언어적 관점에서 보면 PHP에는 그다지 뚜렷한 결함이 없다고 생각됩니다. 풍부한 웹 기반 함수 라이브러리를 기반으로 클래스, SPL, 익명 함수 등도 있습니다. 이러한 기능(전혀 "특별한" 기능은 아님)은 대규모 프로젝트의 코딩 요구 사항을 지원하기에 충분합니다.
PHP5.3
그러나 실제로 개발하고 PHP를 사용하여 코드를 작성하려고 할 때 PHP와 관련이 없는 몇 가지 이상한 문제에 직면하는 경우가 많습니다. 하지만 여전히 머리가 아프다. 웹사이트를 작성하려면 인증코드가 필요할 수도 있지만, 대부분의 경우 인증코드를 직접 작성하고 싶지는 않습니다. 인터넷에 인증번호 종류가 너무 많아서 자연스럽게 직접 사용해보고 싶더라구요. 하지만 직접 사용하고 싶을 때 해야 할 일은 다음과 같습니다.
- 검색 엔진으로 이동하여 검색한 다음 각 결과에 내가 사용할 수 있는 적합한 코드가 있는지 확인하세요.
- 클래스를 찾았습니다. 이제 이 클래스를 내 프로젝트에 도입해야 합니다. 자동로드하는 방법? 확장명에 따라 달라지나요? 현재 사용하고 있는 것보다 더 높은 버전의 PHP에서 사용해야 합니까? 이것들은 모두 내가 해결하고 싶은 문제입니다.
- 2에서 언급한 문제를 모두 해결하고 싶다면 하나만 쓰면 어떨까요?
- f**k it
자체 코드를 사용하더라도 웹 애플리케이션이 여러 개 있을 때(컴퓨터 측, wap 측, api 인터페이스는 정상) 물론 하나의 프로젝트에 살지 않기를 바랍니다( 디렉토리) 진흙으로 인해 지정된 파일을 보는 것이 어려워지고 그에 따라 유지 관리 비용도 증가합니다. 그런데 이 웹어플리케이션을 분리하다 보니 공통코드(모델, 로직, 인증...)가 너무 많아서 웹어플리케이션의 작은 로직을 수정했는데, 이 코드들을 어떻게 처리해야 할까요? 다른 응용 프로그램에서는 기억이 나지 않거나 아주 작은 변화라도 컴퓨터를 부수고 싶거나, 직장을 그만두고 싶거나, 나가서 쉬고 싶을 정도입니다.
알겠습니다. 자동 로드를 통해 코드를 나누어서 사용하겠습니다. 이렇게 하면 더 많은 사람들이 개발에 참여할 수 있습니다. 하지만 온라인 상황이 너무 복잡하면 어떤 웹에 문제가 생기면 어떨까요? 응용 프로그램이 특별하고 새 코드가 적용되지 않습니까? 유지 관리도 문제입니다. 이렇게 다른 프로젝트에 의존하는 웹 애플리케이션을 인수할 경우, 코드를 조금만 변경하면 문제가 많이 생길 수 있습니다. 왜냐하면 자동 로드 코드로 인해 웹이 어떻게 작동하는지 직관적으로 알기 어렵기 때문입니다. 응용 프로그램이 다른 프로젝트에 사용되는 코드입니다.
하지만 PHP에 관해서는 결국 규칙을 어기고 싶지 않습니다. 작성하는 것이 너무 편리합니다. 아직은 그 함정에서 벗어나고 싶지 않아요. 하지만 위의 문제가 해결되지 않는다면 PHP를 작성하는 것은 여전히 매우 답답한 일이라고 개인적으로 생각합니다. 다른 언어가 이 문제를 어떻게 해결하는지 살펴보겠습니다. JAVA의 자연스러운 패키징 메커니즘을 통해 maven, node의 npm을 사용할 수 있으며 심지어 PHP보다 오래된 Perl에도 cpan이 있습니다. PHP에는 패키지 관리 메커니즘이 있어야 하지 않나요?
다행히도 이러한 문제는 PHP를 사용하는 데 너무 오랫동안 수반되지 않았습니다. 왜냐하면 곧 PHP에 Composer가 있고 해가 떴기 때문입니다.
Composer는 PHP용 종속성 관리 도구입니다. 이를 통해 프로젝트가 의존하는 코드 라이브러리를 선언할 수 있으며 프로젝트에 해당 라이브러리가 설치됩니다.
컴포저 중국어 공식 홈페이지 소개입니다.
이 문장은 제 경험을 바탕으로 설명하려고 합니다.
프로젝트가 의존하는 코드 베이스를 선언할 수 있습니다. 즉, 코드를 사용하려는 경우 더 이상 직접 복사할 필요가 없습니다. 대신 선언을 통해 Composer에 알릴 수 있습니다. 레스토랑에서 식사하려면 셰프에게 어떻게 해야 하는지 가르쳐줄 필요도 없고, 접시를 들고 직접 먹을 필요도 없습니다. 대신 웨이터에게 무엇을 말해야 할까요? 그냥 먹고 싶다고 말씀하세요 물론 제가 오늘 배탈이 난다고 말할 수는 없습니다. 가벼운 요리는 절대 이렇게 주문하지 않습니다. 정확히 당신이 먹고 싶은 요리의 구체적인 이름. 이전에 검색 엔진에서 코드를 찾는 것과 다른 점은 Composer를 키워드로 알 수는 없지만 원하는 코드 라이브러리 이름을 알려 주어야 한다는 것입니다. 코드 이름을 어떻게 알 수 있나요? 모든 코드를 담고 있고 우리가 그 코드를 찾아 이름을 알 수 있는 검색 기능을 제공하는 곳이 아니면 누구도 다른 사람의 코드 이름을 아는 것이 불가능합니다.
packagist.org가 하는 일입니다. 더 이상 운에 따라 찾기 위해 다양한 검색 엔진에 갈 필요가 없습니다. 여기에서 키워드를 검색하면 광고가 나타나지 않으며 Putian이나 JD도 나타나지 않습니다.
당신의 프로젝트에 설치해 줄 것입니다: Composer가 자연스럽게 우리가 접시를 가져오는 것을 도와줄 것입니다. 이것은 우리가 원하는 코드가 어디에 저장되어 있는지 알 수 없습니다. 하지만 Composer는 이를 로컬로 다운로드합니다. 하지만 여기에는 다운로드 후 어떻게 사용하는지에 대한 질문이 있습니다. PHP에서 파일을 사용하려면 Composer를 다운로드한 후 이 요리를 어떻게 먹어야 하는지 알고 있습니다. 그릇과 젓가락을 직접 준비하시나요? 다행스럽게도 PHP-FIG라는 또 다른 좋은 것이 있습니다. 이것은 코드를 생성하지 않으며 실제 문제에 대한 해결책을 제공하지 않습니다. 그가 하는 유일한 일은 바비큐뿐인데, 그가 바비큐를 하는 이유는 무엇입니까? 위에서 말했듯이 몇 가지 기본 도구(예: Composer)가 부족하여 PHP 개발에서는 코딩 표준, 디렉터리 구조, 클래스를 자동으로 로드하는 방법 등 몇 가지 표준을 갖기가 어렵습니다. 캐시 사용 방법과 같은 로그 방법은 무엇으로 이어질까요? 물론 다른 회사와 다른 PHP 프로그래머가 마법의 힘을 발휘하기 시작할 것입니다. 물론 이는 개발에 있어 단기적으로는 중요하지 않지만 장기적으로 다른 회사로 전환하면 개발 비용과 유지 관리 비용이 증가하게 됩니다. 프로젝트를 맡게 되면 처음부터 코드를 이해해야 하고, 팀 내에서도 표준이 없기 때문에 커뮤니케이션 비용이 늘어나게 됩니다. 그래서 PHP-FIG는 바로 그 일을 합니다: 표준을 설정합니다. 그가 공식화한 표준은 다음과 같습니다:
- 인코딩 사양(
psr-1psr-2) - 自动加载规范(
psr-4) - 一些通用接口 log(
psr-3) cache(psr-6) http(psr-7)
psr-1 psr-2)这些标准在官网上都有详细的描述。我们这里要讨论的是psr-4。我在这里按照我自己的理解和使用经验稍微阐述一下：psr-4的自动加载基于文件夹和命名空间，我们需要指明一个根目录对应一个根命名空间，在这个基础上，我们可以通过除去根命名空间以外的命名空间和类名来在根文件夹下找到这个PHP文件并加载
#根文件夹 lib#根命名空间 model#file lib/A.phpnamespace model;class A {}#file lib/entity/B.phpnamespace mode\entity;class B{}#file demo.php$a = new \model\A();$b = new \model\entity\B();
Composer就实现了可以根据指明标准（如psr-4）和映射关系(如代码中的lib->model)来生成自动加载类的功能。事实上Composer提供了这些标准：
files 指明PHP文件路径的方式，这种方式会在每次请求时都要载入这些文件，适合一些通用函数的PHP文件
Classmap 比files智能一些，可以指明一个文件夹或一个文件来进行自动加载，缺点是即使是指明了一个文件夹，这个文件夹下增加了一个文件都需要Composer重新生成一次autoload文件，适合一些不能使用psr-4的类或类库，比如一个第三方接口的client，这个client可能在psr-4规则出现之前就有了，那么我们还是希望用Composer进行管理就可以使用这种方式
psr-0 psr-4的前身，以前落伍了，就当我没说过psr-4 就像我上面介绍的，这种方式增加一个或多个文件也不需要重新生成autoload자동 로딩 사양(psr-4 code>)
psr-3) 캐시(psr-6) http(psr-7 code>) <p>이러한 표준은 공식 홈페이지에 자세히 설명되어 있습니다. 여기서 논의할 것은 psr-4이다. 여기에서는 내 자신의 이해와 경험을 바탕으로 설명하겠습니다. psr-4의 자동 로딩은 폴더와 네임스페이스를 기반으로 합니다. 이를 기반으로 루트 네임스페이스를 제거할 수 있습니다. 및 네임스페이스 외부의 클래스 이름을 사용하여 루트 폴더에서 이 PHP 파일을 찾아 로드합니다. </p>
<pre class="brush:php;toolbar:false">{
"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/"
}
}
}</pre>
<p>Composer는 지정된 표준(예: <code>psr-4) 및 매핑 관계(예: lib->model 등)을 코드에 추가하여 자동으로 클래스를 로드하는 기능을 생성합니다. 실제로 Composer는 다음과 같은 표준을 제공합니다. files는 PHP 파일의 경로를 지정하는 방법입니다. 이 방법은 몇 가지 일반적인 기능을 갖춘 PHP 파일에 적합합니다. 단점은 폴더를 지정하더라도 이 폴더에 파일을 추가하면 Composer가 자동 로드 파일을 다시 생성해야 하므로 일부 클래스나 사용할 수 없는 클래스에 적합합니다. psr-4. 타사 인터페이스 클라이언트와 같은 라이브러리입니다. 이 클라이언트는 psr-4 규칙이 나타나기 전에 존재했을 수 있습니다. 그렇다면 우리는 여전히 Composer를 사용하여 이 방법을 사용할 수 있습니다
psr -0 psr-4의 전신은 이전에 구식이었는데, 말하지 않은 척 하세요 🎜psr-4 위에서 소개한 것처럼 이 방법은 하나 이상의 파일 autoload 파일은 네임스페이스와 폴더 간의 매핑 관계에 따라 로드되므로 다시 생성할 필요가 없습니다. 🎜🎜이를 구현하는 Composer의 이점은 무엇입니까? 🎜🎜우리는 자동 로드 파일을 직접 작성할 필요가 없습니다. 동시에 이 표준은 이해하고 수용하기 쉽고 코드 유지 관리 및 학습 비용도 절감됩니다.🎜우리가 타사 라이브러리를 사용하는 한 자동 로딩을 처리하려면 Composer를 사용해야 합니다. 이 패키지만 있으면 Composer는 이 타사 라이브러리를 로드하는 코드도 처리합니다. 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：
name和description是你给这个php项目起的名字，当这个项目仅仅是一个web项目，这两个其实不是很重要，但是这个项目其实是一个向外发布的代码库，就很关键了，name需要独一无二，description需要一句话来描述这个包的作用。
authors就是相当于宣布一下主权，可以有多个
repositories相当于你需要下载的代码库所在的仓库，默认会有一个全局的仓库，具体是什么就不在这里说了，上面的某个网址有介绍，在这里添加一个是因为如果你有个私人的仓库（有些代码不太适合放在公开的仓库吧），则可以在这里声明
version是版本号，这个是跨时代的功能啊，有了这个，PHP程序员也可以刷版本号了啊！
require则是上面阐述了很多的功能，解决了我说的那些痛点，通过“name”:"version"声明，可以有多个，require以后使用composer install命令composer会下载代码并自动加载
require-dev用法一致，但是功能不同，是用来声明一些在开发时候才用到的包，比如测试、文档等等
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仓库生成器。使用它的步骤如下：
在合适的目录执行 php composer.phar create-project composer/satis --stability=dev --keep-vcs(前提是你已经按照Composer)
新建一个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": "*",
}
}
执行 php bin/satis build satis.json public/(public就是所有包的存放目录)
将public目录作为一个web服务对外发布就好了
使用的时候只需要在repositories多加一项（就像我在上面的composer.json做的那样），然后引入包就好了
关于Composer，上面就是我目前要说的了，通过Composer我们可以将业务逻辑、通用函数、逻辑拆分成不同的包，再也不需要做拷贝代码的蠢事了。
위 내용은 작곡가를 빠르게 배울 수 있어요!의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!