When you take on a new project, you can feel out of your depth, especially if you’re not familiar with programming. So where do we start? What parts of the project code do we need to focus on? Let’s look at a few common parts of the Laravel project.

Project documentation

Documentation can be the most helpful for a new project. If your project contains documentation, you’re in luck. However, don’t jump the gun, because documentation may be outdated or incomplete. Project documentation is usually written in readme files, wikis, or published on shared platforms such as Confluence and Google Docs. If you’re developing on a project, don’t be like, please actively contribute to the project documentation: fill in the blanks or make it clearer.

If you’re not lucky (and most of the time you are), the project you’re working on doesn’t have any documentation. The lack of documentation is not entirely a bad thing, because in this case, you have the opportunity to personally document your team. You and your colleagues, as well as the new developers you bring in, will be grateful to you in the future.

Writing documentation is not fun, but it is necessary to keep the project running in the long run. The project documentation should not only list the techniques used and the initial installation method, but also state the “why” and “how” of the project, which is often not clearly expressed in the code itself. Some high-level design choices and their reasons should also be documented to help better understand the code.

composer.json

Composer is a PHP package management tool that has helped drive the rapid progress of the PHP ecosystem over the past few years. Laravel has been using Composer since version 4, so there is almost always a Composer. Json file in the project. You can find the composer. Json file and composer. Lock file in the project root directory.

The Lock file contains the exact versions of all dependencies needed in the project, while the JSON file shows the distribution of dependencies. For now, we are only interested in the version information in JSON files, but if you want to learn more about these files, you can read here.

While browsing through the composer. Json file, you notice that there is a require block that looks like the following.

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

In this example, we have a project based on Laravel 5.6. It relies on two other packages, as well as at least version 7.1.3 of PHP. You will most likely see more dependency packages in your project, and version numbers may change.

Now that you know which extensions are being relied on in your project, figure out what each of them does. I recommend starting with Laravel dependencies because they are well documented. And the document is posted on the web, so it’s easy to find: {VERSION} and {VERSION} https://laravel.com/api/, https://laravel.com/docs/ Links such as laravel.com/docs/5.6 and laravel.com/api/5.6.

The document docs provides a comprehensive overview of laravel’s functions and how each of its major parts works. The API documentation also presents a list of classes and methods used in the Laravel framework.

After you have reviewed the Laravel document, you can move on to other dependent documents. You can go to Packagist (this is used by the Composer expansion pack warehouse) for more information on the dependence, the corresponding extension address to https://packagist.org/packages/ {VENDOR} / {PACKAGE}, Such as packagist.org/packages/fi… .

On the home page of each Packagist project, there is an introduction to the extension pack, the version number, the repository address (such as GitHub), the complete readme file, and other useful information. The information from the project home page is enough to give you an idea of what the extension package is and what part of your project it will perform. In this way, continue to learn about the other dependencies listed in the composer. Json file for your project application.

routing

Routing is an entry point to apply a specific function. A route is represented as a link, which is ultimately handled by the bound controller or closure when the browser accesses it. By finding the corresponding controller through the route, you can know the other modules that the controller depends on and the specific functions that the controller implements. Repeat the process as you encounter new routes, and you’ll gradually understand how the entire application works.

You can find the routing configuration file in the following location of the project:

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

Routing “trap”

Sometimes, locating a route based on a specific URL takes a little ingenuity.

Such as URI/Users /123/profile. You may want to search for route definitions in users/{id}/profile. In fact, it is defined in routing groups, which makes routing difficult to locate.

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

Copy the code

In this example, users and {ID}/profile are not written together, which is why it is difficult to locate. If there are not many routes, it is easier to find them. However, this can be very difficult when routing files have hundreds or thousands of definitions.

Another pit is Route:: Resource() (and Route::apiResource() in newer versions).

Route::resource() automatically generates routes based on the specified parameters. For example, add the code Route::resource(‘dogs’, ‘DogController’) to the routing file; This does the same thing as the code below.

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');
});

Copy the code

However, if you try to find something like dogs/{id}/edit, this will not be found because it is defined as part of Route::resource().

Sometimes it’s convenient to define routes directly with Route::resource(), but I prefer to define each Route individually so that each URI can be easily searched directly. For more information about routing resources and resource controllers, refer to these documents.

The easiest way to preview all the routes in the project is to use the artisan command route:list:

php artisan route:list

Copy the code

The route:list command provides complete details of each route, including HTTP request style, specific URI, route name, action information (that is, controllers and methods), and middleware information configured for each route.

Service provider

The service provider is where Laravel casts his magic. The official document sums it up:

The service provider is the boot center for all Laravel applications. Your application and all of Laravel’s core services are bootstrapped through the service provider.

By bootstrapping, we mean registration, such as registration of service container bindings, event listeners, middleware, and even routes. The service provider is central to configuring your application.

You can browse all application service providers in the app/providers directory. The added code around application customization should be here. For example, in some cases look for view synthesizers, macros, and make configuration adjustments.

In older versions of Laravel, such as 4.2, you would find similar functionality in the global.php file, since service providers were usually only used in packages at that time.

test

The code base includes test suites that show you how the application works and how it responds next. It can provide valuable clues to the boundary handling of applications. Of course, just like the code base documentation, the test files that accompany your application may not exist, be few, or even obsolete.

Just like writing project documentation, writing application matching tests can help you learn more about your project and improve the quality of your code. You might stumble upon and fix bugs, remove useless code, or add test coverage to important classes in your project.

tool

For Laravel developers, Barry Vd. Heuvel’s Laravel Debugbar is a debugging and traceability tool worth having. It is powerful and easy to install. You can see everything that happens in your application: routes and controllers that go by, database queries and execution times, data displays, exceptions, timelines for viewing execution and execution, and so on. After trying this package out, you’ll love it later in your Laravel application development.

The end of the

In this article, I suggest some ways to get started with the new Laravel project code. This article is not an exhaustive list, but a start. I encourage you to use these tips and see where it takes you. If you have any ideas to exchange, I’d love to hear about them! Feel free to contact us on Twitter.

From PHP/Laravel developer community laravel-china.org/topics/8897