http://www.phparch.com \ November 2018 \ 9Maintaining Laravel Applicationsapplications overwrite the default value instead of setting the
ENV value.
For example, consider the config/mail.php file:'from' => [
'address' => env('MAIL_FROM_ADDRESS',
'[email protected]'),
'name' => env('MAIL_FROM_NAME', 'Laravel Shift'),
],This approach edits the config/mail.php file directly. Instead,
set the environment variables and preserve the default values
so the config file remains unchanged.'from' => [
'address' => env('MAIL_FROM_ADDRESS',
'[email protected]'),
'name' => env('MAIL_FROM_NAME', 'Example'),
],This way, when it comes time to upgrade, you can simply
copy the latest config/mail.php into your project. Then, you
can review the file for any new environment variables.
When there are a lot of configuration options, consider
creating a new config file. Any PHP file within the config/
folder is automatically loaded by the framework. I often
create a config/system.php, config/settings.php, or something
domain specific like config/shift.php. This prevents lots of
changes being made to various config files and organizes
them to one file.
This file remains outside the framework and therefore isn’t
subject to changes between versions. But it also allows me to
leverage my own environment variables. This gives me the
best of both worlds—maintainability, and flexibility.Avoid Vanity Namespaces
Some applications still customize the default namespace.
These vanity namespaces create unnecessary overhead when
it comes time to upgrade. It becomes one more difference you
have to remember to change when adding new core files or
copying code samples. If you work on multiple Laravel appli-
cations, you have to remember this for each project.
Taylor Otwell, Jeffrey Way, and others have recommended
for a while now leaving it set to the default. If you’ve custom-
ized your application namespace, you can change it back by
running:
artisan app:name AppNote: This will not change the records in the database.
If you are storing class references, using polymorphic
relationships, for example, you will need to write a query
to change these.In addition to customizing the default namespace, some
applications create a separate namespace. This seems to beused to create separation between this code and the applica-
tion code. However, this is rather awkward. Usually, this code
lives within the app/ folder and is rarely shared with other
applications (if it were, it should be a package). So if it isn’t
shared, why is it separated? Whatever the reason, it again
creates cost without benefit—a cost you’ll have to pay when it
comes time to upgrade.Avoid Creating Your Own Folder Structure
One of the most common questions I hear when working
on Laravel applications is, “Where does this thing go?” Most
applications seem to leverage the native folders within the
app/ folder. So the question becomes where to put something
when that’s not a Controller, Model, Event, Command, etc.
This limits the scope as most applications don’t need classes
outside these core components. However, when they do a
majority of applications group these under a Services folder.
This seems to be a catch-all folder which contains classes of
varying responsibilities. While this is okay in the beginning,
it may be an opportunity to review these for better naming
and organization.
As an aside, 39 percent of applications contain an
app/Models folder. app/Models was a controversial change
from Laravel 4 to Laravel 5. One in three applications still
namespace models under app/Models. On average, this folder
exists when there are more than double-digit models (11 on
average). This is likely for organization, as not to clutter the
app/ folder with these files.
Finally, the app/helpers.php file is a common addition to
a Laravel application. Unfortunately, this file doesn’t have
a designated home and often ends up in the app/ folder.
However, as an un-namespaced file, it’s not autoloaded by
PSR-4 as the other files within the app/ folder. For applica-
tions that contain a helpers.php file, I find the bootstrap/
folder to be a more accurate location for its purposes—load
files necessary to start the application.Grok the Framework
In addition to these analytics, I also have insight into Lara-
vel developers through pairing and moderating the Shifty
Coders^2 Slack. You could ask any one of these developers for
my advice on how to do something, and you’ll get the same
response, “grok the framework.” Put simply, this means do it
the way the framework does. We’ll take a closer look at a few
areas developers may be able to grok more.Injecting Layers
Often applications will inject a layer into the inheritance
hierarchy. Most commonly a BaseController or BaseModel
class. While inheritance is a pillar of object-oriented program-
ming, it is not always the right solution. In the case of Laravel,2 Shifty Coders: https://laravelshift.com/shifty-coders