刚接触一个 Laravel 项目，你可以从这些地方入手

当你接手一个新项目的时候，可能会感到无从下手，如果不熟悉编程，则更是如此。那么，我们该从哪儿入手呢？项目代码的哪些部分我们需要着重了解？下面我们看看 Laravel 项目的几个通用的部分。

项目文档

面对新项目时，文档可能是最有帮助的。如果项目包含文档，恭喜你，你非常幸运。但是，也别高兴地太早，因为文档可能早已经过时或覆盖不全面。项目文档通常编写在 readme 文件中、wiki，或者发布在 Confluence 和 Google Docs 之类共享平台上。如果你基于一个项目做开发，不要犹如，请积极的为项目文档做贡献：补充空白部分或者使其表达得更清晰明了。

如果你不够幸运的话（大多数时候都是如此），你接触的项目没有任何文档。缺少文档并不完全是一件坏事，因为在这种情况下，你有机会亲自为你的团队撰写文档。你和你的同事，以及你带来的新开发者，都将会在未来对你感激不尽。

撰写文档确实不是一件有趣的工作，但它对于保持项目的长期运行是很有必要的。项目文档不仅要列举使用的技术和初始安装方法，同时也应该阐述项目 “为什么这样” 以及 “如何进行” ，这通常不能清晰地用代码自身表达出来。某些高层次的设计选择及其原因也应该被写入文档，以帮助更好地理解代码。

composer.json

Composer 是一个 PHP 包管理工具，在过去的几年中帮助推动了 PHP 生态系统的快速前进。 Laravel 从版本4开始使用 Composer ，所以在项目基本都存在 composer.json 文件。你能够在项目根目录下找到 composer.json 文件和 composer.lock 文件。

lock 文件包含了项目中所需要的所有依赖包的准确版本，而 JSON 文件显示了依赖包的发布内容。目前，我们只对 JSON 文件中的版本信息感兴趣，如果你想学习这些文件的更多知识，可以阅读这里。

在浏览 composer.json 文件时，注意到有一个 require 区块，看起来内容类似如下所示。

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

在这个样例中，我们有一个基于 Laravel 5.6 的项目。它同时依赖于另外两个包，以及不低于7.1.3版本的 PHP 。在你的项目中，你很可能会看到更多依赖包，并且版本号可能会有所变化。

现在你知道了项目中依赖了哪些扩展包，去搞明白它们各自的功能。我推荐从 Laravel 依赖开始，因为它们拥有详细的文档。且文档就发布在网络上，很容易就能找到：https://laravel.com/docs/{VERSION} 和 https://laravel.com/api/{VERSION}，如下这种链接 https://laravel.com/docs/5.6>...。

文档 docs 对 laravel 功能及各个主要部分的工作原理作了比较全面的介绍。同时 api 文档将 laravel 框架中所用到的类及方法以清单的形式呈现出来。

在查看了 Laravel 文档之后，可以继续查看其它依赖的文档。你可以前往 Packagist （这是 Composer 所使用的扩展包仓库）获取关于依赖的更多信息，各扩展对应的地址为https://packagist.org/packages/{VENDOR}/{PACKAGE}，比如 https://packagist.org/package...。

在每一个 Packagist 的项目主页上，展示了扩展包的介绍、版本号、仓库地址（如 GitHub）、完整的 readme 文件，以及其他一些有用的信息。从项目主页上获得的信息足够使你了解这个扩展包是什么，在你的项目中又承担哪部分功能。通过这种方式，继续去了解你项目应用的 composer.json 文件中所罗列出的其他依赖。

路由

路由是应用某个具体功能的入口。路由表现为一个链接，浏览器访问链接时，最终由绑定的控制器或闭包来处理。由路由找到具体对应的控制器，就能清楚控制器所依赖的其他模块以及实现的具体功能。遇到新的路由，继续重复这一动作，就能逐步搞清楚整个应用是怎么工作的。

你可以在项目的如下位置找到路由配置文件:

Laravel 5.3+ routes/*.php
Laravel 5.0-5.2 app/Http/routes.php
Laravel 4.2 app/routes.php

路由 "陷阱"

某些时候，根据具体 URL 定位路由需要费些脑子。

比如 URI /users/123/profile。你可能想要去搜索 users/{id}/profile 的路由定义。事实上，它是定义在路由分组中，这使得路由比较难定位。

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

在这个例子中，users 和 {id}/profile 并没有被写在一起，这是难以定位的原因。如果路由不多，还能比较轻易的找出。但是，当路由文件有成百上千条定义时，这将会变得非常困难。

另外一个坑是 Route::resource() （还有新版本中的 Route::apiResource()）。

Route::resource() 将自动根据指定参数生成路由。举个例子，在路由文件中添加代码 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 的内容，这是找不到的，因为它的定义是作为 Route::resource() 的其中一部分。

有时通过 Route::resource() 方式直接定义路由是挺方便的，但我更倾向于单独地定义每一个路由，这样能使每个 URI 更容易被直接搜索到。了解更多路由资源和资源控制器的相关信息，可以查阅这些文档。

预览项目中的所有路由的最简单方式是使用 artisan 命令 route:list ：

php artisan route:list

route:list 命令提供了每个路由的完整细节，包括 HTTP 请求方式，具体的 URI ，路由名称，动作信息（也就是控制器及其方法），以及为每个路由配置的中间件信息。

服务提供者

服务提供者是 Laravel 释放魔法之地。官方文档给出了总结：

服务提供者是所有 Laravel 应用程序引导中心。你的应用程序以及 Laravel 的所有核心服务都是通过服务提供器进行引导。
在这里，我们说的「引导」其实是指注册，比如注册服务容器绑定、事件监听器、中间件，甚至是路由的注册。服务提供者是配置你应用程序的中心。

你可以浏览位于 app/providers 目录下的所有应用程序服务提供者。围绕应用自定义增加的相关代码，理应在这里。例如，一些情况下要查找视图合成器，宏，并做配置调整。

在旧版本的 Laravel 中，如 4.2，你会在 global.php 文件中发现类似的功能，因为那时服务提供者通常只在包中使用。

测试

代码库包含的测试套件能向你展示应用程序如何工作以及接下来的响应。对应用的边界处理情况，它可以提供有价值的线索。当然，就像代码库文档一样，应用配套的测试文件有可能不存在，或者很少，甚至是无用的过时文件。

同写项目文档一样，写应用配套测试同样可以更好的学习项目应用，提升代码质量。你可能偶然发现并修复一些缺陷，移除无用的代码，或者为项目中重要的类新增测试覆盖。

利器

对 Laravel 开发者而言，Barry vd. Heuvel 发布的 Laravel Debugbar 是值得拥有的调试和追溯工具。它功能强大，安装便易。可以将应用程序中所发生的事情一览无余：经过的路由和控制器，数据库查询和执行时间，数据展示，异常，查看执行内容和执行过程时间线等等。尝试过使用这个包后，你将在之后的 Laravel 应用开发中对它爱不释手。