探索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