作りたいものがありすぎる

40歳を過ぎてプログラミングを始めた人の顛末とこれからなど

Laravelの単機能を作るまでの大まかな流れ

Laravel PHP 資料 プログラミング 設計

設計やら命名規則やら一緒くたになってごちゃごちゃとしてます。
また、俺ルールと一般的なルールと、厳密なルールがごっちゃにかいてあります。
が、自分なりに他の人と共通作業を行う際のコンセンサスを取るメモみたいなものをアップしておきます。何かの参考になれば幸い。

（アプリケーションはAPIとし、ごく基本的な設定関連はほぼ終わっている状態と想定）

ルーティング定義をする

routes/api.php

ルートプレフィックスで上層のpathをまとめる
基本アルファベット順で並べる
特別な処理は上か下の行にまとめる

同じControllerの処理はまずCRUDの順で並べ、次にその他の処理を並べる。

基本はControllerで書いたメソッドの順と揃っているのが望ましい

しかし、これだと1行で行けるらしい、他のメソッド入れた際はどうするんだろう？

Route::resource('users', 'UserController');

Controller 作成

コマンド例 : php artisan make:controller HogeFugaController --resource

( --resources オプション CRUDメソッドを自動生成してくれる)

ディレクトリ/命名例 : app/Http/Controllers/HogeFugaController.php

命名規則:

  • 単数形,table名か機能名の UperCamelCase
  • 最後に Controller を書く

アノテーションにAPI仕様を書く
requestを受けてserviceに送り返り値をもらう処理を書く
retrun [ ]　で想定するAPIの返り値を仮作成
フロント側に要件での最低限の出力を可能とする

unit testファイルを作る

ひとまず pathを指定して
->assertStatus(200)　のテストを書く

テストを実施する(時間があればこの辺詳細書きたい)

migration ファイル作成

コマンド例 :
php artisan make:migration create_users_statuses_table

ディレクトリ例 :
app/Http/Controllers/HogeFugaController.php

命名規則 :

  • スネークケース
  • table(複数形)名に続けて create|edit|delete のいずれかを書く
  • 最後に tableを書く

1テーブルの作成・編集・削除につき1ファイルを生成する
migration実施とphpMyAdminでの仕様との差を確認

  • comment->('仮カラム、仮型')　等と通常のコメントで仮である事を明文化しておく
  • コメントアウトをして作らないでおく

factory 作成

migrationファイルと合わせて factoryを作る。

コマンド例 :
php artisan make:factory HogeFugaFactory
ディレクトリ/命名例 :
database/factories/HogeFugaFactory.php

faker を使ったり、Corbon や決め打ちの値で1レコード文の標準的なダミーレコード作成を定義する

seeder ファイル作成

コマンド例 : php artisan make:seeder UserStatusTableSeeder
ディレクトリ/命名例 : database/seeds/UserStatusTableSeeder.php

ダミーレコードを作る為の定義をするファイル
up メソッド内で未定義のカラムがある場合は faker で定義された値でレコードが生成される

upメソッド内の以下の違いに注意、作成時と編集時はメソッド名が異なる
Schema::create( ... )
Schema::table( ... )

忘れがち！
database/seeds/DatabaseSeeder.php に

$this->call(UserStatusTableSeeder::class);

を書かないとseedingは実行されない

また、Seeder書いたら以下のコマンドもやっておく 　

composer dump-autoload

少なくともレコード1件目はid系カラムのリレーションが成立する現実的値で具体的なデータを入れておく
2件目以降必要な現実的なデータがあれば、個別に生成できるようにしておく

以降のデータは他のtableの連携等含め、リレーションされるidは固定値、その他の値はある程度ランダムで生成されるレコード数を現実的な運用時のページング等の移動が行える程度には入れておく

seeder実施、各カラムに正しくfakeの値が入っているか確認

モデル作成と設定

コマンド例 :
php artisan make:model Models/HogeFuga

ディレクトリ/命名例 :
app/Models/HogeFuga.php

※コマンド時はフォルダpathの指定を間違えないこと

命名規則:

  • 単数形,table名か機能名の UperCamelCase
  • tableの場合は対となるControllerを持つ
  • 最後に Model は書かない

hidden 設定
filiter 設定
table　名指定
リレーション設定

ここにクエリビルダはEloquentの処理は書かない

あとでやる 例外として scpope　等の共通のSQLフィルタ処理のメソッド等を書く

Service 層の作成

app/Http/Services/HogeFugaService.php
※ artisanコマンドでは作れない、コピペで作る

命名規則:

  • Controllerと対にする
  • 単数形,table名か機能名の UperCamelCase
  • 最後に Service を書く
    • Controller が　HogeFugaController なら
    • Service は HogeFUgaService となる

必要なら Controllerから受けたrequestを受ける
1行で済むクエリビルダやEloquentならここに書く

必要なビジネスロジック処理を書く
複数行に渡るDB処理は、 Repositoryに渡して返り値をもらう処理を書く 引数を渡してRepository処理に反映させても良い

必要であれば他のtable層のRepository層を呼び出しても良いがなるべくしない

Repository 層の作成

app/Http/Repositorys/HogeFugaRepository.php
※ artisanコマンドでは作れない、コピペで作る

命名規則:

  • 単数形,table名か機能名の UperCamelCase
  • 最後に Repository を書く
  • Serviceと対にする
    • Controller が　HogeFugaController で
    • Service が HogeFUgaService なら
    • Repository は HogeFugaRepository となる

use App/Models/Hoge
use DB
を書く

DBから値を拾う処理のみを書く
簡単な if分岐やswitch 等はOK
メソッドにどのServiceのメソッドからの呼び出しかコメントを書く

引数を渡して処理を変える等しても良いが、詳細やルールをコメントする

Requests （フォームリクエスト）によるバリデートの作成

コマンド例 : php artisan make:request StoreBlogPost

ディレクトリ/命名例 : app/Htp/Requests/HogeFugaCreareUpdate.php

命名規則:

  • 単数形,table名か機能名の UperCamelCase Controller と同じ
  • 続けて対となるControllerのメソッド名
  • create, update 等、複数のメソッドで共通化できるものは両方の名前を続けて書く

authorrize() は、ほぼ　true　となる

rules() にバリデート条件を書く、仕様書に合わせて書く
特殊なバリデートが必要な箇所はオリジナルバリデートを作成する

本来はこのへんでしっかり test を書いて検証をしたい所だが、ひとまず、値を入れてみて手動のpost,get,put,delete,のtestをする


ひとまずこんな感じ。