はじめに
普段管理画面をよく作る2年目のSE?PG？です。
個人的にこうすると効率上がったな、と感じた事をメモがてら列挙していきます。
要所によっては怒られそうですが許してください。
時間の割き方
開発でどこにリソースを割くかでアウトプット量がかなり変わってきます。
80点の完成度までかかる時間と80点から100点までかかる時間は同じと言われたりしてます。
3時間のタスクが3つあった場合全て80%の出来で終えると4.5時間、全て100%までやると9時間。
倍の差が出ます。流石にここまで極端ではないと思いますが。
開発の初期段階、顧客にシステムイメージを持ってもらう段階などは特に80点すら目指さなくても良いと思うのです。
自分が思う80点の状態にしても大体ひっくり返ります。
モックに時間をかけて少ないページを作るより、60点ぐらいの状態でその時間を生産量にあてて
より多くページを作って広くイメージを持ってもらう方が良いと思うのです。
システムの目玉となる機能にだけ80点ぐらいになるように時間を割き、他のページを40、60点の状態にしたり。
モック段階の状態を顧客にチェックしてもらっている間に時間が少し時間が空いたりするので、
その間に案件で採用できそうな技術スタックを模索します。
日頃から開発速度が上がりそうな技術スタックを溜めこんでおいて、この時間に使えそうな物を選定します。
優先順位
開発、ざっと出すだけでこれぐらいの項目があります。
フロントエンド
・デザイン（UI）
・コーディング
・画面の動き（js）
バックエンド
・DB設計
・プログラム設計
・処理ロジック
バックエンドに最優先で工数を割くのは勿論の事、かといってフロント側を素のHTMLやCSSで書いていては無駄に時間を奪われてしまいますし、デザイナーでは無いので時間がいくらあっても足りません。
如何にしてフロント側を低工数かつ良い感じに出来るような工夫が必要になってきます。
特に見た目は進捗が目で確認しづらいので、余裕が出来るまでは拘りすぎず「まぁ、こんなもんだろう」のラインで留めて良いとおもいます。
怒られそうですが1ページの1部分のデザインに時間をかけるのはかなり無駄だと思うのです、付加価値が少ないから。
見た目に拘る一歩手前ぐらいで一旦引いて、見た目が60~70点ぐらいの状態でバックエンドを優先的にやり、余裕が出来たら見た目も拘るぐらいが一番効率が良いんじゃないかな、と思います。
逃げ道を考える
「こういう実装をしたい」と考えた時、実装方法を調べます。
今までにやった事が無い実装方法の場合、大体どこかで躓いたりします。そういう場合に躓いたままずっとその実装方法に拘っていると時間だけを消費して結局何も生まなかった。なんて事にもなりかねません。
100点になるような実装方法が全然進まない場合、70点になるような自分で出来る実装方法に逃げる事も大事かなと思います。
例えば、
「ここのページを非同期にしたい！けどなんか知らんけどうまくいかん！！時間だけが経っていく・・・」
となった時に
「あー無理そう、リロード挟むか」といった具合に逃げます。100点にしたければ納期に余裕が出来た時で良いと思うのです。
全部を理解しようとしない
目に入るもの全てを理解しながら進もうとしてるといつまでたっても進捗が出ません。「こういうものがある」程度で頭の隅に保存しといて、暇な時に理解を試みればよいと思うのです。何よりも大事なのはその場その場の自分の理解では無くて開発を進める事だと思うのです。
ロジックの分離をする
ここから開発に主に使っているLaravelの話になります。
Laravelには特別こういう書き方をしろ！という決まりがありません。
なので基本的な書き方だけでやるとcontrollerにバリデーションやらビジネスロジックやらを詰め込みがちでFatControllerになりがちです。
FatControllerになるとコードのチェック、修正や改修がやり辛かったりバグを見落としたり良いことが何一つありません。
見通しが悪くなるので新規の追加もやり辛いです。
個人的にやった方が良いであろう分離
・requestデータの処理、validationなどはFormRequestを使う
・モデルからのデータ取得処理はModelに書く
・ビジネスロジックはServiceクラスを作ってそこに書く
モデルにビジネスロジックを書くパターンの人もいると思いますが、モデルに別のモデルの処理が混じったりして気持ち悪いですし、FatModelになりがちです。モデルにはリレーションとデータの取得処理だけ書くようにします。
FormRequest→Controller→Service→Model
みたいな処理順になると思います。一貫性があるのがベストなのでModelからServiceクラスへのアクセスなどは無いようにしましょう。
serviceクラスの設計についてはシステムの規模によったりしますが、ベストな書き方を模索中です。
シングルアクションコントローラーで処理を分けるパターンもありますが、個人的にファイルをあまりにも細かく分けるのが好きじゃないです。
BladeComponentsを使う
Laravel7からBlade Componentsという機能が使えるようになりました。何かと言うとまぁ名前の通りBladeのcomponentなんですが
使いまわせそうなフォームなどをcomponent化する事でコードの行数も減って見通しが良くなりますし実装がかなり楽になります。
自分で作らなくてもAdminLTEベースのコンポーネントが転がっているので、こちらを使うのも全然ありです。
dgvai/laravel-adminlte-components
Laravel-AdminLTE components
参考記事:Laravel-AdminLTEの付属コンポーネントで楽にフォームを作ろうぜ
PhpStormを使う
有料ですがとにかく補完が強力です（語彙力）
有料のプラグイン（月額400円）laravel ideaを入れると更に何でもかんでも補完してくれるので開発がめちゃくちゃ快適です。
有料に有料を重ねますがオススメしたい、30日間無料で使えるエディタなので使ってみて欲しいです。
