Laravel 2018使用數據分析——Laravel你用對了嗎？學對了嗎？

時間  2019-11-30
標籤 laravel 使用 數據 分析 對了 简体版
原文   原文鏈接

本文所說的Laravel 2018使用數據分析，指的是Laravel Shift的做者Jason McCreary，基於使用Laravel Shift的超過8000個laravel應用所作的分析。（Laravel Shift是一個自動升級你的laravel版本的付費應用，好比你的項目版本是5.1,使用它呢能夠自動給你升級到5.6,這期間省去你手動升級的繁瑣和煩惱。）php

更好的閱讀體驗請移步：www.pilishen.com/posts/larav…html

截至到2018年7月，Laravel Shift裏有超過8500個上傳的laravel apps，每一次版本的升級，Laravel Shift都會生成一個日誌文件以用於debug，基於這些日誌文件，產生了今天咱們提到的laravel使用數據。下面是Laravel Shift裏日誌文件一瞥：前端

*** _Shift_ version: 0281cff03fee62f250253f1e485dc7a790209866
*** Cloning app...

>>> _Shift_ 5.2 Event: app did not contain references to SelfHandling
>>> _Shift_ 5.2 Event: could not upgrade middleware Data: ["app\/Http\/Middleware\/Authenticate.php","app\/Http\/Middleware\/EncryptCookies.php","app\/Http\/Middleware\/RedirectIfAuthenticated.php"]
>>> _Shift_ 5.2 Event: could not upgrade app/Providers/RouteServiceProvider.php
>>> _Shift_ 5.2 Event: could not patch app/Providers/RouteServiceProvider.php
>>> _Shift_ 5.2 Event: could not find User model path
>>> _Shift_ 5.2 Event: found additional uses of Event names
>>> _Shift_ 5.2 Event: matched core file: phpunit.xml with version: 5.1.11
>>> _Shift_ 5.2 Event: matched core file: tests/TestCase.php with version: 5.1.33
>>> _Shift_ 5.2 Event: matched core file: database/migrations/2014_10_12_100000_create_password_resets_table.php with version: 5.1.33
>>> _Shift_ 5.2 Event: matched core file: public/.htaccess with version: 5.1.33
>>> _Shift_ 5.2 Event: matched core file: config/broadcasting.php with version: 5.1.11
>>> _Shift_ 5.2 Event: matched core file: config/cache.php with version: 5.1.33
>>> _Shift_ 5.2 Event: matched core file: config/compile.php with version: 5.1.33
>>> _Shift_ 5.2 Event: matched core file: config/database.php with version: 5.1.11
>>> _Shift_ 5.2 Event: matched core file: config/filesystems.php with version: 5.1.33
>>> _Shift_ 5.2 Event: matched core file: config/queue.php with version: 5.1.11
>>> _Shift_ 5.2 Event: matched core file: config/view.php with version: 5.1.33
>>> _Shift_ 5.2 Event: could not upgrade config files Data: {"1":"config\/auth.php","2":"config\/mail.php","3":"config\/services.php","4":"config\/session.php"}
>>> _Shift_ 5.2 Event: could not upgrade package.json
>>> _Shift_ 5.2 Event: app contained phpspec/phpspec requirement of ~2.1
>>> _Shift_ 5.2 Event: found customized namespace

*** _Shift_ ran in: 212.209509
複製代碼

從這些日至裏能夠看到哪些文件被升級了，用到了哪些功能、哪些組件，等等。ios

(一)最流行的Laravel版本——5.3

不少apps停留在了5.3,可能由於PHP版本的要求，由於到了5.4測試想轉換到Dusk，或者auth組件的變化等。laravel

這應該符合現實狀況，由於laravel在5.2～5.3期間一方面作了不少變更，你們要逐步適應和學習，另外一方面這些人性化的變更也讓laravel更加流行和易用，laravel被大批量地用於生產環境，同時這些變更自己，也逐漸使laravel趨於成熟，知足了你們實際項目的大部分須要。可能沒有了特殊的功能須要，你們也就不會那麼急迫地更新版本，自己laravel 5.4開始的更新變更也相對小了不少。git

固然，也能夠說你們的項目還都在「升級的過程當中」，取決於升級的時間、人力成本等因素，若是能夠的話，可能你們都還想升到laravel 5.5,也即第二個LTS版本。github

(二)最流行的第三方組件

須要注意的是，接下來的數據樣本，laravel 5.5及以上版本的要小一些，同時laravel自身的核心組件，都被排除在外了。web

  • 58% of apps use guzzlehttp/guzzle
  • 36% of apps use predis/predis
  • 34% of apps use laravelcollective/html
  • 32% of apps use league/flysystem-aws-s3-v3
  • 27% of apps use intervention/image
  • 25% of apps use maatwebsite/excel
  • 24% of apps use spatie/laravel-backup
  • 23% of apps use laravel/horizon
  • 22% of apps use bugsnag/bugsnag-laravel
  • 21% of apps use laravel/socialite
  • 20% of apps use laravel/passport
  • 19% of apps use sentry/sentry-laravel
  • 15% of apps use spatie/laravel-permission
  • 14% of apps use laravel/scout
  • 14% of apps use league/csv

流行的開發輔助組件：redis

  • 35% of apps use barryvdh/laravel-debugbar
  • 28% of apps use barryvdh/laravel-ide-helper
  • 19% of apps use laravel/dusk
  • 11% of apps use laravel/browser-kit-testing

編者點評：sql

  • 值得一提的是，早在兩年前（2016年），這裏面的一些對於初學者來講比較關鍵的第三方組件，在咱們的Laravel系列課程裏也都帶領你們使用過了，好比必備的表單組件laravelcollective/html，在咱們《Laravel實戰：任務管理系統（一）》就跟你們見面了；
  • 處理圖片必備的intervention/image，也在咱們《Laravel實戰：任務管理系統（一）》中大量使用，後來出現了不少其餘的圖片相關組件，但每每背後也是基於的intervention/image，好比說近來流行的spatie/laravel-medialibrary；
  • 項目備份必備的spatie/laravel-backup，是咱們在《Laravel&Vue實戰：任務管理系統二》一開始就使用的，當時該組件還名不見經傳；
  • 關於權限，能夠說一開始數一數二的是Zizaco/entrust,爲此呢咱們還專門出了免費的公開課《Laravel Entrust角色權限管理》，可是呢entrust的做者忽然從去年開始不怎麼活躍了，因而santigarcor/laratrust做爲entrust的維護版本出現，已經安裝了entrust的能夠無縫遷移到laratrust上，固然這期間另外一個權限組件spatie/laravel-permission憑藉其強大的活躍也流行起來了，Laravel也推出了自身的權限功能——Policy。因此權限這塊，其實用哪一個功能就取決於你本身了，都不錯，均可以，那麼若是你權限這塊感受有障礙，仍是推薦咱們的免費的公開課《Laravel Entrust角色權限管理》，瞭解了原理之後，你能夠自行在santigarcor/laratrust或spatie/laravel-permission之間選擇。
  • 搜索必備組件laravel/scout，這個背後的driver默認基於的是付費服務Algolia，在國內咱們更喜歡開源的Elasticsearch，laravel/scout與Elasticsearch搭配來開發實時搜索相關的功能，能夠看咱們的《Laravel & Elastic全文搜索實戰》課程。
  • 關於guzzlehttp/guzzle排第一位，多是由於這兩年api開發開始流行，傳統上咱們常常用guzzle來處理http請求，因爲數據來源大部分都是5.3及如下的，這個時候passport與axios還剛開始流行，因此這一點上，可能後期咱們會看到passport的排名將攀升，axios由於是前端組件，可能就會被排除在統計數據以外了，可是咱們毫不能忽視它的日發流行。

（三）改動最多的文件——config

config文件是改動最多的，雖然這很合理，可是呢改動默認的config文件，也容易致使升級障礙。一般，你能夠有其餘的方式來處理這些改動，從而使config文件保持默認的樣子。

這期間必定記得經過ENV環境變量來改動config文件的值。不少應用喜歡改變config文件當中的默認值，而不是設置ENV，好比假設config/mail.php:

'from' => [
    'address' => env('MAIL_FROM_ADDRESS', 'shift@laravelshift.com'),
    'name' => env('MAIL_FROM_NAME', 'Laravel _Shift_'),
],
複製代碼

這樣呢並很差，仍是得設置ENV，讓config文件保持默認：

'from' => [
    'address' => env('MAIL_FROM_ADDRESS', 'hello@example.com'),
    'name' => env('MAIL_FROM_NAME', 'Example'),
],
複製代碼

當你有不少的配置選項須要設置時，再一種方式就是建立你本身的config文件，好比建立config/system.php, config/settings.php，這樣你就不用分別改動多個config文件了。

（四）不推薦自定義的全局namespace

使用默認的APP namespace就好。有9%的apps使用了自定義的namespace，而這個數值應該是0.

若是你更改過namespace，能夠這樣來改回：

artisan app:name App
複製代碼

固然這並不能改回你在數據庫當中，使用到多極對應關係（polymorphic relationships）時的記錄，那個你得本身經過sql query來改變了。

編者按： 這個呢，其實在5.3及如下版本，若是經過artisan app:name改變了namespace，其實是會發生不少莫名bug的，因此不推薦出於好奇隨便設置app:name，除非你知道本身在幹什麼。

（五）apps的目錄結構

接下來是在app目錄下發現的非laravel官方文件夾：

  • 36% of apps contain app/Models
  • 29% of apps contain app/Services
  • 29% of apps contain app/Helpers
  • 25% of apps contain app/Traits
  • 20% of apps contain app/Rules
  • 18% of apps contain app/Repositories
  • 17% of apps contain app/helpers.php

在laravel 4時代，是默認有app/Models文件夾的，到了5, laravel做者特地將其刪掉，由於model這個詞在不一樣的人那裏理解不同，有的人認爲一個app的model是其整個的業務邏輯，有的人認爲model是一些與關係型數據庫進行交互的class，爲了避免限制你們，乾脆刪掉，讓開發者本身決定該怎麼安置model，也即你能夠本身建立app/Models文件夾，而後遵循MVC框架的傳統方式，也能夠「面向業務（service）」，搞一個DDD（Domain-Driven Design）。

固然，這裏手動建立 app/Models的，通常都是model數量超過了10個。可是，這裏咱們想更進一步地，若是model數量超過50個呢？這個時候仍是簡單地放在 app/Models裏，還有特別的意義嗎？

app/Services文件夾通常放置一些獨立的業務相關的邏輯，能夠用來將你的某一部分業務邏輯獨立出來，使業務邏輯模塊化，甚至方便後期將其獨立成爲單獨的package給其餘的項目使用，或者成爲一個microservice，關於面向service，或者說package開發，就須要你對laravel底層及其原理有足夠的掌握了，這裏就推薦咱們的《Laravel底層核心技術實戰揭祕》

app/Helpers和app/helpers.php應該大同小異，前者放置一些輔助功能的class，後者放置一些全局的helper function，這個在咱們的《Laravel&Vue實戰：任務管理系統二》中也給你們介紹過了。

app/Rules，這個文件夾嚴格來講是laravel自己的，由於它是咱們執行artisan make:rule後產生的，關於laravel 5.5之後建立自定義的驗證規則，也即rule，若是有不懂的同窗，能夠看咱們以前給你們提供的文章：【Laravel 5.5新特性】更方便地建立自定義的數據驗證規則 和 Laravel的unique和exists驗證規則的優化

關於repository，是否放置在app/Repositories內不是關鍵，關鍵是你是否使用，Repository Design Pattern能夠說是laravel自己以及其衆多第三方組件的命脈之一，Repository Design Pattern對於你分離業務邏輯，或者開發package，也很是關鍵。repository在laravel剛出來的時候，曾經在國外社區盛極一時，可謂是學laravel必學的，大概在2014年左右能夠說是成爲一種規範和標準在推行，甚至官方很是簡單的起步項目都要介紹和使用，可是呢國內laravel流行的較晚一些，等到國內開始追逐laravel的時候，國外社區都「懶得提」repository了，加上不少國內材料或教程有意無心地躲避repository，說太複雜了不適合新手，不必讓新手學之類的。但其實不是，並不複雜，也並不須要向所謂的新手藏着掖着，不然新手怎麼成爲高手？

若是你對repository還感到陌生，不知道是咋回事，那麼請務必看看咱們的《Laravel實戰：任務管理系統（一）》,該課程可謂是國內惟一在初學階段就讓你輕鬆嚐鮮Repository Design Pattern的，讓你在初學階段就打下往後成爲高手的根基，固然若是你想真真正正掌握Repository Design Pattern的全貌，仍是推薦咱們的《Laravel底層核心技術實戰揭祕》

（六）改造基本的繼承關係

這個通常是指本身額外建立一個BaseController 或者 BaseModel class，讓它們繼承laravel默認的controller或model，而後本身的具體的controller或者model再繼承這個BaseController 或者 BaseModel,這期間就能夠在BaseController 或者 BaseModel裏作一些本身的邏輯。

有23%的應用這麼作了，這個呢其實也是不推薦的，這種作法每每在早期的一些國外教程或材料中能看到，可是新近的都不會這麼搞，同時這個應該在國內不是很大的問題。

就好比說model，當咱們想擴展其功能的時候，更優雅的辦法是使用trait，而不是寫到BaseModel裏，這符合咱們編程設計原則裏常說的「composition over iinheritance」

（七）Facade的濫用

57%的應用濫用，或者說過分使用facade。Facade自己已然是laravel社區內一個極具爭議的話題，或者說是laravel備受非議的一個話題，關於這一點，若是有不瞭解的，能夠看看咱們以前給你們寫的擴展文章PHP中的facade pattern（外觀模式）。那麼大部分的apps亂用facade，無異於火上澆油了。最大的爭議發生在controller和middleware當中濫用Request和Auth

好比一塊兒看一下這個controller邏輯：

public function store()
{
    $data = Request::only('product_id', 'token');

    if (Auth::check()) {
        $data['email'] = Auth::user()->email;
    }

    // ...
}
複製代碼

這裏呢使用Request來獲取請求數據，使用Auth來獲取當前用戶。可是呢，不管是controller仍是middleware，均可以注入一個request實例：

public function store(Request $request)
{
    $data = $request->only('product_id', 'token');

    if ($request->user()) {
        $data['email'] = $request->user()->email;
    }

    // ...
}
複製代碼

這樣就不用調用兩個facade，而只經過一個request object。關於方法注入、或者依賴注入、或者依賴解析等，不管是咱們的初級課程《Laravel實戰：任務管理系統（一）》，仍是咱們的高級課程《Laravel底層核心技術實戰揭祕》,都有大量的講解和使用，這些也是掌握laravel、成爲高手的關鍵。

固然，若是你有真正學習了咱們的《Laravel底層核心技術實戰揭祕》,或者在閱讀PHP中的facade pattern（外觀模式）之餘作足了功夫，那麼你會明白，上面的代碼也並不能徹底解決facade濫用的問題，由於畢竟Request自己也是一個facade，可是畢竟下降了問題的程度，從而在更好的程序設計和測試過程當中，能更大程度地解耦。

（八）View視圖中的query查詢

24%的應用在view中存在數據查詢，這天然是bad practice，視圖層不該該直接交互Model，確保使用Controller來傳遞相關的數據

（九）不要直接調用ENV變量值

42%的應用直接調用ENV變量。Laravel提供了artisan config:cache來提升性能，爲了充分利用這一功能，不要直接調用env數據，而是在config文件中調用。所以，你必須得經過config來間接獲取env數值

（十）CRUD型Controller

77%的應用尚未採用CRUD型Controller。所謂CRUD型Controller，指的是將controller裏的方法限制爲默認的CRUD這四類，或者說是默認的resourceful controller，也即裏面只有index()、create()、store()、update()、edit()、show()、destroy()這七個方法，任何多出來的方法均可以重構到單獨的一個controller，這符合坊間「全部的操做其實歸根到底都是CRUD操做」的說法。

固然這一理念呢，還比較新穎，屬因而2017年的laravel國際會議laracon上纔開始推薦，因此大部分的應用尚未真正地實踐，應該國內的開發者也大都對此陌生，不過沒關係，在近期的課程更新中，咱們將會在《Laravel底層核心技術實戰揭祕》中給你們介紹相似的一些流行作法。

（十一）Controller內的數據驗證（Validation）

89%的應用在Controller內進行數據驗證，這也是很差的實踐——正如咱們在入門課程《Laravel實戰：任務管理系統（一）》裏就講過的，Controller只是一個「指揮者」，它正常來講不負責任何具體的邏輯，因此此處的數據驗證，最好是放到單獨的Request文件中，正如咱們在入門課程裏提倡的那樣。

（十二）Blade相關的命令

71%的應用尚未使用Laravel提供的一些blade命令。用的最少，但每每最有用的是@auth，@guest，@json，@method，@csrf。

固然，這一項所提到的blade命令，其實大都是laravel 5.5才新出的，甚至有些呢文檔上也沒有說起，因此你們可能還不熟悉。天然，咱們在blade裏面可使用原生的PHP標籤，可是那樣就有可能沒有充分利用起來laravel給咱們提供的便利與優雅，因此blade當中，咱們常常也提倡儘量地不用原生php標籤。

關於blade命令，咱們以前也給你們寫過兩篇文章：【Laravel 5.5新特性】能夠在blade中自定義if判斷的簡略標籤 和 Laravel Blade中的@each用法

（十三）額外的一些數據分析

最後呢是一些附加的統計數據，注意的是，該項數據樣本相對較小，並且只是限於laravel 5.5及更新版本，該項數據的生成使用的是stefanzweifel/laravel-stats這個組件。

+-------------------+-------+---------+---------------+------------+
| Name              | Usage | Classes | Methods/Class | LoC/Method |
+-------------------+-------+---------+---------------+------------+
| Commands          |   66% |    6.37 |          2.42 |       9.68 |
| Controllers       |   67% |   20.91 |          4.10 |       6.28 |
| Events            |   29% |    5.63 |          1.64 |       7.69 |
| Jobs              |   31% |    4.11 |          2.36 |      11.84 |
| Listeners         |   39% |    5.35 |          1.89 |       5.16 |
| Mails             |   39% |    6.72 |          2.06 |       6.71 |
| Middleware        |  100% |    4.22 |          0.12 |       4.93 |
| Models            |   99% |   17.80 |          3.75 |       3.79 |
| Notifications     |   39% |    4.57 |          3.80 |       3.71 |
| Policies          |   19% |    5.09 |          3.96 |       2.88 |
| Requests          |   58% |   11.04 |          2.07 |       2.52 |
| Resources         |    7% |   14.75 |          0.94 |       4.95 |
| Rules             |   17% |    2.40 |          3.07 |       2.86 |
| Service Providers |  100% |    6.28 |          1.97 |       4.61 |
| PHPUnit Tests     |  100% |    9.96 |          2.02 |       6.63 |
| Dusk Tests        |   18% |       5 |          3.00 |       6.67 |
| Browserkit Tests  |    3% |      13 |          4.16 |       6.05 |
+-------------------+-------+---------+---------------+------------+
| Total             |       |  144.54 |          2.18 |       5.72 |
+-------------------+-------+---------+---------------+------------+
複製代碼
  • 相對來說，Jobs、Controller和Events中的每個method中包含了最多的代碼
  • 雖然phpunit test顯示的是100%的使用，但實際的狀況是，大部分都只是laravel默認自帶的示例測試文件。其餘的數據顯示，只有27%的應用裏包含有自定義的測試
  • 多是laravel-stats這個組件自己的bug，由於顯示的是67%的應用使用controller，實際上不可能這麼低

結語

看了這些數據，你的laravel學對了嗎？用對了嗎？但願這些數據能給你的laravel使用與學習，提供更好的參考與建議～

值得自豪的是，經過這些數據，能夠看到兩年前咱們pilishen.com出品的laravel從入門到高手系列課程，兩年後的今天，依然能夠說是始終保持在laravel規範使用的前列，所以凡是認真學習了咱們系列課程的小夥伴，應該也能夠自豪地說本身的laravel用得很優雅、沒問題，在此祝賀大家，同時感謝一往的支持。

這些數據，是過去的兩三年內全球範圍內Laravel使用狀況的一個縮影，下一個時代，或者說下一個階段，應該就是Laravel 5.5的時代了。值得慶祝的是，咱們的這些系列課程，將於近期通通升級重錄，更新到laravel 5.5及更新的版本，以保證小夥伴們繼續領先下一個時代，下一個將來的兩三年。這次更新，將不僅是簡單地版本更新，不是簡單地把已有項目再作一遍，而是一次系統性的經典昇華，升級後的課程將不只包含本文數據裏提到的這些最佳實踐與建議，並且將包含大量這些數據裏都未曾提到的更優實踐，以此來切實保證我們的小夥伴們真真正正地領先同行。並且，咱們已經上車的小夥伴們，將完徹底全免費得到更新後的全部課程，不止過去，包括未來，相信大家都是國內laravel開發者中的佼佼者～

到如今尚未上車的小夥伴，你在等什麼呢？～

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程