摘要：在每一個(gè)的項(xiàng)目主頁上，展示了擴(kuò)展包的介紹版本號(hào)倉庫地址如完整的文件，以及其他一些有用的信息。官方文檔給出了總結(jié)服務(wù)提供者是所有應(yīng)用程序引導(dǎo)中心。你可以瀏覽位于目錄下的所有應(yīng)用程序服務(wù)提供者。

當(dāng)你接手一個(gè)新項(xiàng)目的時(shí)候，可能會(huì)感到無從下手，如果不熟悉編程，則更是如此。那么，我們該從哪兒入手呢？項(xiàng)目代碼的哪些部分我們需要著重了解？下面我們看看 Laravel 項(xiàng)目的幾個(gè)通用的部分。

面對新項(xiàng)目時(shí)，文檔可能是最有幫助的。如果項(xiàng)目包含文檔，恭喜你，你非常幸運(yùn)。但是，也別高興地太早，因?yàn)槲臋n可能早已經(jīng)過時(shí)或覆蓋不全面。項(xiàng)目文檔通常編寫在 readme 文件中、wiki，或者發(fā)布在 Confluence 和 Google Docs 之類共享平臺(tái)上。如果你基于一個(gè)項(xiàng)目做開發(fā)，不要猶如，請積極的為項(xiàng)目文檔做貢獻(xiàn)：補(bǔ)充空白部分或者使其表達(dá)得更清晰明了。

如果你不夠幸運(yùn)的話（大多數(shù)時(shí)候都是如此），你接觸的項(xiàng)目沒有任何文檔。缺少文檔并不完全是一件壞事，因?yàn)樵谶@種情況下，你有機(jī)會(huì)親自為你的團(tuán)隊(duì)撰寫文檔。你和你的同事，以及你帶來的新開發(fā)者，都將會(huì)在未來對你感激不盡。

撰寫文檔確實(shí)不是一件有趣的工作，但它對于保持項(xiàng)目的長期運(yùn)行是很有必要的。項(xiàng)目文檔不僅要列舉使用的技術(shù)和初始安裝方法，同時(shí)也應(yīng)該闡述項(xiàng)目 “為什么這樣” 以及 “如何進(jìn)行” ，這通常不能清晰地用代碼自身表達(dá)出來。某些高層次的設(shè)計(jì)選擇及其原因也應(yīng)該被寫入文檔，以幫助更好地理解代碼。

Composer?是一個(gè) PHP 包管理工具，在過去的幾年中幫助推動(dòng)了 PHP 生態(tài)系統(tǒng)的快速前進(jìn)。 Laravel 從版本4開始使用 Composer ，所以在項(xiàng)目基本都存在 composer.json 文件。你能夠在項(xiàng)目根目錄下找到 composer.json 文件和 composer.lock 文件。

lock 文件包含了項(xiàng)目中所需要的所有依賴包的準(zhǔn)確版本，而 JSON 文件顯示了依賴包的發(fā)布內(nèi)容。目前，我們只對 JSON 文件中的版本信息感興趣，如果你想學(xué)習(xí)這些文件的更多知識(shí)，可以閱讀 這里。

在瀏覽 composer.json 文件時(shí)，注意到有一個(gè) require 區(qū)塊，看起來內(nèi)容類似如下所示。

{
    "require": {
        "php": ">=7.1.3",
        "fideloper/proxy": "~4.0",
        "laravel/framework": "5.6.*",
        "laravel/tinker": "~1.0"
    }
}

在這個(gè)樣例中，我們有一個(gè)基于 Laravel 5.6 的項(xiàng)目。它同時(shí)依賴于另外兩個(gè)包，以及不低于7.1.3版本的 PHP 。在你的項(xiàng)目中，你很可能會(huì)看到更多依賴包，并且版本號(hào)可能會(huì)有所變化。

現(xiàn)在你知道了項(xiàng)目中依賴了哪些擴(kuò)展包，去搞明白它們各自的功能。我推薦從 Laravel 依賴開始，因?yàn)樗鼈儞碛性敿?xì)的文檔。且文檔就發(fā)布在網(wǎng)絡(luò)上，很容易就能找到：https://laravel.com/docs/{VERSION}?和?https://laravel.com/api/{VERSION}，如下這種鏈接 https://laravel.com/docs/5.6>...。

文檔?docs?對 laravel 功能及各個(gè)主要部分的工作原理作了比較全面的介紹。同時(shí) ?api 文檔將 laravel 框架中所用到的類及方法以清單的形式呈現(xiàn)出來。

在查看了 Laravel 文檔之后，可以繼續(xù)查看其它依賴的文檔。你可以前往 Packagist?（這是 Composer 所使用的擴(kuò)展包倉庫）獲取關(guān)于依賴的更多信息，各擴(kuò)展對應(yīng)的地址為https://packagist.org/packages/{VENDOR}/{PACKAGE}，比如 https://packagist.org/package...。

在每一個(gè) Packagist 的項(xiàng)目主頁上，展示了擴(kuò)展包的介紹、版本號(hào)、倉庫地址（如 GitHub）、完整的 readme?文件，以及其他一些有用的信息。從項(xiàng)目主頁上獲得的信息足夠使你了解這個(gè)擴(kuò)展包是什么，在你的項(xiàng)目中又承擔(dān)哪部分功能。通過這種方式，繼續(xù)去了解你項(xiàng)目應(yīng)用的 composer.json? 文件中所羅列出的其他依賴。

路由是應(yīng)用某個(gè)具體功能的入口。路由表現(xiàn)為一個(gè)鏈接，瀏覽器訪問鏈接時(shí)，最終由綁定的控制器或閉包來處理。由路由找到具體對應(yīng)的控制器，就能清楚控制器所依賴的其他模塊以及實(shí)現(xiàn)的具體功能。遇到新的路由，繼續(xù)重復(fù)這一動(dòng)作，就能逐步搞清楚整個(gè)應(yīng)用是怎么工作的。

你可以在項(xiàng)目的如下位置找到路由配置文件:

Laravel 5.3+?routes/*.php

Laravel 5.0-5.2?app/Http/routes.php

Laravel 4.2?app/routes.php

某些時(shí)候，根據(jù)具體 URL 定位路由需要費(fèi)些腦子。

比如 URI?/users/123/profile。你可能想要去搜索?users/{id}/profile 的路由定義。事實(shí)上，它是定義在?路由分組?中，這使得路由比較難定位。

Route::prefix("users")->group(function () {
    Route::get("{id}/profile", "UsersController@profile");
});

在這個(gè)例子中，users?和?{id}/profile?并沒有被寫在一起，這是難以定位的原因。如果路由不多，還能比較輕易的找出。但是，當(dāng)路由文件有成百上千條定義時(shí)，這將會(huì)變得非常困難。

另外一個(gè)坑是?Route::resource()?（還有新版本中的?Route::apiResource()）。

Route::resource() 將自動(dòng)根據(jù)指定參數(shù)生成路由。舉個(gè)例子，在路由文件中添加代碼 Route::resource("dogs", "DogController"); 將完成與下述代碼相同的功能。

Route::group(["prefix" => "dogs"], function () {
    Route::get("/", "DogsController@index")->name("dogs.index");
    Route::get("create", "DogsController@create")->name("dogs.create");
    Route::post("/", "DogsController@store")->name("dogs.store");
    Route::get("{id}", "DogsController@show")->name("dogs.show");
    Route::get("{id}/edit", "DogsController@edit")->name("dogs.edit");
    Route::put("{id}", "DogsController@update")->name("dogs.update");
    Route::delete("{id}", "DogsController@destroy")->name("dogs.destroy");
});

然而，如果你嘗試查找類似 dogs/{id}/edit 的內(nèi)容，這是找不到的，因?yàn)樗亩x是作為 Route::resource() 的其中一部分。

有時(shí)通過 Route::resource() 方式直接定義路由是挺方便的，但我更傾向于多帶帶地定義每一個(gè)路由，這樣能使每個(gè) URI 更容易被直接搜索到。了解更多路由資源和資源控制器的相關(guān)信息，可以查閱這些 文檔 。

預(yù)覽項(xiàng)目中的所有路由的最簡單方式是使用 artisan 命令 route:list ：

php artisan route:list

route:list 命令提供了每個(gè)路由的完整細(xì)節(jié)，包括 HTTP 請求方式，具體的 URI ，路由名稱，動(dòng)作信息（也就是控制器及其方法），以及為每個(gè)路由配置的中間件信息。

服務(wù)提供者是 Laravel 釋放魔法之地。 官方文檔 給出了總結(jié)：

服務(wù)提供者是所有 Laravel 應(yīng)用程序引導(dǎo)中心。你的應(yīng)用程序以及 Laravel 的所有核心服務(wù)都是通過服務(wù)提供器進(jìn)行引導(dǎo)。
在這里，我們說的「引導(dǎo)」其實(shí)是指注冊，比如注冊服務(wù)容器綁定、事件監(jiān)聽器、中間件，甚至是路由的注冊。服務(wù)提供者是配置你應(yīng)用程序的中心。

你可以瀏覽位于 app/providers 目錄下的所有應(yīng)用程序服務(wù)提供者。圍繞應(yīng)用自定義增加的相關(guān)代碼，理應(yīng)在這里。例如，一些情況下要查找視圖合成器，宏，并做配置調(diào)整。

在舊版本的 Laravel 中，如 4.2，你會(huì)在 global.php 文件中發(fā)現(xiàn)類似的功能，因?yàn)槟菚r(shí)服務(wù)提供者通常只在包中使用。

代碼庫包含的測試套件能向你展示應(yīng)用程序如何工作以及接下來的響應(yīng)。對應(yīng)用的邊界處理情況，它可以提供有價(jià)值的線索。當(dāng)然，就像代碼庫文檔一樣，應(yīng)用配套的測試文件有可能不存在，或者很少，甚至是無用的過時(shí)文件。

同寫項(xiàng)目文檔一樣，寫應(yīng)用配套測試同樣可以更好的學(xué)習(xí)項(xiàng)目應(yīng)用，提升代碼質(zhì)量。你可能偶然發(fā)現(xiàn)并修復(fù)一些缺陷，移除無用的代碼，或者為項(xiàng)目中重要的類新增測試覆蓋。

對 Laravel 開發(fā)者而言，Barry vd. Heuvel 發(fā)布的 Laravel Debugbar 是值得擁有的調(diào)試和追溯工具。它功能強(qiáng)大，安裝便易?？梢詫?yīng)用程序中所發(fā)生的事情一覽無余：經(jīng)過的路由和控制器，數(shù)據(jù)庫查詢和執(zhí)行時(shí)間，數(shù)據(jù)展示，異常，查看執(zhí)行內(nèi)容和執(zhí)行過程時(shí)間線等等。嘗試過使用這個(gè)包后，你將在之后的 Laravel 應(yīng)用開發(fā)中對它愛不釋手。

在這篇文章中，我提出了一些方法，方便你很快上手新的 Laravel 項(xiàng)目代碼。這篇文章并非一份包含所有細(xì)節(jié)的清單，只是一個(gè)起步。我鼓勵(lì)你使用這些建議，看看它能把你帶到哪里。如果您有任何交流的想法，我很樂意聽到它們！歡迎隨時(shí)聯(lián)系?Twitter。

轉(zhuǎn)自 PHP / Laravel 開發(fā)者社區(qū) https://laravel-china.org/top...